Q> 소문자 이름의 테이블들을 EXPORT 할 수 있습니까?
▶▶ 가능합니다. 테이블 생성시 이름을 소문자로 사용하는 것은 권유하는 바는
아니지만 테이블 이름의 quotes 를 사용하여 생성할 수 있습니다. 예를 들어

create table "mytab" (col1 number);

이 테이블은 MYTAB 이 아닌 mytab 으로 dictionary 에 저장될 것입니다.
또한 다음과 같이 테이블로부터 select 할 수 있습니다.

select * from "mytab";

quotes 사용이 항상 요구 되어지지는 않습니다. 왜냐하면, 소문자 이름의
테이블을 테이블 level 의 export 할 때에 operating system 은 command line
에서 quotes를 다른게 해석할 수도 있기 때문입니다.


Q> STORED PROCEDURE, PACKAGES, PACKAGE BODIES 를 EXPORT 할때 얻어진 TEXT
는 어느 곳에 있게 됩니까?

▶▶ text 는 SOURCE$ 에서 알아낼 수 있고, 이 내용이 export 됩니다.


Q> 몇몇의 WRAPPED STORED PROCEDURES 가 있는데 이들의 TEXT 역시 SOURCE$ 로
부터 얻어집니까?

▶▶ 그렇습니다. wrapped format 이 portable 하므로 전혀 문제가 없습니다.


Q> 사용자 A 에 의해서 소유된 테이블이 있습니다. 이 테이블의 INDEX 는 사용자
B 에게 소유되어 있습니다. 사용자 A 로 USER-LEVEL EXPORT 를 하고 있습니다.
INDEX 가 EXPORT 됩니까?
▶▶ 사용자 A 에 소유되지 않은 index 는 export 되지 않습니다. 그러나, DBA
가 user-level 의 export 를 하면 index 는 export 됩니다. 다른 schema 의
index 를 재생성할 수 있는 권한을 가진 DBA 에 의해서 import 가 이루어지기
때문입니다.


Q> EXPORT 실행 중의 성능 향상을 위한 방법에는 어떤 것들이 있습니까?

▶▶ 우선 사용 기종에 load 문제가 있는지 없는지 체크해야 합니다. 또한 disk
export 에 과부하가 걸리지는 않았는가 확인해야 합니다. export 는 dictionary
queries 의 CATEXP.SQL 의 views 에 대한 sequence 를 생성하기 때문에 query
들 중 일부가 늦게 실행될 수도 있습니다. 더 많은 정보들은 sql_trace 를 실행
함으로써 얻을 수 있습니다.


Q> PL/SQL 없이 데이터베이스를 인스톨하였습니다. JOB QUEUES 나 REFRESH
GROUPS 같은 PL/SQL 에 의존적인 객체들을 EXPORT 하려할 때 어떻게 됩니까?

▶▶ export 는 그런 것들을 무시하게 됩니다. PL/SQL 없이 오라클을 구입하는
것이 가능하므로 Release 7.0 에서는 이것이 큰 문제가 되었습니다. Release 7.1
부터는 PL/SQL 이 묶음으로 따라오지만, 이를 인스톨하지 않을 수 있는 option 을
여전히 사용자는 가지고 있습니다.


Q> PROCEDURES, PACKAGES 를 EXPORT 할때, 생성된 TIMESTAMPS 가 보존됩니까?

▶▶ 불필요한 재컴파일을 막기 위하여 생성 timestamp 는 보존됩니다.


Q> PACKAGES, PROCEDURES 를 EXPORT 한후 어떤 것은 INVALID 상태인데 이것이
무슨 문제가 됩니까?

▶▶ 문제가 되지 않습니다. procedures 는 서로 의존적 관계이므로 어떤 한
procedure 가 그것이 의존하는 procedure 가 생성되기 전에 만들어 질 수 도
있습니다. 이러한 객체들은 그들이 사용될때 valid 상태로 바뀝니다.


Q> FULL 데이터베이스 EXPORT 를 하고 있습니다. EXPORT 가 끝나기 전에 어떤
사용자가 테이블 중 하나를 DROP 시켰습니다. 이것이 가능합니까?

▶▶ 가능합니다. export 는 session 의 시작 시에 모든 테이블에 lock 을 걸지
않습니다. export 는 session 시작 시에 모든 테이블의 list 만 가지고 있습니다.
테이블의 list를 생성하는 시간과 테이블이 실제로 export 되는 시간 사이에
테이블이 drop될 수도 있습니다. export 는 drop된 테이블은 건너 뛰고
계속됩니다. 이런 상황은 경고 상태입니다.


Q> 읽기 전용의 테이블스페이스가 있습니다. EXPORT/IMPORT 주기가 끝난 후 여전히
그것은 읽기 전용입니까?

▶▶ 현재로는 그렇지 않습니다. 테이블스페이스는 읽기, 쓰기가 가능합니다.
그 이유는 테이블스페이스는 테이블 데이터가 import 되기 전에 생성되기
때문입니다. 만약 테이블스페이스가 읽기 전용으로 생성된다면 아무런 데이터도
import 되지 습니다. option 은 데이터를 import 하고 후에 자동으로
테이블스페이스를 읽기 전용으로 만드는 것입니다. 그러나, 사용자가
테이블스페이스를 미리 생성하고 그것을 읽기 전용으로 만들기로 원하지 않을 수도
있습니다. 이 결정은 사용자가 마음대로 정할 수 있습니다.


Q> OFFLINE 테이블스페이스가 하나 있습니다. EXPORT 는 이 테이블스페이스에 있는
자료도 가져옵니까? 이 테이블스페이스는 EXPORT/IMPORT 주기가 끝난 후에도
OFFLINE 상태로 있게 됩니까?

▶▶ 두가지 경우 모두 그렇지 않습니다.


Q> ROLLBACK SEGMENT 가 현재 OFFLINE 입니다. EXPORT/IMPORT 주기가 끝난 후
에도 OFFLINE 상태로 있게 되나요?

▶▶ 그렇지 않습니다.


Q> EXP_FULL_DATABASE ROLE 에게 주어진 "BACKUP ANY TABLE" 권한은 무엇입니까?

▶▶ 사용자에게 incremental export 를 허용하려면 privilege 가 필요합니다.
incremental export 의 개념은 지난 번 incremental export 이후에 변화된
테이블만 export 하는 것입니다. 테이블이 변화되면 modification bit 이 지정
되고 export 는 이 bit 을 찾게 됩니다. 만약 bit 이 셋팅되면 테이블을 export
하고 다음 번 incremental export 에서는 이 테이블이 export 되지 않게끔 bit
을 정리하는 문장들을 생성합니다.
이 문장을 만들기 위해 export 의 사용자는 "backup any table" privilege 가
필요합니다. 일반적으로 DBA 만이 incemental export 를 수행하지만,
실제로는 EXP_FULL_DATABASE role 을 부여받은 어떤 사용자도 incremental
export 를 실행할 수 있습니다. 만약, DBA 가 export 를 수행한다면 이 권한
은 부적절한 것입니다. 왜냐하면 DBA 는 데이터베이스에 대해 어떠한 일도
할 수 있기 때문입니다.
그러나, DBA 가 아니면서 EXP_FULL_DATABASE role 을 가진 사용자가 있을 수
있습니다. 그런 경우에는 이 권한은 non-DBA 가 modification bit 을 정리할 수
있게 해주므로 적절한 사용이 됩니다.


Q> A, B 로 불리는 다른 사용자에게 소유된 두 테이블에 기반을 둔 SNAPSHOT 이
있습니다. SNAPSHOTS 을 EXPORT 하고 FROMUSER/TOUSER OPTION 을 사용해서
이들을 C, D 등의 다른 사용자에게 옮기고 싶습니다. IMPORT 시에 FROMUSER/
TOUSER OPTION 을 사용하는 것이 적당한 것입니까?

▶▶ 그렇지 않습니다. FROMUSER/TOUSER 의 개념은 단지 한 사용자에게 속한 객체
들을 다른 사용자에게로 옮기는 것입니다. 의존적인 정의들은 이 개념에서 지원
되지 않습니다.


Q> 테이블을 EXPORT 할때 CONSTRAINT INDEXES 은 EXPORT 시의 STORAGE 특성 값
들을 여전히 보유하고 있습니까?

▶▶ 그렇습니다. 이것은 ALTER TABLE 명령어에서 USING INDEX STORAGE 절을
사용함으로 얻어집니다.


Q> IMPORT 되기 전에 데이터를 특별한 방법으로 미리 저장하고 싶습니다.
이것을 지원하는 기능이 있습니까?

▶▶ 이와 연관된 몇가지 처리 요구사항이 있지만 현재로는 불가능합니다.


Q> FULL 데이터베이스 EXPORT가 있고 FULL 데이터베이스 IMPORT를 막 수행하려
합니다. 미리 생성해야 할 객체들의 집합이 있습니까?

▶▶ 테이블스페이스와 rollback segments 을 미리 생성하는 것이 좋습니다.
그래야 export 가 올바른 위치로 이루어지게 됩니다. 만약, full export 가
OpenVMS 에서 UNIX 로 처럼 다른 operating system 에서 왔다면 이는 반드시
필요합니다. 꼭 필요하지는 않지만 다르게 지정된 quotas, default tablespaces
같은 사용자 attributes 도 미리 생성해주면 좋습니다. SHOW=Y 로 import 하게
되면 처음에 export 화일의 현재 문장들을 보여줍니다.


Q> 사용자 A 의 테이블들을 EXPORT 화일 대신에 그의 DEFAULT 테이블스페이스로
전환하고 싶습니다. 원본 테이블스페이스도 역시 새로운 데이테베이스에 존재
합니다. 이렇게 하고 싶으면 어떻게 해야 합니까?

▶▶ 선별적으로 해당 테이블스페이스에서 자원들을 취소하거나 사용자 A 의 해당
테이블스페이스 quotas 를 0 으로 지정할 수 있습니다. 두가지 경우 모두
테이블은 전환될 것입니다.


Q> 사용자 JOE 가 EXPORT 를 수행하는 것을 방지하고 싶습니다.
JOE 는 DBA가 아닙니다. 어떻게 해야 합니까?

▶▶ export 와 관련된 role 은 부여받으면 full 데이터베이스를 export 할 수
있는 EXP_FULL_DATABASE 입니다. 그러나, 이를 부여받지 않았어도 사용자가
소유한 객체들의 사용자, 테이블 level export 는 가능합니다. export 를 완전히
못하도록 데이터베이스 내에서 할 수 있는 조치는 없습니다. 그러므로, O/S
levle 에서 export executable 에 접근을 못하도록 해 놓는 방법이나 그에 준하는
조치가 가장 좋은 방법입니다.


Q> SYSTEM 테이블스페이스에 많은 데이터 화일들을 가지고 있습니다. 이 데이터
화일들에 대한 정보나 EXPORT 된 그들의 크기 등을 알 수 있을까요?

▶▶ 알 수 없습니다. export 된 SYSTEM 테이블스페이스에 관한 정보는 제공되지
않습니다. 데이터베이스가 import 수행을 할수 있도록 구성 되어 있어야 하기
때문에 새로운 데이테베이스는 이미 고유한 SYSTEM 테이블스페이스를 가지고
있어야 합니다.
그래서, 사용자의 객체들을 SYSTEM 테이블스페이스 이외의 다른 곳에 저장하고
SYSTEM 테이블스페이스에는 catalog 정보를 포함하는 것들을 위해 남겨두는 것이
좋습니다. 만약, source 데이터베이스에서 SYSTEM 테이블스페이스에 여분의
화일들을 추가한다면 그들은 화일을 import 하기전에 target 데이터베이스에서
수작업으로 생성되어져야 합니다.


Q> COMPRESS=Y 와 ROWS=N 라는 OPTION 의 조합은 ROWS 을 EXPORT 하기 원하지
않는 사용자라면 모를까 전혀 말이 되지 않는 것 같습니다.

▶▶ COMPRESS=Y option 은 단지 storage 절을 바꾸어서 initial extent 가
모든 현재의 extents 의 합이 됩니다. 테이블에 데이터가 있던 없던 아무런 관계
가 없습니다. 새로운 데이터베이스에서 데이터는 하나도 없지만 크기가 정확히 꼭
같은 테이블을 새로운 DB에 생성할길 원하는 사용자의 경우에는 사용 가능합니다.


Q> EXPORT 화일에서 모든 DDL 문장들을 포함하는 SQL SCRIPT 를 생성하고
싶습니다. 이것이 가능합니까?

▶▶ 직접적으로는 아니지만 가능합니다. import 에 대해서 SHOW=Y option 을
사용하면 실행될 모든 문장들의 list 가 주어집니다. 이것은 LOG option 을 사용
하면 log 화일로 보내지고, log 화일은 사용자가 직접 수정 가능합니다. UNIX 의
SED, AWK 같은 적당한 operating system tool 은 이 화일을 SQL script 로
reformat 시켜줍니다. 앞으로는 직접 이러한 기능을 수행하는 option 이 제공될
것입니다.


Q> EXPORT/IMPORT 주기 이후에 어떤 객체들이 ANALYZED 되었는지 아닌지를
어떻게 알아낼 수 있습니까?

▶▶ export 화일에 어떤 ANALYZE 문장들이 쓰여졌는가를 알아내는 three-level
hierarchy 가 있습니다.

--- Cluster

--- Table

--- Index

여기에 export 가 사용하는 알고리즘의 요약이 있습니다.

--- 만약 클러스터가 analyzed 되면 테이블이나 인덱스는 자동으로 analyzed
되기 때문에 cluster 에는 ANALYZE 문장들이 생성되지 않습니다.

--- 만약 클러스터가 analyzed 되지 않고 단지 몇개의 테이블만 analyzed
되면 ANALYZE TABLE 문장들은 per-table basis 의 화일에 쓰여집니다.
analyzed 테이블에 대한 인덱스는 자동으로 analyzed 되므로 화일에
ANALYZED INDEX 문장은 쓰여지지 않습니다.

--- clustered 테이블의 인덱스가 있을 수 있으나 클러스터나 테이블은
analyzed 되지 않습니다. 이 경우, 만약 인덱스가 analyzed 되었다면
ANAYLYZE INDEX 문장은 export 파일에 쓰여집니다.

출처 : Technical Bulletin (Korean)