Export, Import시 이미 생성된 오브젝트의 정보를 데이타 딕셔너리에서 쿼리를 하는데 이러한 오브젝트의 정보가 데이타 딕셔너리내의 여러 테이블에 나누어져 있다. 필요한 데이타 딕셔너리 정보를 편리하게 이용하기 위하여 여러 가지의 뷰를 catexp.sql에 Script되어 있다. 이 스크립트 화일은 $ORACLE_HOME/rdbms/admin에 있으며 Install시 수행되도록 되어 있다.　　　　　　

[질문2] Export시 오브젝트의 백업 순서는 있는가 ?　　　　　　

　 Export하는 오브젝트의 순서는 존재하며 이는 Oracle의 Version Up등에 의한 새로운 오브젝트가 만들어지거나 하면 Export되는 오브젝트의 순서는 변할 수 있다.　　　　　　
　　　　　　　　
　오브젝트의 Export순서는 다음과 같다.　　　　　　　

Tablespaces　　　　　　　
Profiles　　　　　　　
Users　　　　　　　
Roles　　　　　　　
System Privilege Grants　　　　　　　
Role Grants　　　　　　　
Default Roles　　　　　　　
Tablespace Quotas　　　　　　　
Resource Costs　　　　　　　
Rollback Segments　　　　　　　
Database Links　　　　　　　
Sequences( includes Grants )　　　　　　　
Snapshots ( includes grants, auditing )　　　　　　　
Snapshot logs　　　　　　　
Job Queues　　　　　　　
Refresh Groups　　　　　　　
Cluster Definitions　　　　　　　
Tables(includes grants,column grants,comments,indexes,constraints,auditing)　　　　　　　
Referential Integrity　　　　　　　
POSTTABLES actions　　　　　　　
Synonyms　　　　　　　
Views　　　　　　　
Stored Procedures　　　　　　　
Triggers　　　　　　　
Default and System Auditing

　 BUFFER　　　　　　
　 Export시 오브젝트 내에 있는 여러 개의 Row가 한꺼번에 Fetch된다. 디스크에서 Fetch된 정보는 화일에 Write하기 전에 메모리를 거치게 되며, 이때 할당되는 메모리의 양이 Buffer 파라미터의 값이다.　　　　　　

　 RECORDLENGTH　　　　　　
　 메모리에 있는 Export할 자료를 화일에 Write하기 위해 한번에 운반되는 양을 결정하는 파라미터이다.　　　　　　
[주의] 위의 BUFFER와 RECORDLENGTH는 O/S의 Block Size의 배수가 되도록 하는 것이 효율적이다.　　　　　　

[질문4] 다량의 Row를 Export, Import시 어느 정도의 Row가 처리되었는지 알 수 있는가?　　　　　　

　 알 수 있다. V 7.1까지는 다량의 Row를 Export, Import시 처리된 정도를 알 수가 없어 현재 작업 중인지 시스템이 Hang인지 파악되지 않았으나 V 7.2 부터는 FEEDBACK이라는 옵션을 이용하여 체크가 가능하다.　　　　　　

[질문5] Export시 한번에 몇 개의 Row가 Fetch되는가?　　　　　　

　 한번에 Fetch되는 Row의 수는 Buffer Size와 연관 관계가 있다. 하나의 Row가 Export시 차지하는 양은 각 Column Size의 합 + 4 * (Column의 수)로 구할 수 있다. 한번 Fetch되는 Row의 수는 Buffer Size / 한 Row의 Export시 Size이다. 이를 이용하면 Export된 Output File의 Size는 대략 한 Row의 Export시 Size * Row 수 이다.　　　　　　

[질문6] Export, Import의 호환성은 어떻게 되는가?　　　　　　

　 Export, Import의 호환성은 Oracle의 버젼과 직접적인 연관관계를 갖고 있다.　　　　　　
호환성은 4가지로 나누어 설명할 수 있으며 이를 아래의 가정을 이용해 설명하겠다.　　　　　　　
가령 A라는 기계에 Oracle V 7.0, B 라는 기계에 Oracle V 7.1이 설치되어 운영 중이라 가정하자. Oracle V7.0을 X라 하고 Oracle V7.1을 Y라고 하자.　　　　　　

　 Base Compatibility : X의 exp를 이용해 X DB를 export하여 X의 imp를 이용해 X DB에 import하는 것을 말한다. 이는 당연히 지원한다.　　　　　　
　 Upward Compatibility : X의 exp를 이용해 X DB를 export하여 Y DB에 Y의 imp를 이용해 import하는 것을 말한다. 이도 Oracle에서는 지원한다.　　　　　　
　 Downward Compatibility : Y exp를 이용해 Y DB를 export하여 X DB에 X의 imp로 import하는 것을 말한다. 이는 지원될 수도 안될 수도 있다.　　　　　　
　 Cross Compatibility : X exp를 이용해 Y DB를 export(SQL*Net 이용)하여 X 또는 Y DB에 import(imp는 적정한 것을 활용)하는 것을 말한다. 이는 지원될 수도 안될 수도 있다.　　　　　　　

[질문7] 어떤 경우에 Downward Compatibility가 실패하는가?　　　　　　

　　 V7.2에 hash cluster expressions라는 옵션이 있는데, 이를 이용해서 클러스터를 생성하여 사용 후 export한 것을 V7.0 또는 V7.1로 downward시 create cluster문에 옵션이 맞지않아 실패하게 된다.　　　　　　

[질문8] EXP-37 에러(export views not compatible with database version)발생의 원인은 무엇인가 ?　　　　　　

　 이 에러는 Cross Compatibility에서 발생하는 문제로 이는 Export가 이용하는 View(Catexp.sql에 의해 생성된)가 Oracle Version내에 일치하지 않아 발생한 문제로 이를 해결하기 위해 Exp에서 이용 가능한 View를 설치한다.　　　　　　

[질문9] Full Export는 DBA 권한을 갖고 있는 유저만 할 수 있는가 ?　　　　　　

　　 Version 6 에서는 DBA권한을 갖고 있는 유저만 Full Export를 할 수 있으며, V7에서는 DBA가 아니더라도 EXP_FULL_DATABASE Role이 Grant되면 Full Export가 가능하다.　　　　　　

[질문10] 테이블 Import 시에 디폴트 테이블 스페이스가 아닌 곳으로 들어가는 경우는 왜 발생하는가?　　　　　　

　　　 예를 들어서 scott 유저의 디폴트 테이블 스페이스가 users 인데 임포트를 해보면 tools 테이블 스페이스에 테이블이 만들어졌다고 하자. 그 이유는 다음과 같다. 즉, 임포트 하는 테이블이 원래 tools 테이블 스페이스에 있었고 scott가 현재 tools 테이블스페이스에 대한 Quota 를 가지고 있거나 아니면 Unlimited Tablespace 권한(Resource Role 에 포함)을 부여 받았기 때문이다.　　　　　　　

　 Import시에 테이블을 디폴트 테이블 스페이스에 만들려면 디폴트 테이블 스페이스 외의 테이블 스페이스에 대한 모든 Quota 를 0 로 만들고 Unlimited Tablespace 권한을 Revoke 시킨 다음에 임포트를 수행해야 한다. 그리고, 디폴트 테이블 스페이스에 대한 Quota만 Unlimited 로 한다. 예를 들면 다음과 같다.　　　　　　　

$ sqlplus system/manager　　　　　　

SQL> alter user scott　　　　　　
　　 quota 0 on system　　　　　　
　　 quota 0 on tools　　　　　　
　　 .......　　　　　　
　　 quota 0 on data　　　　　　
　　 quota unlimited on users;　　　　　　

SQL> revoke unlimited tablespace from scott;　　　　　　
　　　　　　　

　 이렇게 한 다음 Import 를 수행하면 된다. 물론 유저를 만들 때 quota 를 주지 않은 테이블 스페이스는 상관 없으며　 Unlimited Tablespace 권한(또는 Resource Role) 을 주지 않았다면 Revoke 명령도 사용할 필요가 없다.　　　　　　　

[질문11] Import 시에 Core Dump/Segmentation Fault 가 발생하는 경우　　　　　　

　　 오라클에는 Character Set이 있다. 국내에서는 US7ASCII 또는 KO16KSC5601 을 주로 사용하는데 Export 받은 곳과 Import 하는 곳의 Character Set 이 다르면 Import 시에 Core Dump 가 발생하거나 원인 불명의 에러가 발생하면서 임포트가 중단되는 경우가 발생한다.　　　　　　　
　 이 경우에는 Export 받은 dump file 을 convert 프로그램을 이용하여 Import 하는 곳의 Character Set 으로 변환 시킨 다음 임포트를 하는 방법이 있고, 아니면 어느 한 쪽 DB 의 Character Set　 자체를 바꿔서 동일하게 맞춘 다음 Export/Import 하는 방법이 있다. 이중에서 Convert 프로그램을 이용하는 방법이 간단한데 이 프로그램은 Unix 상에서 cc 로 컴파일 하여서 사용하면 된다. 프로그램 소스는 Response Center로 문의하면 구할수 있다.