Q> 테이블 LEVEL EXPORT 방법의 종류가 하나 이상 있습니까?
▶▶ 말씀드리자면 대답은 그렇기도 하고 아니기도 합니다. 테이블 export는 두
가지 방법 중 하나가 될 수 있습니다.

--- 사용자가 그 소유한 테이블을 export 한다.

exp donald/duck tables=huey, dewey, louie

--- SYSTEM/MANAGER 같은 DBA가 사용자의 집합에 속해 구분되어진 테이블
들을 export 한다.

exp system/manager tables=scott.emp, humty, dumpty

위의 두가지 export 방법 모두 테이블 level의 export로 구분되어집니다.
후자의 경우에는 export가 DBA에 의해서 행해지기 때문에 import도 DBA에
의해서 행해져야 합니다.


Q> FULL EXPORT 를 받으려면 사용자가 반드시 DBA 이어야 합니까?
▶▶ 아닙니다. 버전 6 에서는 그러했지만, 이는 오라클7 role 의 introduction
에서 바뀌었습니다. 다시 말해서, EXP_FULL_DATABASE role 을 받은 어떤 사용자도
FULL export 를 할 수 있습니다. 이 role 은 DBA 에 의해서 부여됩니다. 따라서,
여전히 DBA 가 아니면서도 위의 role 을 부여받은 사용자가 있을 수 있습니다.
위의 role 과 동반되는 privilege 들은 CATEXP.SQL 에 정의되어 있습니다.
privilege 들을 살펴보면 이 role 을 소유한 사용자는 DBA 와 거의 같은 역할을
할 수 있음을 알 수 있습니다.


Q> EXPORT 되는 객체들의 순서는 어떻게 됩니까?
▶▶ 오라클7 에서 export 되는 객체들의 순서는 다음과 같습니다. 위에서 아래쪽
으로 row 별로 왼쪽에서 오른쪽 순서로 읽으시면 됩니다.

Tablespaces Profiles Users Roles

System Privilege Role Grants Default Roles Tablespace
Quotas

Resource Costs Rollback Segments Database Links Sequences
(includes grants)

Snapshots Snapshot Logs Job Queues Refresh Groups
(includes grants,
auditing)

Cluster Definitions Tables(constraints, Referential POSTTABLES
grants, indexes, Integrity actions
comments, audits)
In 7.3.4 the order for
tables will be changed
to:(indexes, grants,
constraints, audits,
comments)

Synonyms Views Stored Triggers
Procedures
Default and System
Auditing


Q> 순서가 중요합니까? 만약 그렇다면 왜죠?
▶▶ 순서는 매우 중요합니다. Import 가 데이터베이스에 대한 SQL 문장들을 실행
하는 연속적인 session 이기 때문입니다. 다른 이미 존재하는 어떤 객체들에 의존
하는 몇몇 객체들은 반드시 더 이후에 위치해야 합니다. 예를 들어, 트리거는
테이블에 의존적 객체이므로 테이블이 트리거보다 먼저 import 되어져야 합니다.
또, 프로시져나 뷰같은 홀로 존재할 수 있는 객체들도 있습니다. 이러한 객체들은
compilation errors 과 함께 데이터베이스에 load 될 수 있고, 이는 처음으로 사용
될 때 비로소 validation 이 체크 됩니다.


Q> EXPORT 는 ARRAY FETCH 라 불리우는 메카니즘을 사용하는데, 이게 무엇입니까?
▶▶ Export 는 SELECT 문장을 만들어서 테이블 데이터를 가져옵니다. 즉, 데이터는
데이터베이스로부터 사용자 쪽으로 옮겨져야 하는데, 만약 Export 가 한번에 단
하나의 row 만 가져오게 되어 있다면 데이터베이스를 Export 하기 위해서는 너무
많은 부하가 걸릴 것입니다. 따라서, Export 는 매번 row 들의 집합을 fetch 해오게
되고, 총 수행시간은 감소하게 됩니다. Array fetch 는 데이터베이스로부터 한번에
여러개의 row 들을 가져오는 개념입니다.


Q> EXPORT 시의 BUFFER PARAMETER 는 어떤 목적으로 사용됩니까?
▶▶ 이전에 언급한 바와 같이, Export 는 한번에 여러개의 row 들을 fetch 합니다. 이러한 정보는 화일로 저장되기 이전에 사용자 쪽의 메모리에 올라가게 됩니다.
사용자에게 할당되는 메모리의 용량이 바로 BUFFER parameter 의 값과 대응하게
됩니다.


Q> EXPORT 시의 RECORDLENGTH PARAMETER 는 무엇입니까?
▶▶ Export 시 export 화일로 정보를 쓸때, 한번에 한 글자씩을 써내려가지 않고
버퍼의 정보를 한번에 기록하게 됩니다. RECORDLENGTH 는 이 버퍼의 크기입니다.
O/S 블럭 크기의 배수로 이를 관리하는 것이 가장 효율적입니다.
또, 이는 이전에 설명된 데이터를 가져올 때에만 사용되는 BUFFER parameter 와
종종 혼동됩니다. 두가지 버퍼가 있는 이유는 쓰기 버퍼가 SQL 문장들을 포함할 수
있기 때문입니다. 또한 데이터베이스로부터 자료를 가져올때 이는 export 화일
형태로 format 되어 있지 않습니다. 따라서, 데이터를 올바른 format 형태로 얻을
수 있도록 몇몇 메세지들도 포함되어 있습니다.


Q> 얼마나 많은 ROW 들이 한 주기에서 FETCH 되는 지 어떻게 알 수 있습니까?
▶▶ BUFFER parameter 에서 정의된 것 처럼 이 값은 버퍼의 크기를 한 row 의
크기로 나눔으로써 얻어질 수 있습니다. 한 row 의 크기는 대략 다음과 같습니다.
(sum of all internal columns sizes ) + 4 x (number of columns)


Q> LONG 데이터 타입도 같은 방법으로 작업할 수 있습니까?
▶▶ 아닙니다. LONG 데이터의 경우에는 현재로서는 오로지 한 row 씩의 fetch 만
가능합니다. LONG 데이터 타입은 2GB 까지의 길이를 가질 수 있으므로 위와 같은
방법으로 사용되어지는 것은 바람직하지 않기 때문입니다.


Q> PARALLEL 에서 MULTIPLE EXPORTS 를 할 수 있습니까?
▶▶ incremental exports 가 아니라면 가능합니다. incremental exports 는
dictionary 의 정보를 기록하게 되고, 실행중인 여러개의 session 들이 정보의
충돌을 야기할 것이기 때문입니다.


Q> RECORD PARAMETER 는 무엇입니까?
▶▶ 위 parameter 는 incremental export 에 적용됩니다. incremental export 는
이전의 incremental/cumulative/complete export 중에서 변화가 생긴 객체들만
export 하는 것입니다. 따라서 data dictionary 의 변경 timestamp 가 INCEXP
테이블의 timestamp 와 비교되고, 객체가 export 될때 새로운 timestamp 가 INCEXP
테이블에 반영됩니다.
RECORD=Y 로 정해주시면 INCEXP 테이블의 현 정보가 유지됩니다. 그렇지 않으면
아무런 정보가 남지 않습니다. 다시 말하면 RECORD=N 상태이면 모든 객체들이 export
됩니다. 종종 이 parameter 는 쓰기버퍼나 incremental export 와 관계없는
RECORDLENGTH 와 혼동되기도 합니다.


Q> 테이블의 FLAG 을 "MODIFIED" 로 바꾸는 것들은 어떤 경우입니까?
이는 추가적 INCREMENTAL EXPORT 를 해야함을 의미합니까?
▶▶ INSERT, DELETE, UPDATE 문을 사용하셔서 데이터를 변경하셨다면 객체가 변경
되었다고 나타나게 됩니다. 컬럼을 not null 로 바꾸시거나 storage 를 변경하는
등의 DDL 은 테이블을 변경시키게 됩니다. 심지어 테이블에 grant 나 comment 를
추가하셔도 테이블이 변경되었다고 나타납니다.


Q> 데이터가 EXPORT 될 때의 시점에서 모든 데이터의 일관성이 유지됩니까?
"SNAPSHOT TOO OLD" 에러는 무엇인가요?
▶▶ Export 는 일련의 SELECT 문을 생성함으로 데이터를 가져오게 되고, 각각
테이블 데이터의 snapshot time 이 SELECT 문의 생성 시간과 대응합니다. 만약,
어떠한 데이터 작업도 없다면 이것은 크게 중요하지 않습니다. 그러나, export 가
시작된 후 테이블을 변경시키는 경우가 가능합니다. 그러한 경우에는 데이터의
snapshot 이 중요할 수 있습니다. Export 는 테이블에 exclusive lock 을 걸지
않기 때문입니다.
option 중 CONSISTENCY=Y 라는 것이 있는데, 이 것을 enable 시키면 EXPORT 는
export 를 시작하기 전에 먼저 SET TRANSACTION READ ONLY 명령어를 수행합니다.
그러나, 오랫동안 계속되는 export 의 경우에는 rollback segment 의 공간이
부족해서, "snapshot too old" 에러가 생길 위험이 있습니다.


Q> PRE-TABLE 과 POST-TABLE ACTIONS 은 무엇입니까?
▶▶ pre-table actions 은 테이블이 import 되기 전에 실행되는 PL/SQL
routines 이고, post-table actions 은 모든 테이블들이 import 된후에 실행되는
PL/SQL routines 입니다. 그러므로 프로시져들은 테이블 데이터가 import 된후
변경 작업을 하게 됩니다. 이러한 options 은 사용자들이 실행하길 원하는
routines 을 지정할 수 있도록 앞으로의 release 에서 제공될 것입니다. 이는
import session 중에서 데이터를 변경할 수 있도록 해줄 것입니다.


Q> IMPORT 는 ARRAY INSERTS 를 사용하는데 이것은 어떤 것입니까?
▶▶ Export 가 테이블 데이터를 select 하는 것처럼 import 는 데이터베이스로
다시 데이터를 insert 합니다. 한번에 한 row 를 insert 하는 것은 자원 집약적
입니다. 데이터베이스로 통신하는 횟수는 한번에 여러 row 들을 insert 함으로써
줄일 수 있습니다. 이것이 바로 array insert 의 개념입니다.


Q> LONG 컬럼의 테이블을 IMPORT 할 때 한번에 한 컬럼 씩 INSERT 되는데,
이것이 정상적으로 수행되는 것입니까?
▶▶ 정상입니다. LONG 컬럼에 대해서는 array 크기의 default 는 1 입니다.
Export 는 insert 하기 전에 모든 LONG 컬럼을 올려놓을 연속적인 메모리를 필요로
하기 때문입니다. 또, 적당한 upper bound 를 찾아낼 방법도 없습니다. 장차 LONG
컬럼을 조각조각 insert 하는 데이터베이스의 지원이 이루어 질때 이러한 작업은
변화될 것입니다.


Q> IMPORT BUFFER 는 무엇입니까?
▶▶ 테이블의 rows 이 저장되기 위해서 데이터베이스로 보내기 전에 사용자 쪽에
할당될 메모리의 용량을 지정하는 parameter 입니다.


Q> 각각의 ARRAY INSERT 에 COMMIT 할 수 있습니까?
▶▶ COMMIT=Y 로 지정하시면 가능합니다. 한번의 통신에서 commit 되는 정확한
rows 의 수는 버퍼의 크기와 얼마나 많은 rows 가 해당 버퍼에 저장 되었는 것에
달려있습니다.


Q> RECORDLENGTH PARAMETER 는 무엇입니까?
▶▶ import 는 한 번에 한 글자씩 export 화일로부터 정보를 읽지 않습니다.
대신에 버퍼의 값만큼의 분량의 정보를 메모리로 읽습니다. RECORDLENGTH 는 이
읽기버퍼의 크기입니다. 이를 O/S 블럭 크기의 배수로 유지하는 것이 가장 효율적
입니다. 이 parameter 는 종종 테이블 데이터에만 영향을 미치는 BUFFER parameter
와 혼동되기도 합니다. 테이블 데이터에 나뉘어져 저장된 SQL 문장들이 있어서
데이터가 분리될 필요가 있으므로 또다른 분리된 버퍼들을 가지는 것이 필요합니다.




Q> DESTROY OPTION 은 IMPORT 시에 어떤 역할을 합니까?
▶▶ CREATE TABLESPACE 문은 사용자가 존재하는 데이터 화일을 재사용할 수 있게
하여주는 REUSE 절을 가지고 있습니다. 그러나, 사용자가 다른 테이블스페이스 속한
화일을 실수로 없애버리는 바람직하지 않은 효과를 낼 수도 있으므로 주의해야
합니다. DESTROY=N 으로 import 를 실행하면 CREATE TABLESPACE 문에서 REUSE
절을 사용하지 않게 됩니다.


Q> IMPORT 를 실행 시 "SEALS DON'T MATCH" 라는 메세지를 접하게 됩니다.
SEAL이 어떤 건가요?
▶▶ seal 은 export session 에 대해 정보를 가지고 있는 export 화일 헤더의
또 다른 이름입니다.


Q> IMPORT 를 실행시 "ABNORMAL END OF FILE" 이라는 메세지를 보게 됩니다.
이것이 무슨 의미인가요?
▶▶ 이것은 어떤 이유로 인해서 export 화일이 손상되었음을 의미합니다.
보통 import 는 화일의 특정 포인트를 얻으려 하는데, 만약 화일이 손상되었
다면 import는 아마도 정상적이지 않게 약간 앞쪽에서 찾으려 하게 됩니다.
그 결과 화일이 비정상적으로 끝났다고 생각하게 되는 겁니다.
한쪽 기종에서 다른 기종으로 정상적으로 옮겨지지 않았다면 export 화일은 손상을
입었을 가능성이 있습니다. export 하는 기종에서 다시 한번 화일을 보내도록
하십시오. 또 한가지 화일의 transport protocol 이 binary mode 인지 확인
하시기 바랍니다.


Q> FROMUSER / TOUSER 기능을 사용하고 있는데, TOUSER 수 보다도 FROMUSER 에서
많은 사용자를 지정하고 있습니다. 이 때, 여분의 사용들에게 어떤 일이 생기나요?
▶▶ import 는 적절한 수의 TOUSER 만큼 FROMUSER 수를 mapping 합니다. 여분의
사용자들은 스스로에게 mapping 되므로 시작 시점에서 지정되지 않을 수도
있습니다.


Q> FROMUSER / TOUSER 기능을 사용하고 있는데, FROMUSER 수 보다 많은 TOUSER
수를 사용합니다. 여분의 TOUSER 는 어떻게 됩니까?
▶▶ 그들은 무시되게 됩니다

출처 : Technical Bulletin (Korean)