Export / Import

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 /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 /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= & # Write from pipe to tape % exp file=/tmp/exp_pipe # Export to the pipe 4. PIPE와 DD를 이용한 tape의 import % mknod /tmp/imp_pipe p # Make the pipe % dd if= of=/tmp/imp_pipe & # Write from tape to pipe % imp file=/tmp/imp_pipe # Import from the pipe 5. PIPE 와 DD를 이용한 remote server의 tape device에 export하기 % mknod /tmp/exp_pipe p % dd if=/tmp/exp_pipe | rsh dd of= & % exp file=/tmp/exp_pipe 6. PIPE 와 DD 를 이용한 remote server의 tape device에서 import하기 % mknod /tmp/imp_pipe p % rsh dd if= 7. TAPE에 있는 DATA FILE을 SQL*LOADER로 받기. % mknod /tmp/load_pipe p % dd if= of=/tmp/load_pipe & (주의) 만약 tape이 EBCDIC이면 다음 명령으로 ASCII로 바꾸어 줍니다. % dd if=

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 은 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를 얻을 수는 있으나, " "로 묶여 있어 바로 사용하기에는 번거로운 단점이 있다.  [출처] export / import(1)|작성자 후리