5. EXPORT / IMPORT

1 : 다른 USER로 IMPORT
2 : PIPE와 COMPRESS를 사용한 EXPORT
3 : TAPE로 EXPORT, IMPORT, LOADER 사용하기
4 : EXPORT시 화면에 결과가 나오지 않게하기
5 : CRON 사용법
6 : EXPORT/IMPORT 에 관하여 (1)
7 : EXPORT/IMPORT 에 관하여 (2)
8 : EXPORT/IMPORT 에 관하여 (3)
9 : EXPORT/IMPORT 에 관하여 (4)
10 : EXPORT받은 DUMP FILE을 가지고 IMPORT SCRIPT받기
11 : EXPORT FILE의 SIZE 예측
12 : 많은 갯수의 TABLE을 한번에 TABLE별로 EXPORT 받는 방법
13 : INCREMENTAL, CUMULATIVE, COMPLETE EXPORT & IMPORT
14 : EXPORTING ORACLE8 TO IMPORT TO ORACLE7
15 : (V8.X)USER LEVEL, TABLE LEVEL EXPORT/IMPORT 방법 및 FAQ
16 : ORACLE 8I EXPORT의 QUERY OPTION 기능
17 : ORACLE 버젼간 EXPORT/IMPORT 상호 호환성 참조표
18 : EXPORT FILE을 SPLIT하여 생성하는 방법.
19 : LARGE EXPORT FILE의 SPLITTING 방법


TOPIC 1. SCOTT의 데이타를 LARRY로 옮기는 방법
scott의 데이타를 larry 로 옮기려면 export/import 를 이용해야 한다. larry가 만들어져 있지 않다면 다음과 같이 만든다. $ sqlplus system/manager SQL> create user larry identified by lion default tablespace users temporary tablespace temp quota unlimited on users; default tablespace, temporary tablespace 는 시스템에 따라 알맞게 설정한다. 다음과 같이 larry에게 권한을 부여한다. sql> grant connect, resource to larry sql> revoke unlimited tablespace from larry 물론 users 테이블스페이스는 이미 존재한다고 가정한다. scott로 export를 받고 larry로 import한다. $ exp scott/tiger file=scott.dmp $ imp larry/lion file=scott.dmp fromuser=scott touser=larry 만약 scott 가 dba 권한을 갖고 있었다면 다음과 같이 import를 해야 한다. $ imp system/manager file=scott.dmp fromuser=scott touser=larry 만약 import 도중 연속된 저장 공간이 부족해서 에러가 발생한다면 익스포트를 받을 때 compress=n 옵션을 사용하며, import 시 롤백 세그먼트 문제가 발생 한다면 import 시 commit=y 옵션을 사용하면 쉽게 해결이 가능하다.


TOPIC 2. PIPE 와 COMPRESS 를 사용한 export
Export 중에 dump file size 가 2G 이상이어서 에러가 발생하는 경우가 있습니다. 이러한 문제를 해결하기 위하여, 압축(unix command 인 compree 이용)하면서 disk 나 tape 으로 보낼 수 있는 방법은 다음과 같습니다. $ mknod /tmp/exp_pipe p => /tmp/exp_pipe 라는 이름의 pipe를 생성합니다. 이 때 p는 pipe 임을 나타냅니다 (이후에 불필요하여 지우는 방법은 rm /tmp/exp_pipe, rm하지 않고 계속해서 아래의 compress와 exp 작업을 중복하게 되는 경우 이후 import 시에 문제가 발생할 수 있으므로 주의한다.) $ compress < /tmp/exp_pipe > /dev/rmt/tx4 & => pipe 를 통과하게 될 화일을 압축하여 tape device /dev/rmt/tx4 로 보내는 작업을 backgroud process 로 미리 기동하여 둡니다. tape 대신 disk 로 보낼 때에는 export.dmp.Z 과 같은 화일명을 줍니다. (이 때 <, >는 redirection 기호이므로 생략해서는 안 되고 위와 같이 그래도 적어야 한다.) $ exp system/manager file=/tmp/exp_pipe full=y and other options => Dump file name 에는 위에서 만든 pipe 이름을 줍니다. 위와 같이 받은 dump file 을 import 하는 방법은 다음과 같습니다. $ mknod /tmp/imp_pipe p => import 를 위한 /tmp/imp_pipe 생성하십시오 $ uncompress < /dev/rmt/tx4 > /tmp/imp_pipe & => pipe 를 통과 하게될 화일의 압축을 풀어서 tape device /dev/rmt/tx4 로 보내는 작업을 backgroud process 로 미리 기동하여 둡니다. export를 disk로 받았다면, tape device name 대신 압축 화일명을 주십시오. $ imp system/manager file=/tmp/imp_pipe and other option => file 에는 위에서 만든 pipe 이름을 줄 것 EXAMPLE) 2G를 초과하는 export dump file을 압축하여 tape으로 보내어 전체 데이타베이스 에 대하여 backup을 받고, 그 중에서 scott 유저의 데이타만 import 하는 예. mknod /tmp/exp_pipe p compress </tmp/exp_pipe> /dev/rmt/tx4 & exp system/manager file=/tmp/exp_pipe owner=s buffer=100000 volsize=0 참고 : volsize=0 의 의미는 tape으로 화일을 보낼 때 제한을 두지 않겠다는 것 (no limit)을 의미합니다. mknod /tmp/imp_pipe p uncompress </dev/rmt/tx4> /tmp/imp_pipe & imp system/manager file=/tmp/imp_pipe owner=scott ignore=y



TOPIC 3. TAPE로 EXPORT, IMPORT, LOADER 사용하기
대용량의 DATA를 BACKUP 받거나 DATA를 처리할 때에는 TAPE을 이용하는 경우가 있다. 이럴 때 EXPORT, IMPORT, SQL*LOADER에서 TAPE 를 이용하는 방법을 종류별로 정리하였다. 1. TAPE DEVICE로 EXPORT 받기 % exp userid=system/manager full= y file=/dev/rmt/0m volsize=245M FILE은 TAPE이 있는 DEVICE 이름이고 VOLSIZE는 TAPE에 들어갈 DATA의 SIZE이다. 만약 첫번 째 TAPE이 245M에 이르게 되면 다음 TAPE를 넣으라는 메시지가 나온다. (주의) VOLSIZE should be < tape capacity 2. TAPE DEVICE에서 IMPORT받기 % imp userid=system/manager full=y file=/dev/rmt/0m volsize=245M 첫번째 TAPE이 245M에 이르면 다음 TAPE를 위한 메시지가 나온다. 3. PIPE와 DD를 이용한 tape의 export % mknod /tmp/exp_pipe p # Make the pipe % dd if=/tmp/exp_pipe of=<tape device> & # Write from pipe to tape % exp file=/tmp/exp_pipe <other options> # Export to the pipe 4. PIPE와 DD를 이용한 tape의 import % mknod /tmp/imp_pipe p # Make the pipe % dd if=<tape device> of=/tmp/imp_pipe & # Write from tape to pipe % imp file=/tmp/imp_pipe <other options> # Import from the pipe 5. PIPE 와 DD를 이용한 remote server의 tape device에 export하기 % mknod /tmp/exp_pipe p % dd if=/tmp/exp_pipe | rsh <hostname> dd of=<file or device> & % exp file=/tmp/exp_pipe <other options> 6. PIPE 와 DD 를 이용한 remote server의 tape device에서 import하기 % mknod /tmp/imp_pipe p % rsh <hostname> dd if=<file or device | dd of=/tmp/imp_pipe & % imp file=/tmp/imp_pipe <other options> 7. TAPE에 있는 DATA FILE을 SQL*LOADER로 받기. % mknod /tmp/load_pipe p % dd if=<tape_device> of=/tmp/load_pipe & (주의) 만약 tape이 EBCDIC이면 다음 명령으로 ASCII로 바꾸어 줍니다. % dd if=<tape_device conv=ascii of=/tmp/load_pipe & % sqlldr userid=user/pass control=contol.ctl log=loader.log infile='/tmp/load_pipe' * PIPE는 I/O operation의 보다 빠른 상호 작용을 위한 memory 안의 가상 화일이다. PIPE buffer는 Sun Solaris에서는 5K, HP에서는 8K, SGI에서는 10K이다. 이것은 FIFO를 따르며 command는 다음과 같다. mknod filename p * DD는 한 device로부터 다른 곳으로 data를 raw copy하는 명령어이다.



TOPIC 4. EXPORT시 화면에 결과가 나오지 않게하기
다음은 export, import 시 화면에 실행 결과를 return 하지 않는 방법이다. 이는 사용하는 shell 에 따라 약간의 command 차이가 있다. 1) csh : exp command > &file 즉 exp .... > &/dev/null 2) ksh,bsh : exp command >/dev/null 2>&1 참고 ) %ksh $set -o vi esc+ k key 시 history 를 볼수 있다.



TOPIC 5. CRON 사용법
<CRON TABLE 사용법> cron 은 root를 사용해도 되고 oracle owner를 사용해도 되는데 oracle 사용 시는 /usr/lib/cron/cron.allow 에 oracle owner를 등록해야 한다. /var/spool/cron/crontabs/khpark 화일에 cron table 을 정의한다. 여기에는 *(분) *(시간) *** ....(수행될 script path 와 file 이름을 적어준다.) Field Range ------------------------ minute 0-59 hour 0-23 day of the month 1-31 month of the year 1-12 day of the week 0-6 (0 is Sunday) 1. $crontab khpark 2. khpark 의 내용 0 18 * * * sample (18시에 sample 을 실행) 3. sample program 의 내용은 아래와 같다. 여기에서는 예를 들어 export를 full로 수행하는 작업을 예로 든다. 1) root 사용 시 cron table 에 다음과 같이 작성한다. * * * * * su - oracle -c "/../.../script_file" (수행될 file 이름.) (*부분은 원하는 시간을 지정) 이 script file 에 /usr/oracle/bin/exp system/manager file=expfull.dmp full=y ... 을 명시한다. 2) oracle 을 사용할 때 oracle 을 cron.allow 에 등록한다. cron table 에는 * * * * * "/../.../script_file" (수행될 file 이름.) 과 같이 하면 된다. (*부분은 원하는 시간을 지정) script_file은 다음과 같이 작성한다. 이것은 예이므로 각 환경 변수인, ORACLE_HOME,... NLS_LANG 등은 자신의 시스템에 맞게 setting하여야 한다. ORACLE_HOME =/usr/oracle;export ORACLE_HOME ORACLE_SID=TEST;export ORACLE_SID ORA_NLS=/usr/oracle/ocommon/nls/admin/data;export ORA_NLS NLS_LANG=American.America.KO16KSC5601;export NLS_LANG /usr/oracle/bin/exp system/manager full=y ... (이 문 대신 pro*c program 등 수행하고자 원하는 script file이나 실행 가능한 file 이름 등을 지정하면 된다)



TOPIC 6. EXPORT/IMPORT에 관하여 1)
[질문1] RDBMS와 Export, Import의 연관 관계는 (catexp.sql 이란) ? Export, Import시 이미 생성된 오브젝트의 정보를 데이타 딕셔너리에서 쿼리를 하는데 이러한 오브젝트의 정보가 데이타 딕셔너리내의 여러 테이블에 나누어져 있다. 필요한 데이타 딕셔너리 정보를 편리하게 이용하기 위하여 여 러 가지의 뷰를 catexp.sql에 Script되어 있다. 이 스크립트 화일은 $ORACLE_HOME/rdbms/admin에 있으며 Install시 수행되도록 되어 있다. [질문2] Export 시 오브젝트의 백업 순서는 있는가 ? Export하는 오브젝트의 순서는 존재하며 이는 Oracle의 Version Up 등에 의한 새로운 오브젝트가 만들어지거나 하면 Export되는 오브젝트의 순서는 변할 수 있다. 오브젝트의 Export순서는 다음과 같다. 1. Tablespaces 2. Profiles 3. Users 4. Roles 5. System Privilege Grants 6. Role Grants 7. Default Roles 8. Tablespace Quotas 9. Resource Costs 10. Rollback Segments 11. Database Links 12. Sequences( includes Grants ) 13. Snapshots ( includes grants, auditing ) 14. Snapshot logs 15. Job Queues 16. Refresh Groups 17. Cluster Definitions 18. Tables(includes grants,column grants,comments,indexes, constraints,auditing) 19. Referential Integrity 20. POSTTABLES actions 21. Synonyms 22. Views 23. Stored Procedures 24. Triggers 25. Default and System Auditing [질문3] Export 시 BUFFER와 RECORDLENGTH는 무엇인가? -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 시에 디폴트 tablespace가 아닌 곳으로 들어가 는 경우는 왜 발생하는가? 예를 들어서 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 으로 변환시킨 다음 Import를 하는 방법이 있고, 아니면 어느 한 쪽 DB 의 Character Set 자체를 바꿔서 동일하게 맞춘 다음 Export/Import하는 방법이 있다. 이 중에서 Convert 프로그램을 이용하는 방 법이 간단한데 이 프로그램은 Unix 상에서 cc로 컴파일하여서 사용하면 된다.



TOPIC 7. EXPORT/IMPORT에 관하여
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 와 관계없는 R4ECORDLENGTH 와 혼동되기도 합니다. 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 는 어떻게 됩니까? ▶▶ 그들은 무시되게 됩니다.



TOPIC 8. EXPORT/IMPORT 에 대하여 3)
Q> 어떻게 IMPORT 는 CHARACTER SET CONVERSION 을 처리합니까? ▶▶ export 된 데이터베이스가 character set A 로 생성되었다고 가정할때, export session 은 character set B 입니다. 그 결과 two-task layer 에 의해서 A 로부터 B 로 데이터가 conversion 됩니다. export 화일의 데이터는 이제 character set B 이고, 화일은 import 될 기종으로 전송됩니다. import session 이 예를들어 character set C 라고 하더라도 export 화일 데이터는 여전히 character set B 임을 확인할 수 있습니다. destination 데이터베이스가 character set D 이면 C 로부터 D 로의 conversion 은 two-task 를 통해서 이루어 집니다. 그러나, B 로부터 C 로의 conversion 은 반드시 import 에 의해서 수행되어져야 합니다. 다음에 몇가지 유의사항이 있습니다. -- character set B 와 C 는 반드시 1 의 ratio 를 가져야 합니다. B 와 C 사이의 ratio 가 n 이라면 이는 character set C 의 string 길이가 source character set B 의 같은 string 길이의 최대 n 배가 된다는 것을 의미합니다. ratio 가 1 이 되는 것을 기대하는 이유는 import 쪽에서 사용되는 현재의 메모리 운영 형태때문입니다. 이것은 앞으로 몇가지 부분이 바꾸어질 것입니다. string 들은 import 에 의해서 B 로부터 C 로 바뀌고, character set D 로 바뀌어질 수 있도록 two-task layer 를 통해서 보내집니다. -- B 와 C 사이의 모든 characters 이 변환될 수 있는 것은 아닙니다. 이는 매우 데이터에 의존적이며 사용자에게 책임이 있습니다. -- export 를 수행중에 데이터베이스 A 에 저장된 특별한 어떤 character 들은 character set B 로 capture 되지 않으면 정보를 잃게 됩니다. -- 만약 다음 정보들에 대해 주의를 기울이신다면 내용을 잘 살펴봐 주십시오. 가) source 데이터베이스에 대한 데이터베이스 character 의 변환은 CREATE DATABASE 문장이 수행될때 지정이 됩니다. 나) 데이터가 insert 되어질때 client 쪽의 character 변환은 NLS_LANG 에 의해서 지정되어 집니다. 다) client 쪽의 character 변환은 데이터가 export 될 때 이루어 집니다. 이는 사용자가 원하는 특별한 characters 에 capture 할 수 있음을 의미합니다. 라) destination 데이터베이스에 대한 데이터베이스 character 변환은 CREATE DATABASE 문장이 수행될때 지정이 됩니다. 마) client 쪽의 character 변환은 데이터가 import 될때 이루어 집니다. Q> CHARACTER SET B 에서 C 로의 변환이 되지 않는데 어떻게 조치해야 합니까? ▶▶ import session 의 NLS_LANG 을 character set B 로 바꾸어 주십시오. 이제 B=C 이므로 수행이 가능합니다. Q> CHARSET OPTION 이 무엇입니까? ▶▶ CHARSET option 의 개념은 사용자가 export 화일의 character set 을 지정 할 수 있게 하는 것입니다. 그러나, 때때로 사용자는 다른 character set, 예를 들어 E 로 지정하길 원합니다. 여전히 export 화일은 B 에 있기 때문에 원래 이론을 따른다면 B 에서 E 로 바뀌고, 이것은 추후 필요에 따라 다시 E 에서 C 로 변경 되어집니다. 그러나, 데이터는 이 과정에서 손상을 입을 수 있습니다. 현재는 CHARSET 은 단지 B 만 가능합니다. 이는 앞으로 개선될 것입니다. Q> "8-BIT PROBLEM" 은 무엇입니까? ▶▶ CREATE DATABASE 명령어를 사용해서 데이터베이스를 생성시에 사용자는 character set 을 지정할 수 있습니다. 만약 사용자가 이를 지정하지 않았다면 default 는 US7ASCII 입니다. 사용자들은 umlauts 같은 8-bit 데이터를 US7ASCII 의 데이터베이스로 저장해왔습니다. high bit 의 조작이 없었기 때문에 사용이 가능했지만, side effect 역시 존재해 왔습니다. 8-bit 의 문제는 이제 사용자들이 8-bit 의 데이터를 다른 데이터베이스로 migration 하고싶어 한다는 점입니다. 이때, 다음 두가지 중 한가지가 발생합니다. 사용자는 character set B 를 US7ASCII 로 지정해 놓았습니다. export 시에 변환이 되지 않으므로 화일은 US7ASCII 로 되어 있으나 8-bit 데이터는 있는 그대로 나타납니다. 그 결과 순수 8-bit 데이터베이스로 import 할때에는 high bit 이 손실되게 됩니다. 다음으로 사용자가 character set B 를 8-bit 로 지정했을때는 데이터를 가져올 때 high bit 는 export 화일로 오기전에 손상을 입게 됩니다. 그래서, 정보가 손실 되거나 화일이 제대로 생성되지 않게 됩니다. 이 문제의 해결책은 앞으로 나아진 CHARSET 에서 보강됩니다. Q> 어떻게 데이터베이스의 CHARACTER SET 을 알아낼 수 있을까요? ▶▶ 다음 query 를 수행해 보십시오. select * from props$ where name = 'NLS_CHARACTERSET'; PROPS$ 는 SYS 유저의 소유입니다. Q> 현 데이터베이스와 꼭 같은 복사본을 생성하고 싶은데, 데이터 내용이 없습니다. 어떻게 해야 합니까? ▶▶ ROWS=N option 으로 full 데이터베이스 export 를 하십시오. exp system/manager full=Y rows=N file=full.dmp 그리고, rows=N option 으로 full 데이터베이스 import 를 받으십시오. imp system/manager full=Y rows=N file=full.dmp 만약 같은 기종에서 중복되게 데이터베이스를 생성하려고 한다면 이전의 데이터 화일들이 이미 사용중이므로 새로운 테이블스페이스가 생성되어져야 합니다. Q> 기존의 데이터를 IMPORT 시 새로운 데이터로 교체하고 싶습니다. 직접 이런 작업들을 할 수 있습니까? ▶▶ import 는 SQL*Loader 같은 replace optioin 이 없으므로 불가능 합니다. 먼저 직접 수작업으로 모든 rows 을 삭제하셔야 합니다. Q> 왜 SYS 에 의해 소유된 객체들은 EXPORT 되지 않습니까? ▶▶ 사용자가 SYS 로 접속하고 객체를 생성하는 것은 가능하지만 SYS 는 또한 OBJ$, USER$, 등등의 dictionary 테이블을 소유하고 catalog 뷰나 dictionary 객체들을 소유하고 있습니다. SYS 를 export 하는 것은 dictionary 객체들이 아닌 모든 객체를 찾는 작업을 포함합니다. 새로운 데이터베이스는 이미 고유의 dictionary 테이블을 가지고 있기 때문입니다. 이를 결정하는 것은 가능하지만 새로운 dictionary 객체를 생성 시킬 때 export 에 대해 상당한 부하가 걸리게 됩니다. 그래서, SYS 가 배제되는 것입니다. 또한 사용자들은 어떠한 개인적인 작업을 하기 위하여 SYS 로 접속해서는 안됩니다. DBA 는 그의 고유한 계정을 부여받고, 객체들은 그의 schema 에서 생성되어져야 합니다. SYS 는 매우 강력한 계정이고, 상대적으로 가장 적게 사용되도록 남겨 두어야 합니다. Q> SYS 의 객체들에게 부여된 GRANT 들은 EXPORT 됩니까? ▶▶ export 되지 않습니다. Q> SYS 나 SYSTEM 의 PASSWORD 는 EXPORT 됩니까? 다른 사용자들에 대해서는 어떻습니까? ▶▶ 위의 두 사용자의 password 는 export 화일의 값과 맞아 떨어지도록 변경됩니다. 그러므로 DBA 가 혹 password 를 잊어 버리더라고 lock 을 풀 수 있습니다. 다른 방법으로는 INTERNAL 로 접속하는 것입니다. 다른 사용자의 password 는 변경되어 지지 않습니다. Q> EXPORT 화일에서 PASSWORD 를 변경할 수 있습니까? ▶▶ password 들은 암호화되어 있어서 변경할 수 없습니다. 그러나, 이동이 가능하므로 어떤 데이터베이스에서도 작동합니다. Q> PARALLEL 에서 일련의 사용자 EXPORT 들을 사용하여 FULL EXPORT 를 할 수 있습니까? ▶▶ 사용자 level 의 export 는 특정 사용자나 사용자 집합에 소유된 객체들만 포함합니다. full 데이터베이스 export 는 tablespaces, profiles, roles, auditing 등의 다른 dictionary 객체들에 대한 정보를 포함합니다. 이것들은 사용자 export 에서는 export 할 수 없는 item 들입니다. 따라서, 이론상으로 사용자 exports 의 모음은 full export 와 같지 않습니다. 그러나, parallel 에서 시간을 절약할 수 있으므로 단지 사용자들만을 export 하는 것은 타당합니다. 사용자는 다른 객체들을 재생성하기 위해 rows 가 없는 여분의 full export 를 반드시 가지고 있어야 합니다. Q> 다른 데이터베이스 작업들이 실행 중일 때 EXPORT 와 IMPORT 를 할 수 있습니까? ▶▶ 가능합니다. export 의 경우는 CONSISTENCY=Y 가 아니라면 각 테이블의 snapshop 시간은 다르게 됩니다. import 의 경우에는 각 테이블이 암시적으로 다음의 DDL 문장이 실행된 후 데이터가 commit 됩니다. 모든 테이블들이 import 된 후에야 foreign key 관계는 생성이 됩니다. 이러한 관계들에 의존하는 application 들은 import 가 마무리 될 때까지 작동이 되지 않을 수 있습니다. Q> IMPORT 시에 어떻게 관련된 무결성이 지켜지게 됩니까? ▶▶ 모든 테이블들이 import 된후 모든 foreign key 관계들이 생성됩니다. 또, 특정한 테이블의 데이터가 import 된후에 CHECK 나 PRIMARY KEY 같은 constraints 도 생성됩니다. Q> EMP 라는 테이블을 EXPORT 했는데 TEST 라는 테이블에 이를 IMPORT 하고 싶습니다. 이것이 가능합니까? ▶▶ 불가능합니다. 테이블은 EMP 로 import 되어져야 합니다. 그러나, 수작업으로 나중에 테이블 이름을 바꾸어 주실 수는 있습니다. Q> TABLESPACE-LEVEL 의 EXPORT/IMPORT 를 할 수 있습니까? ▶▶ 비록 이것은 차후 보완하려는 부분이지만, 현재로서는 불가능합니다. 현재 export 와 import 는 full, user, table 의 세가지 modes 로 실행할 수 있습니다. 각 level 은 우측의 경우를 포함합니다. 테이블스페이스는 이 modes 에 걸쳐 있으므로 이러한 상위구조에 완벽하게 적합되지 않습니다. 따라서, 비록 편리한 방법은 아닌지만 가능한 차선책은 테이블스페이스의 객체들을 모두 확인해서 테이블 단위로 export 를 하는 것입니다. 이러한 차선책은 인덱스와 관계된 모든 테이블들이 같은 테이블스페이스 있다는 가정을 하게 됩니다. 이는 다른 테이블스페이스에 존재하는 관계된 인덱스들까지 export 하는 것을 지원하지 않습니다. Q> 이미 존재하는 테이블로 데이터를 IMPORT 하고 있습니다. 테이블에는 인덱스와 트리거가 존재합니다. 그런데 왜 IMPORT 는 INSERT PROCESS 의 속도를 높이기 위해 이들을 DISABLED 합니까? ▶▶ 사용자는 테이블에 여러개의 triggers 나 constraints 을 가지고 있을 수 있고 다른 이유로 인해서 이들 중 일부를 disabled 시켜 놓았을 수 있습니다. 그 결과 import 는 어떤 것들이 enabled 되어 있고 그렇지 않은 가를 추적해야만 하고, 나중에 다시 이들을 재생성 해 주어야 합니다. constraints 나 triggers 가 business rules 을 요구하는 것이므로 이러한 책임은 사용자가 조정 가능하게끔 합니다. Q> CLUSTER 의 부분인 테이블이 있는데 이를 테이블 LEVEL EXPORT 하고 싶습니다. 여전히 CLUSTER 의 정의가 적용됩니까? ▶▶ 적용되지 않습니다. import 시 cluster 의 정보없이 테이블이 생성됩니다. Q> EXPORT 하기 전에 특정 ROLLBACK SEGMENT 를 지정하고 싶은데 이것이 가능합니까? ▶▶ 현재로는 불가능합니다. Q> 버전 6 과 7 사이의 EXPORT 시에 VIEWS 의 변경이 있습니까? ▶▶ 버전 6 에서는 viws 가 export 될때 생성 timestamp 순서로 이루어 집니다. 그래서, 만약 view B 가 view A 를 기반으로 생성되었다면 view A 가 더 오래된 것이므로 먼저 export 됩니다. 그러나, script 를 통해서 양쪽 views 가 동시에 생성되게 할 수도 있습니다. 그런 경우에는 이들의 순서는 명확하게 구분되지 않습니다. 그 결과 export 화일에서 view A 보다 먼저 나타난다면 view B 의 생성은 실패하게 됩니다. 오라클7 에서는 level 의 순서로 export 되므로 위의 문제가 해결됩니다. view B 는 view A 보다 높은 level 에 있으므로 항상 마지막에 export 됩니다. level 의 정보는 DEPENDENCY$ 를 참조하시기 바랍니다. Q> 테이블 데이터를 IMPORT 할 때 INDEXES 도 존재합니까? ▶▶ 만약 테이블이 새로운 것이라면 그렇지 않습니다. indexes 는 모든 테이블 데이터가 import 된후 생성됩니다. 그러므로 index 는 hit 되지 않습니다. 만약, 테이블이 이미 존재한다면 index 는 disabled 되지 않게 됩니다. Q> GRANTS 는 어떻게 IMPORT 됩니까? ▶▶ WITH GRANT OPTION 의 모든 grants 은 첫번째로 import 됩니다. 그리고 생성 순서에 따라서 정규 grants 가 그 뒤를 따릅니다. Q> SYNONYMS 은 어떻게 EXPORT 됩니까? ▶▶ synonyms 은 그들의 생성 순서에 따라서 export 됩니다. Q> 어떻게 IMPORT 는 EXTENTS 을 압축합니까? 만약 테이블이 압축 된다면 NEXT EXTENT를 위해 어떤 값을 사용합니까? COMPRESS OPTION 을 사용함으로써 얻는 좋은점과 나쁜점은 어떤 것입니까? ▶▶ 사실 import 는 어떠한 extents 도 압축하지 않습니다. export 가 그런 작업을 합니다. COMPRESS=Y 로 지정되어 있으면 export 는 할당된 모든 extents 를 합하고 export 화일의 CREATE TABLE 문장의 initial extent 을 이 값으로 지정함으로써 테이블의 현재 크기를 정하게 됩니다. NEXT 값은 두번째 extent 의 실제 크기입니다. 이것은 import 된후 압축된 테이블들이 너무 커지는 것을 방지합니다. 만약 export 할때에 테이블이 크고 COMPRESS=Y 로 지정되 있으면 import 는 initial 값이 너무 커서 테이블을 생성하지 못할 수 도 있습니다. 이러한 경우에는 import 실행 이전에 작은 extent 로 미리 테이블을 생성해 보는 것입니다. Q> 어떻게 테이블 조각들을 모을 수 있을까요? ▶▶ 조각모음의 목적은 fragmentation 에 의해서 잃은 공간을 재생성 하는데 있습니다. 테이블을 조각모음 하기 위해서는 가) COMPRESS=Y option 으로 테이블을 export 합니다. 이는 initial extent 를 테이블의 크기로 지정합니다. 나) 우선 안전하게 데이터베이스를 back up 하고 테이블을 drop 합니다. 다) 테이블을 import 합니다. 이것은 모든 테이블의 내용을 하나의 extent 로 저장합니다. 만일 USER LEVEL의 EXPORT를 한 경우 자기 소유가 아닌 TABLE에 대한 INDEX는 EXPORT되지 않읍니다. 해당 TABLE이 DROP되면 INDEX도 따라서 DROP됩니다. TABLE은 크지만 이전에 많은 DELETE가 발생되어 실제적인 DATA양이 적은 경우는 IMPORT가 일어나기 전에 미리 작은 INITIAL EXTENT로 TABLE을 생성해 놓는 것이 바람직합니다.



TOPIC 9. EXPORT/IMPORT 에 대하여 4)
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 파일에 쓰여집니다.



TOPIC 10. EXPORT받은 DUMP FILE을 가지고 IMPORT SCRIPT받기
다음은 export받은 dump 화일을 이용하여 database 내의 object 생성문을 얻어내는 방법이다. 이 때 import의 두가지 option(show와 indexfile)을 이용할 수 있다. (1) show option을 이용하는 방법. 먼저 unix의 shell을 하나 띄운다. # ksh script 명령을 사용하여 이후에 나오는 화면을 화일로 받아 둔다. # script imp.log Script started, file is imp.log show option을 사용하여 import를 수행한다. # imp system/manager file=xxx.dmp full=y show=y 이 때 실제 실행되는 import script가 화면에 보이고 실제 database로는 값이 입력되지는 않는다. (definition only) shell을 빠져 나간다. #exit 편집기로 imp.log를 열어 보면 방금 실행한 내용들이 들어 있다. (2) indexfile option을 이용하는 방법. 위와 같은 경우 다음과 같은 명령으로 script를 만든다. # imp system/manager file=xxx.dmp full=y indexfile=index constraints=y 그러면 index.sql이라는 file이 생성이 되고 이 때 생성된 file 안의 script는 index 생성 script 외에는 모두 REM으로 막혀 주석 처리가 되어 있다. 이것을 제거하고 사용하면 되고 vi 편집기에서 모든 주석 처리되어 있는 것을 없애려면 위의 경우와 마찬가지로 아래와 같이 하여 처리한다. ~ ~ ~ : 1;$ s/REM/ /g * 이 때 얻을 수 있는 정보의 양은 서로 다르다. indexfile을 이용할 경우에는 create table과 index 정도이다. 하지만 REM을 제거하기만 하면 index 뿐 아니라 table 생성 script도 바로 사용 가능한 형태로 만들 수 있다. 그러나 show option을 사용할 경우는 내용은 table, index, view, synonym, procedure 등 모든 object의 생성 script를 얻을 수는 있으나, " "로 묶여 있어 바로 사용하기에는 번거로운 단점이 있다.



TOPIC 11. EXPORT FILE의 SIZE 예측
disk 여유가 없어 export된 dump size를 알아야 할 경우, named pipe를 이용하여 export를 수행함으로써 정확한 dump file size를 예측해 볼 수 있다. 단, 이 방법은 실제 export를 수행하는 것과 동일한 시간이 소요 된다는 점을 염두에 두어야 한다. % mknod /tmp/exp_pipe p % dd if=/tmp/exp_pipe of=/dev/null bs=1024 & % exp scott/tiger file=/tmp/exp_pipe 64+0 records out 결과가 위와 같다면 dump 화일의 크기는 64 * 1024 byte 가 된다.



TOPIC 12. 많은 갯수의 TABLE을 한번에 TABLE별로 EXPORT 받는 방법
export를 table 별로 받아야 할 필요가 있는 경우 export를 받아야 할 table이 매우 많은 경우 tables option에 모두 적는 것이 불가능한 경우가 있다. 이러한 경우 다음과 같이 작업하도록 한다. 1) sqlplus scott/tiger로 login SQL> set heading off SQL> set pagesize 5000 (user가 소유한 table의 갯수이상) SQL> spool scott.out SQL> select tname from tab; SQL> exit 2) 위와 같이하면 모든 scott user의 table들이 scott.out에 저장 $ vi scott.out SQL> select tname from tab; BONUS DEPT DUMMY EMP SALGRADE SQL> exit vi editor로 불필요한 처음과 마지막 두라인 삭제후 table 이름뒤에 있는 null문자를 제거 합니다. < null문자 제거 및 export 화일을 만드는 사전 작업 > 화일을 open 한 후 1) :g/ /s///g <-- table name뒤의 null문자 제거 2) :1 3) bonus table 뒤에 comma 를 append 4) :map @ j$. 하고 Enter <--- 다음 라인에도 2번의 작업을 하기 위한 macro 5) Shift+2 (계속 누르고 있음)<--- 다음 라인의 마지막에 comma 추가 6) 제일 마지막 라인은 comma 불필요 위의 out file을 100 개씩(table name이 길 경우는 그 이하로) 라인을 쪼개어 화일을 나누어 개별 화일 이름을 부여하여 저장합니다. 예) 1~100은 scott1.out 101~200은 scott2.out .....과 같이 나누고 화일의 제일 마지막 라인의 comma를 제거 아래의 script4exp.c를 compile하여 export를 위한 shell script를 작성합니다. ( 필요하다면 script내의 export option을 수정하여 compile) compile이 끝난후 $ script4exp scott1.out scott1.sh scott tiger scott1.dmp scott1.log $ script4exp scott2.out scott2.sh scott tiger scott2.dmp scott2.log . . . 하게 되면 scott1.sh, scott2.sh,.....가 생기며 이를 모드를 바꿔 background job으로 수행하면 됩니다. 주의 ) 1. 작업이 끝난후 *.sh의 file size를 check하십시오. 2. 가능한 큰 table은 outfile에서 빼내 따로 export하십시오. ====script4exp.c================= #include <stdio.h> #include <string.h> #define EXPCMD "exp %s/%s buffer=52428800 file=%s log=%s tables=" main(int argc, char **argv) { FILE *ifp, *ofp; char buff[256], *pt; if (argc != 7) { printf("\nUSAGE :\n"); printf("$ script4exp infile.out, outfile.sh, username, passwd, dmpfile.dmp, logfile.log\n\n"); exit(0); } if ((ifp = fopen(argv[1], "r")) == NULL) { printf("%s file open fail !!\n", argv[1]); exit(0); } if ((ofp = fopen(argv[2], "w")) == NULL) { printf("%s file open fail !!\n", argv[1]); exit(0); } fprintf(ofp, EXPCMD, argv[3], argv[4], argv[5], argv[6]); while((fgets(buff, 80, ifp)) != NULL) { if ((pt = strchr(buff, '\n')) != NULL) *pt = NULL; fprintf(ofp, "%s", buff); memset(buff, 0, sizeof(buff)); } fprintf(ofp, "\n"); fclose(ifp); fclose(ifp); }



TOPIC 13. INCREMENTAL, CUMULATIVE, COMPLETE EXPORT & IMPORT
'Incremental', 'Cumulative', 'Complete' Export가 무엇이며, 어떻게 효과적인 backup 전략으로 사용할 수 있는지를 알아본다. (자세한 내용은 'Oracle7 Server Utilities' manual을 참조하도록 한다.) Incremental, Cumulative export의 계획 수립 ----------------------------------------- 'Complete' export는 db 내의 모든 정보를 추출하여 기록해 준다. 따라서, 매일 밤에 complete export를 수행한다면 하루치 이상의 data가 유실될 염려는 전혀 없게 된다. 그러나, complete export는 많은 시간이 소요될 뿐 아니라 많은 space도 필요로 하게 된다. 최종 export 이후에 변경된 정보들에 대해서만 자주 export할 수 있는 방법으로 incremental, cumulative export가 있는데 이를 이용하면 시간과 space를 절약할 수도 있다. incremental export는 마지막으로 수행된 incremental, cumulative, complete export 이후에 변경된 모든 table들을 export한다. cumulative export는 마지막으로 수행된 cumulative, complete export 이후에 변경된 모든 table 들을 export한다. 만약 db가 손상되거나 완전히 유실되었다고 가정한다면, 1. 가장 최근의 complete export를 import하고 2. 위의 complete export 이후에 생성된 cumulative export들을 차례로 import한 후 3. 위에서 적용한 마지막 cumulative export 이후의 모든 incremental export를 적용함으로써 마지막 export 시점까지의 복구가 가능해진다. 다음과 같은 export 실행 계획을 수립한다고 가정해 본다. . 매일 밤 incremental export를 수행한다. . 매주 cumulative export를 수행한다. . 매월 complete export를 수행한다. 이에 따른 한달 계획은 다음과 같을 수 있다. 일 월 화 수 목 금 토 +--------+--------+--------+--------+--------+--------+--------+ | | Full | Inc | Inc | Inc | Cum | | | | | | | | | | | | 1 | 2 | 3 | 4 | 5 | 6 | +--------+--------+--------+--------+--------+--------+--------+ | | Inc | Inc | Inc | Inc | Cum | | | | | | | | | | | 7 | 8 | 9 | 10 | 11 | 12 | 13 | +--------+--------+--------+--------+--------+--------+--------+ | | Inc | Inc | Inc | Inc | Cum | | | | | | | | | | | 14 | 15 | 16 | 17 | 18 | 19 | 20 | +--------+--------+--------+--------+--------+--------+--------+ | | Inc | Inc | Inc | Inc | Cum | | | | | | | | | | | 21 | 22 | 23 | 24 | 25 | 26 | 27 | +--------+--------+--------+--------+--------+--------+--------+ 매주 금요일에 cumulative export를 받고 나서는 그 주의 incremental은 더 이상 필요가 없으므로 삭제를 해도 된다. 마찬가지로 월 초에 export를 받은 후에는 지난 달의 incremental, cumulative export는 삭제해도 된다. 만약 오늘이 17일이고 db가 완전히 유실되었다고 가정해 보자. 다음과 같은 절차로 복구할 수 있을 것이다. 1. db를 새로 생성한다. 2. system table들에서 가장 최근의 data들을 가져오기 위해서, 가장 최근의 export file을 이용하여 SYSTEM import(INCTYPE=SYSTEM)을 수행한다. (예에서는 16일자 incremental export) 3. 가장 최근의 complete export file을 이용하여 RESTORE import (INCTYPE=RESTORE)를 수행한다.(예에서는 1일자 complete export) 4. 위의 complete export 이후의 모든 cumulative export file을 이용하여 RESTORE import를 수행한다.(예에서는 5일, 12일의 cumulative export) 5. 마지막 cumulative export 이후의 모든 incremental export file을 이용하여 RESTORE import를 수행한다.(예에서는 15일, 16일의 incremental export) 가장 최근의 export file은 복구 작업의 시작과(INCTYPE=SYSTEM) 마지막에 (INCTYPE=RESTORE) 각각 다른 INCTYPE으로 import된다는 사실에 주목한다. incremental, cumulative export 시 export되는 정보들 -------------------------------------------------- 1. 모든 system object들 (tablespace, rollback segment, user privilege 등을 포함, temporary segment는 제외) 2. drop된 object에 대한 정보 3. 마지막 export 이후에 생성된 cluster, table, view, sysnonym 등 4. 변경(update, insert, delete 등)이 발생한 모든 table들 COMMAND SYNTAX -------------- export : exp username/password inctype=complete or exp username/password inctype=cumulative or exp username/password inctype=incremental import : imp username/password inctype=system 가장 최근의 export file에서 system data를 import할 때 사용한다. (실제 user data를 restore import하기 전에 반드시 수행해야 함) or imp username/password inctype=restore 수행 예 ------- 위의 일정표에 의거하여 수행한 예이다. 일자 command --------------------------------------------------------------- 1 월 exp system/manager inctype=complete file=base.dmp 2 화 exp system/manager inctype=incremental file=inc1 3 수 exp system/manager inctype=incremental file=inc2 4 목 exp system/manager inctype=incremental file=inc3 5 금 exp system/manager inctype=comulative file=cum1 (inc1, inc2, inc3는 이 시점에 삭제해도 무방하다.) 8 월 exp system/manager inctype=incremental file=inc4 9 화 exp system/manager inctype=incremental file=inc5 10 수 exp system/manager inctype=incremental file=inc6 11 목 exp system/manager inctype=incremental file=inc7 12 금 exp system/manager inctype=comulative file=cum2 (inc4, inc5, inc6, inc7은 이시점에 삭제해도 무방) 15 월 exp system/manager inctype=incremental file=inc8 16 화 exp system/manager inctype=incremental file=inc9 17 수 db 유실됨. 다음과 같이 복구함. imp system/manager inctype=system full=y file=inc9 imp system/manager inctype=restore full=y file=base.dmp imp system/manager inctype=restore full=y file=cum1 imp system/manager inctype=restore full=y file=cum2 imp system/manager inctype=restore full=y file=inc8 imp system/manager inctype=restore full=y file=inc9



TOPIC 14. EXPORTING ORACLE8 TO IMPORT TO ORACLE7
oracle 8의 내용을 oracle 7으로 import 시 다음과 같은 에러가 발생한다. RC73:/mnt3/rctest73/server> imp exp_test/exp_test file=exp_test.dmp Import: Release 7.3.4.1.0 - Production on Thu Apr 22 14:25:39 1999 Copyright (c) Oracle Corporation 1979, 1996. All rights reserved. Connected to: Oracle7 Server Release 7.3.4.1.0 - Production With the distributed, replication, parallel query and Spatial Data options PL/SQL Release 2.3.4.1.0 - Production IMP-00010: not a valid export file, header failed verification IMP-00021: operating system error - error code (dec 2, hex 0x2) IMP-00000: Import terminated unsuccessfully RC73:/mnt3/rctest73/server> 이러한 문제는 오라클 7의 export dump file의 header 정보에서 오라클 8으로 버전이 올라오면서 추가적인 정보(eg. NCHAR character set)가 늘어나서 오라클 8 에서 export한 화일을 오라클 7의 imp utility가 읽어내지 못하는 데서 비롯된다고 할 수 있다. 이러한 문제점을 해결하기 위한 script가 $ORACLE_HOME/rdbms/admin/catexp7.sql임. 이것은 오라클 8 데이타베이스에 대해서 오라클 7대와 같은 style의 export/import view들을 만들어 주는 역할을 한다. 이러한 view는 오라클 8의 object들은 볼 수 없으므로 오라클 7대와 같은 형태의 object들만 export될 수 있다. 다음은 export / import 하는 절차를 간단하게 보여주고 있다. 1. oracle 8 으로 접속하여 svrmgrl을 수행 후 connect internal을 해준 후 다음을 수행. SVRMGR> @?/rdbms/admin/catexp7.sql 2. oracle 7 으로 접속하여 oracle 7의 export utility를 이용해서 export를 받는다. 이 때 oracle 8을 가리키는 tns name을 이용해서 export받는다. exp exp_test/exp_test@ora80 file=exp_test.dmp 3. 이렇게 export받은 dump 화일을 이용해서 oracle 7으로 import를 받는다. imp system/manager file=exp_test.dmp fromuser=exp_test touser=scott 4. oracle 8의 sys user(system이 아님)로 catexp.sql을 다시 수행해 주어서 export/import 관련 view들을 생성해 준다. SVRMGR> @?/rdbms/admin/catexp.sql



TOPIC 15. (V8.X)USER LEVEL, TABLE LEVEL EXPORT/IMPORT 방법 및 FAQ
export를 받는 user 별로 또는 table 별로 어떤 옵션을 사용하는가에 대한 문의를 중심으로 실제 export/import하는 예제를 알아보기로 한다. system user가 export 시에 한번에 두 명 이상의 user의 오브젝트를 지정하여 export받는 것이 가능하며, 일반 user가 export를 수행할 경우에도 한 번에 두 개 이상의 table을 한꺼번에 export받을 수 있습니다. user level로 받는 예제와 table level로 받는 다양한 예제를 소개합니다. - system user가 한 user의 모든 오브젝트를 export 수행하는 명령 1. system user로 export/import하는 예 exp system/manager file=aaa.dmp owner=a_user buffer=1000000 log=exp.log imp system/manager file=aaa.dmp fromuser=a_user touser=b_user ignore=y commit=y buffer=1000000 log=exp.log 2. system user로 export받은 것은 반드시 system user로 import해야 합니다. - user level export/import 방법. 사용자 모드 export 방법에는 두 가지가 있습니다. 1. 사용자 자신이 만든 모든 오브젝트를 그 user가 export하는 방법입니다. exp scott/tiger file=myexp.dmp (on unix) exp80 scott/tiger file=myexp.dmp (on winnt) 2. system/manager로 접속한 DBA가 여러 user 소유의 오브젝트들을 export 하는 방법입니다. exp system/manager owner=scott raghu file=user.dmp (on unix) exp80 system/manager owner=scott raghu file=user.dmp (on winnt) 위의 두 가지 방법은 user export로 분류됩니다. 두번 째 방법의 경우에는 import를 할 때에도 DBA 권한이 있어야 합니다. FROMUSER/TOUSER 옵션은 2번 방법으로 생성된 export 화일을 import할 때에 사용될 수 있습니다. - table level export/import 방법 1. system user로 table 몇 개만 export/import하는 예 exp system/manager file=exp.dmp tables='(pan.BBS_DATA_ID, pan.BBS_MAIL)' compress=n buffer=100000 log=exp.log => 위와 같이 table의 schema(user)명까지 지정해야만 export가 성공합니다. imp system/manager file=exp.dmp tables='(pan.BBS_DATA_ID, pan.BBS_MAIL)' commit=y ignore=y buffer=100000 log=imp.log => 위와 같이 import 수행하시면 성공합니다. 2. pan user로 table 몇 개만 export/import하는 예 exp pan/pan file=exp.dmp tables='(BBS_DATA_ID, BBS_MAIL)' compress=n buffer=100000 log=exp.log => user가 자신의 table을 export할 때에는 schema 명을 지정할 필요 없습니다. imp pan/pan file=exp.dmp tables='(BBS_DATA_ID, BBS_MAIL)' commit=y ignore=y buffer=100000 log=imp.log => 위와 같이 import 수행하시면 성공합니다. - export/import 에 관한 FAQ(Frequently Asked Question) 1. exp80 system/manager owner=scott raghu file=user.dmp (on winnt) 만약, 위와 같은 명령 수행 시 에러가 나면 owner='(scott, raghu)' 와 같이 single quote와 owner 명 사이에 comma를 주고 export를 수행합니다. 2. dba role이 없는 db user는 full=y 옵션으로 export를 받을 수 없습니다. 3. export 받을 때 function, procedure, package, trigger만 별도로 받거나 또한 제외시키고 export를 수행하는 것은 불가능합니다. dba가 full=y 옵션으로 export를 받을 때 속도와 저장 공간이 문제라면 먼저 user level로 export를 수행하고, rows=n 옵션과 함께 받으면 속도가 빠릅니다. 즉, export를 받을 때 procedure, trigger만 export받기를 원한다면 owner 단위로 받으면서 rows=n 옵션을 주고 export를 수행합니다. 4. 양쪽 db 모두의 nls_characterset을 맞추어 놓고 export/import를 수행해야 하고, (가능하면 us7ascii -> ko16ksc5601) oracle 8부터는 ko16ksc5601을 us7ascii로 바꾸게 되면 이미 저장되어 있는 한글 데이타에 기본적으로 문제가 있을 수 있습니다. 그렇지 않으면 아래 제목의 export dump 화일의 character set 변환 프로그램을 이용하도록 하십시오. <BUL:10159> EXPORT 받은 화일의 CHARACTER SET 변경 프로그램 위와 같은 제목의 Technical Bulletin을 찾으실 수 있습니다. 5. import 시에 ignore=y를 주시는 것은 똑같은 이름의 tablespace나 table이 import할 db에 이미 만들어져 있는 경우 export dump 화일로부터 같은 tablespace, table을 만들려고 할 때 에러가 날 것인데, 이것을 무시하고 오브젝트의 구조는 기존의 것을 따라가고, data만 기존에 들어 있는 row들에 추가하여 넣겠다는 뜻입니다. (다만, 원본과 똑같은 data들을 유지하려면 import할 db에는 tablespace, table의 구조만 만들어놓고, 기존의 table data는 지워 놓고 import를 수행해야 합니다.) 6. 다른 서버의 다른 user에게 import할 때에도 fromuser/touser 옵션과 함께 위에 소개한 예제를 사용하시면 됩니다. export 받은 dump 화일을 실제 text file로 열어볼 수 있는 방법에 대한 자료는 아래의 자료를 참조하십시오. <BUL:11180> EXPORT받은 DUMP FILE을 이용하여 IMPORT SCRIPT받기(SHOW와 INDEXFILE 이용). export받은 dump 화일을 이용하여 database 내의 object 생성문을 얻어내는 방법입니다. 7. 6번과도 연관이 있는 내용인데, EXPORT/IMPORT 를 이용하여 TABLE과 INDEX를 분리하는 방법에 대해서는 다음의 자료를 참조하시면 됩니다. <BUL:11000> EXPORT/IMPORT 를 이용하여 TABLE과 INDEX를 분리하는 방법



TOPIC 16. ORACLE 8I EXPORT의 QUERY OPTION 기능
Oracle 8i에서는 export 작업 수행 시 Query Option을 이용하여 테이블의 부분적인 추출이 가능하다. SQL> select empno, ename, job, sal from emp order by job; EMPNO ENAME JOB SAL ---------- ---------- --------- ---------- 7788 SCOTT ANALYST 3000 7902 FORD ANALYST 3000 9999 홍길동 ANALYST 2000 7369 SMITH CLERK 800 7876 ADAMS CLERK 1100 7934 MILLER CLERK 1300 7900 JAMES CLERK 950 7566 JONES MANAGER 2975 7782 CLARK MANAGER 2450 7698 BLAKE MANAGER 2850 7839 KING PRESIDENT 5000 7499 ALLEN SALESMAN 1600 7654 MARTIN SALESMAN 1250 7844 TURNER SALESMAN 1500 7521 WARD SALESMAN 1250 위와 같이 구성된 EMP 테이블에서 만일 'MANAGER'로 JOB을 가진 사원중 SAL 컬럼이 2500이상인 레코드를 export하고 싶다면, 다음과 같이 수행하면 된다. % exp scott/tiger tables=emp query=\"where job=\'MANAGER\' and sal\>=2500\" Export: Release 8.1.5.0.1 - Production on Tue Sep 19 16:14:15 2000 ... About to export specified tables via Conventional Path ... . . exporting table EMP 2 rows exported Export terminated successfully without warnings. 한글 컬럼에 대해서도 동일한 where 조건에 지정이 가능하다. % exp scott/tiger tables=emp query=\"where ename like \'홍%\'\" V8.1.5 버젼에서 제공되는 Query 옵션의 특징: 1. 테이블 레벨의 export 명령어에서만 가능하다. 2. Direct 옵션과 함께 사용될 수 없다. 3. Nested 테이블을 갖는 테이블에는 적용할 수 없다. 4. Partition 테이블에 대한 export에도 적용가능하다. 5. Import 명령에는 적용되지 않는다.



TOPIC 17. ORACLE 버젼간 EXPORT/IMPORT 상호 호환성 참조표
버젼이 상이한 데이타베이스간의 export/import 작업은 작업 수행시 반드시 상호 호환성을 확인하여야 하며, 호환성이 없는 버젼간의 작업은 IMP-9 또는 IMP-10 오류와 함께 작업이 실패하게 된다. 다음은 V8.0 미만의 버젼으로 import하고자 할 때 사용될 export 도구의 버젼 정보이고, +----------+-----------------------------------+ | EXPORT | IMPORT to | | from +--------+--------+--------+--------+ | | 7.0.x | 7.1.x | 7.2.x | 7.3.x | +----------+--------+--------+--------+--------+ | 7.0.x | EXP70x | EXP70x | EXP70x | EXP70x | | 7.1.x | EXP70x | EXP71x | EXP71x | EXP71x | | 7.2.x | EXP70x | EXP71x | EXP72x | EXP72x | | 7.3.x | EXP70x | EXP71x | EXP72x | EXP73x | +----------+--------+--------+--------+--------+ | 8.0.x 주1| EXP70x | EXP71x | EXP72x | EXP73x | | 8.1.x 주1| EXP70x | EXP71x | EXP72x | EXP73x | +----------+--------+--------+--------+--------+ 다음은 V8.0 이상의 버젼으로 import하고자 할 때 사용될 export 도구의 버젼 정보이다. +--------+--------------------------------------------------------------+ | EXPORT | IMPORT to | | from +--------+--------+--------+--------+--------+--------+--------+ | | 8.0.3 | 8.0.4 | 8.0.5 | 8.0.6 | 8.1.5 | 8.1.6 | 8.1.7 | +--------+--------+--------+--------+--------+--------+--------+--------+ | 7.x 주2| EXP7x | EXP7x | EXP7x | EXP7x | EXP7x | EXP7x | EXP7x | +--------+--------+--------+--------+--------+--------+--------+--------+ | 8.0.3 | EXP803 | EXP803 | EXP803 | EXP803 | EXP803 | EXP803 | EXP803 | | 8.0.4 | EXP803 | EXP804 | EXP804 | EXP804 | EXP804 | EXP804 | EXP804 | | 8.0.5 | EXP803 | EXP804 | EXP805 | EXP805 | EXP805 | EXP805 | EXP805 | | 8.0.6 | EXP803 | EXP804 | EXP805 | EXP806 | EXP806 | EXP806 | EXP806 | +--------+--------+--------+--------+--------+--------+--------+--------+ | 8.1.5 | EXP803 | EXP804 | EXP805 | EXP806 | EXP815 | EXP815 | EXP815 | | 8.1.6 | EXP803 | EXP804 | EXP805 | EXP806 | EXP815 | EXP816 | EXP816 | | 8.1.7 | EXP803 | EXP804 | EXP805 | EXP806 | EXP815 | EXP816 | EXP817 | +--------+--------+--------+--------+--------+--------+--------+--------+ * 주의 사항 * 주1.Oracle8이나 Oracle8i 데이타베이스를 Oracle7 데이타베이스로 import하고자 하는 경우에는, import 수행 전 반드시 Oracle8이나 Oracle8i 데이타베이스를 대상으로 SYS 사용자로 CATEXP7.SQL 스크립트를 수행하여야 함. 주2.Oracle7 export dump 화일을 Oracle8이나 Oracle8i 데이타베이스로 import 하는 경우에는 DATE 타입의 컬럼에 지정되어 있는 제약조건이 invalid 상태로 변함. 기타 주의사항으로는, 1. 상위 버젼의 데이타베이스에 대해 exp 명령을 사용할 경우에는 반드시 tns alias를 이용한 SQL*Net 접속이 필요하며, 2. DIRECT path export 방식은 지원하지 않으므로, CONVENTIONAL path 방법만을 사용하여야 한다. 현재 운영중인 데이타베이스가 유지하고 있는 export와 import 관련 뷰의 버젼을 확인하기 위해서는 다음 명령어를 이용할 수 있고, 값에 해당하는 버젼 번호는 아래 표와 같다. SQL> SELECT * FROM sys.props$ WHERE name LIKE 'EXPORT%'; NAME VALUE$ COMMENT$ ------------------------- ----------- ------------------------ EXPORT_VIEWS_VERSION 8 Export views revision # +-------------------------------+ | EXPORT_VIEWS_VERSION | +-------+-----------------------+ | Value | Introduced in Release | +-------+-----------------------+ | 1 | 7.1.3 | | 2 | 7.2.1 | | 3 | 7.2.3 | | 4 | 8.0.1 | | 5 | 8.0.2 | | 6 | 8.0.3 | | 7 | 8.0.4 | | 8 | 8.1.6 | +-------+-----------------------+



TOPIC 18. EXPORT FILE을 SPLIT하여 생성하는 방법
Export file의 크기가 2GB 제한에 걸리게 되면 File Size를 줄이는 방법을 강구하여야 하는데 여기에는 다음과 같은 방법들이 있다. 1) User 또는 Table 단위로 export를 하여 export file size를 줄인다. 2) Unix PIPE를 사용하여 export file을 Compress한다. 그러나 위 두 방법으로도 2GB 제한을 해결하지 못하는 경우가 있다. 이때에는 제한적이긴 하지만 Export file을 Split하는 것을 고려해 볼 수 있다. 아래에 그 방법을 소개한다. * 아래의 예제는 KORN SHELL(KSH)에서만 유효하다는 것을 명심할 것* @ Unix Pipe와 Split 명령의 사용 - Export command: echo|exp file=>(split -b 1024m - expdmp-) userid=scott/tiger tables=X - Import command: echo|imp file=<(cat expdmp-*) userid=scott/tiger tables=X @ Splitting 과compressing 을 동시에 수행. - Export command: echo|exp file=>(compress|split -b 1024m - expdmp-) userid=scott/tiger tables=X - Import command: echo|imp file=<(cat expdmp-*|zcat) userid=scott/tiger tables=X



TOPIC 19. LARGE EXPORT FILE의 SPLITTING 방법
Oracle 8i 에서는 OS의 filesize보다 큰 export file에 대한 filesize option 을 제공하여 export file을 split할 수 있다. 따라서 2G 의 limit에 걸린 export file에 대해 O/S 상의 compress나 split을 사용할 필요가 없어졌다. FILESIZE VALUE. FILESIZE=0 (default) Causes one file. FILESIZE=1024 Causes 1K files to be generated. FILESIZE=1K Same as above. FILESIZE=1M Causes 1Meg files to be generated. FILESIZE=1G Causes 1Gig files to be generated. ## Example 3G ORDERS table 을 3개의 export file로 나누어서 export. three 1G export files. exp demo/demo file=(orders_1.dmp,orders_2.dmp,orders_3.dmp) log=orders.log filesize=1g tables=orders ## Test CKCHOI:/home13/rctest8i/server/ckchoi> exp boss/boss file=x1,x2,x3,x4 filesize=1M Export: Release 8.1.6.0.0 - Production on Thu Jul 5 09:47:20 2001 (c) Copyright 1999 Oracle Corporation. All rights reserved. Connected to: Oracle8i Enterprise Edition Release 8.1.6.0.0 - Production With the Partitioning option JServer Release 8.1.6.0.0 - Production Export done in KO16KSC5601 character set and KO16KSC5601FIXED NCHAR character set About to export specified users ... . exporting pre-schema procedural objects and actions . exporting foreign function library names for user BOSS . exporting object type definitions for user BOSS About to export BOSS's objects ... . exporting database links . exporting sequence numbers . exporting cluster definitions . about to export BOSS's tables via Conventional Path ... . . exporting table AA 65536 rows exported . . exporting table AAA 3 rows exported . . exporting table AB 8 rows exported . . exporting table AC 8 rows exported . . exporting table ADATE 1 rows exported . . exporting table ASAS 0 rows exported . . exporting table ASDF 5 rows exported . . exporting table BONUS 0 rows exported . . exporting table DEPT 4 rows exported . . exporting table DUMMY 1 rows exported . . exporting table DUMMY_Y 0 rows exported . . exporting table DUMMY_Z 0 rows exported . . exporting table EE 65536 rows exported . . exporting table EEE 0 rows exported . . exporting table EESS 14 rows exported . . exporting table EMP 14 rows exported . . exporting table EMP1 continuing export into file x2.dmp continuing export into file x3.dmp continuing export into file x4.dmp 57344 rows exported . . exporting table EMP11 1 rows exported . . exporting table EMPTTT 6 rows exported . . exporting table EMP_TEST 19 rows exported . . exporting table FF 0 rows exported . . exporting table FFF 0 rows exported . . exporting table FFF1 0 rows exported . . exporting table FI 6 rows exported . . exporting table LLL 2 rows exported . . exporting table LLLLL 0 rows exported . . exporting table LONGTAB 1 rows exported . . exporting table LONGTAB2 1 rows exported . . exporting table LONTAB 4 rows exported . . exporting table MLOG$_DEPT 7 rows exported . . exporting table MLOG$_EMP_TEST 0 rows exported . . exporting table MO 12 rows exported . . exporting table N 10 rows exported . . exporting table NN 0 rows exported . . exporting table NUM 1 rows exported . . exporting table PART_TBL . . exporting partition PART_TBL_03 0 rows exported . . exporting partition PART_TBL_04 0 rows exported . . exporting partition PART_TBL_05 0 rows exported . . exporting table PLAN_TABLE 0 rows exported . . exporting table PP 0 rows exported . . exporting table PPP 0 rows exported . . exporting table P_EMP . . exporting partition EMP_P1 8 rows exported . . exporting partition EMP_P2 5 rows exported . . exporting table RUPD$_DEPT . . exporting table RUPD$_EMP_TEST . . exporting table SALGRADE 5 rows exported . . exporting table SSTEST 1 rows exported . . exporting table TBL 0 rows exported . exporting synonyms . exporting views . exporting stored procedures . exporting operators . exporting referential integrity constraints . exporting triggers . exporting indextypes . exporting bitmap, functional and extensible indexes . exporting posttables actions . exporting snapshots . exporting snapshot logs . exporting job queues . exporting refresh groups and children . exporting dimensions . exporting post-schema procedural objects and actions . exporting statistics Export terminated successfully without warnings. CKCHOI:/home13/rctest8i/server/ckchoi> ls -als x* 2048 -rw-r--r-- 1 rctest8i dba 1048576 Jul 5 09:47 x1.dmp 2048 -rw-r--r-- 1 rctest8i dba 1048576 Jul 5 09:47 x2.dmp 2048 -rw-r--r-- 1 rctest8i dba 1048576 Jul 5 09:47 x3.dmp 840 -rw-r--r-- 1 rctest8i dba 430080 Jul 5 09:47 x4.dmp CKCHOI:/home13/rctest8i/server/ckchoi> CKCHOI:/home13/rctest8i/server/ckchoi> imp boss/boss file=x1,x2,x3,x4 filesize=1M full=y show=y log=imp.log Connected to: Oracle8i Enterprise Edition Release 8.1.6.0.0 - Production With the Partitioning option JServer Release 8.1.6.0.0 - Production Export file created by EXPORT:V08.01.06 via conventional path import done in KO16KSC5601 character set and KO16KSC5601FIXED NCHAR character set . importing BOSS's objects into BOSS "CREATE DATABASE LINK "BOSSRAIN" CONNECT TO "BOSS" IDENTIFIED BY "BOSS" USIN" "G 'ckchoi'" "CREATE DATABASE LINK "KIMDH" CONNECT TO "BOSS" IDENTIFIED BY "BOSS" USING '" "kimdh'" "CREATE DATABASE LINK "KIMDH.WORLD" CONNECT TO "BOSS" IDENTIFIED BY "BOSS" U" "SING 'kimdh'" "CREATE DATABASE LINK "RC734KO" CONNECT TO "BOSS" IDENTIFIED BY "BOSS" USING" " 'rc734ko'" . . . . . . . . . . . . "ALTER PROCEDURE "TT" COMPILE TIMESTAMP '2001-06-14:18:03:22'" "BEGIN SYS.DBMS_SNAPSHOT_UTL.SYNC_UP_LOG('BOSS','DEPT'); END;" "BEGIN SYS.DBMS_SNAPSHOT_UTL.SYNC_UP_LOG('BOSS','EMP_TEST'); END;" "CREATE SNAPSHOT LOG ON "BOSS"."DEPT" WITH PRIMARY KEY USING ("MLOG$_DEPT", " "(3, 'CKCHOI', 98, '2001-04-20:12:05:53', '2001-04-20:12:05:53', '2001-04-20" ":12:05:53', 1, "DEPTNO", '2001-04-20:12:05:53', 2, 0, ("RUPD$_DEPT")))" "CREATE SNAPSHOT LOG ON "BOSS"."EMP_TEST" WITH PRIMARY KEY USING ("MLOG$_EMP" "_TEST", (3, 'CKCHOI', 98, '2001-05-28:15:07:44', '2001-05-28:15:07:44', '20" "01-05-28:15:07:44', 1, "EMPNO", '2001-05-28:15:07:44', 2, 0, ("RUPD$_EMP_TE" "ST")))" "BEGIN dbms_job.isubmit(job=>5,what=>'dbms_refresh.refresh(''"BOSS"."EMP_T" "EST"'');',next_date=>to_date('2001-05-22:15:50:43','YYYY-MM-DD:HH24:MI:SS')" ",interval=>'sysdate+(1/24/60/60) ',no_parse=>TRUE); END;" "BEGIN null; END;" "BEGIN dbms_refresh.make('"BOSS"."EMP_TEST"',list=>null,next_date=>null,in" "terval=>null,implicit_destroy=>TRUE,lax=>FALSE,job=>5,rollback_seg=>NULL,pu" "sh_deferred_rpc=>TRUE,refresh_after_errors=>FALSE,purge_option => 1,paralle" "lism => 0,heap_size => 0); END;" "ALTER TABLE "DEPT" ENABLE CONSTRAINT "DEPT_DEPTNO_PK"" "ALTER TABLE "EMP_TEST" ENABLE CONSTRAINT "EMP_EMPNO_PK1"" "ALTER TABLE "LLL" ENABLE CONSTRAINT "LLL_AA_PK"" "ALTER TABLE "PPP" ENABLE CONSTRAINT "AAA_ABCD_PK"" "ALTER TABLE "EMP1" ENABLE CONSTRAINT "EMP1_DEPTNO_FK"" "ALTER TABLE "FFF1" ENABLE CONSTRAINT "FFF_AB_FK"" Import terminated successfully without warnings. CKCHOI:/home13/rctest8i/server/ckchoi> ########################################################################### reference to <Note:108639.1> <Note:75109.1>