EXPORT 시 QUERY OPTION에 대한 사용 예(ORACLE 8I 이상)
============================================
PURPOSE
============
oracle 8i에서 export 시 query option에 대한 사용 예
8i에서 export의 query syntax 를 이용하여 table data의 한 부분만 exporting 이 가능
-------------------------------------------------------------------------
- 8i 에서 select 문장의 where 절을 사용하는 것처럼 export 시에 부분적으로 table data 를 받아 낼수 있는 기능을 소개 한다.
- Direct 옵션은 사용될 수 없다..
- where 절에 해당하는 export utility는 query parameter 를 사용한다.
UNIX syntax:
----------------
- Example:
1.SCOTT.Emp table의 ename 이 JAME과 비슷한 이름의 data 를 export ..
exp scott/tiger query=\"where ename like \'JAME%\'\" tables=emp file=exp.dmp log=exp.log
2. employee와 cust table에서 new york 주의 data 만 export ..
exp scott/tiger query=\"where st=\'NY\'\" tables=(employee,cust) file=exp.dmp log=exp.log
query 문장에서 UNIX reserved characters( ", ', ,< .. 등) 를 사용하는 경우에는 escape ('\') 을 반드시 사용해야 한다.
예)query=\"where JOB = \'SALESMAN\' and salary \< 1600\"
더 중요한 것은 command line에서 export option을 사용할때는 반드시 escape 이 있어야 하나
parfile을 사용할때는 eacape이 불필요하다.
예를 보면 .. p라는 이름의 file을 다음과 같이 생성
tables=emp query="where job='SALESMAN'"
parfile을 이용해서 export 를 실행해 보면
[rmtdchp6]/apac/rdbms/64bit/app/oracle/product/9.2.0> exp scott/tiger parfile=p
Export: Release 9.2.0.4.0 - Production on Wed Mar 17 00:12:34 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses KO16KSC5601 character set (possible charset conversion)
About to export specified tables via Conventional Path ...
. . exporting table EMP 4 rows exported
와 같이 정상 처리 됨을 알수 있다.
만일 command line에서 위의 내용을 실행하게 되면 다음과 같이 error 를 만난다.
exp scott/tiger tables=emp query="where job='SALESMAN'"
LRM-00101: unknown parameter name 'job'
EXP-00019: failed to process parameters, type 'EXP HELP=Y' for help
EXP-00000: Export terminated unsuccessfully
command line에는 query 내에 single(')나 double quotes(") 를 사용한다면 반드시 double quotes(") 를 사용하여
query 문을 묶어야 한다.그러나 query 내에서 single ('')나 double quotes(") 를 사용하지 않는다면 single quotes (')을 사용하여
query 문을 수행할 수도 있다..
다음 예를 보면..
1>exp scott/tiger tables=emp query=\'where deptno=20\'
Export: Release 9.2.0.4.0 - Production on Wed Mar 17 00:22:00 2004
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to: Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses KO16KSC5601 character set (possible charset conversion)
About to export specified tables via Conventional Path ...
. . exporting table EMP 4 rows exported
2>exp scott/tiger tables=emp query=\'where job=\'SALESMAN\'\'
LRM-00112: multiple values not allowed for parameter 'query'
EXP-00019: failed to process parameters, type 'EXP HELP=Y' for help
EXP-00000: Export terminated unsuccessfully
즉.. 정리를 하자면
command line에서 query 내에 '," 을사용하지 않는 다면 '나 " 으로 query option을 사용할수 있다
query=\'where deptno = 20\'
query=\"where deptno = 20\"
query=\'where deptno \< 2\'
(이 경우 single 이나 double quotes 을 둘다 사용할수 있다.)
parfile을 사용하는 경우에는 다음과 같이 단순하게 사용이 가능하다.
query='where deptno = 20'
query="where deptno = 20"
query='where deptno < 20'
WINDOWS NT / 2000 와 NETWARE syntax:
---------------------------------------------------------
다음의 자료를 참조바란다.
Example:
EXP demo/demo tables=emp file=exp1.dmp query="""where deptno>30"""
double quotes(") 를 둘러 싸는 경우에는 space 가있으면 안된다.
parfile의 사용은 다음과 같이 하시면 됩니다.
file=exp66.dmp
query="where deptno > 20"
tables=(emp)
log=log66.txt
userid=scott/tiger
Explanation
-----------
Windows NT or Win2000의 경우 command line에서는 3 double quotes 이 필요하고
'PARFILE 을 사용하는 경우에는 double quotes(") 한번만 필요함
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 명령에는 적용되지 않는다.
1) INCREMENTAL, CUMULATIVE, COMPLETE EXPORT & IMPORT
=================================================
Purpose
-------
'Incremental', 'Cumulative', 'Complete' Export가 무엇이며, 어떻게
효과적인 backup 전략으로 사용할 수 있는지를 알아본다.
SCOPE
-----
8~10G Standard Edition 에서는 'Incremental', 'Cumulative', 'Complete' 지원하지 않는다.
Explanation
-----------
1. 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된다는 사실에 주목한다.
2. 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들
3. 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
Example
-------
위의 일정표에 의거하여 수행한 예이다.
일자 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
2) 테이블 LEVEL EXPORT 방법의 종류가 하나 이상 있습니까?
▶▶ 말씀드리자면 대답은 그렇기도 하고 아니기도 합니다. 테이블 export는 두
가지 방법 중 하나가 될 수 있습니다.
--- 사용자가 그 소유한 테이블을 export 한다.
exp donald/duck tables=huey, dewey, louie
--- SYSTEM/MANAGER 같은 DBA가 사용자의 집합에 속해 구분되어진 테이블
들을 export 한다.
exp system/manager tables=scott.emp, humty, dumpty
위의 두가지 export 방법 모두 테이블 level의 export로 구분되어집니다.
후자의 경우에는 export가 DBA에 의해서 행해지기 때문에 import도 DBA에
의해서 행해져야 합니다.
Q> FULL EXPORT 를 받으려면 사용자가 반드시 DBA 이어야 합니까?
▶▶ 아닙니다. 버전 6 에서는 그러했지만, 이는 오라클7 role 의 introduction
에서 바뀌었습니다. 다시 말해서, EXP_FULL_DATABASE role 을 받은 어떤 사용자도
FULL export 를 할 수 있습니다. 이 role 은 DBA 에 의해서 부여됩니다. 따라서,
여전히 DBA 가 아니면서도 위의 role 을 부여받은 사용자가 있을 수 있습니다.
위의 role 과 동반되는 privilege 들은 CATEXP.SQL 에 정의되어 있습니다.
privilege 들을 살펴보면 이 role 을 소유한 사용자는 DBA 와 거의 같은 역할을
할 수 있음을 알 수 있습니다.
Q> EXPORT 되는 객체들의 순서는 어떻게 됩니까?
▶▶ 오라클7 에서 export 되는 객체들의 순서는 다음과 같습니다. 위에서 아래쪽
으로 row 별로 왼쪽에서 오른쪽 순서로 읽으시면 됩니다.
Tablespaces Profiles Users Roles
System Privilege Role Grants Default Roles Tablespace
Quotas
Resource Costs Rollback Segments Database Links Sequences
(includes grants)
Snapshots Snapshot Logs Job Queues Refresh Groups
(includes grants,
auditing)
Cluster Definitions Tables(constraints, Referential POSTTABLES
grants, indexes, Integrity actions
comments, audits)
In 7.3.4 the order for
tables will be changed
to:(indexes, grants,
constraints, audits,
comments)
Synonyms Views Stored Triggers
Procedures
Default and System
Auditing
Q> 순서가 중요합니까? 만약 그렇다면 왜죠?
▶▶ 순서는 매우 중요합니다. Import 가 데이터베이스에 대한 SQL 문장들을 실행
하는 연속적인 session 이기 때문입니다. 다른 이미 존재하는 어떤 객체들에 의존
하는 몇몇 객체들은 반드시 더 이후에 위치해야 합니다. 예를 들어, 트리거는
테이블에 의존적 객체이므로 테이블이 트리거보다 먼저 import 되어져야 합니다.
또, 프로시져나 뷰같은 홀로 존재할 수 있는 객체들도 있습니다. 이러한 객체들은
compilation errors 과 함께 데이터베이스에 load 될 수 있고, 이는 처음으로 사용
될 때 비로소 validation 이 체크 됩니다.
Q> EXPORT 는 ARRAY FETCH 라 불리우는 메카니즘을 사용하는데, 이게 무엇입니까?
▶▶ Export 는 SELECT 문장을 만들어서 테이블 데이터를 가져옵니다. 즉, 데이터는
데이터베이스로부터 사용자 쪽으로 옮겨져야 하는데, 만약 Export 가 한번에 단
하나의 row 만 가져오게 되어 있다면 데이터베이스를 Export 하기 위해서는 너무
많은 부하가 걸릴 것입니다. 따라서, Export 는 매번 row 들의 집합을 fetch 해오게
되고, 총 수행시간은 감소하게 됩니다. Array fetch 는 데이터베이스로부터 한번에
여러개의 row 들을 가져오는 개념입니다.
Q> EXPORT 시의 BUFFER PARAMETER 는 어떤 목적으로 사용됩니까?
▶▶ 이전에 언급한 바와 같이, Export 는 한번에 여러개의 row 들을 fetch 합니다. 이러한 정보는 화일로 저장되기 이전에 사용자 쪽의 메모리에 올라가게 됩니다.
사용자에게 할당되는 메모리의 용량이 바로 BUFFER parameter 의 값과 대응하게
됩니다.
Q> EXPORT 시의 RECORDLENGTH PARAMETER 는 무엇입니까?
▶▶ Export 시 export 화일로 정보를 쓸때, 한번에 한 글자씩을 써내려가지 않고
버퍼의 정보를 한번에 기록하게 됩니다. RECORDLENGTH 는 이 버퍼의 크기입니다.
O/S 블럭 크기의 배수로 이를 관리하는 것이 가장 효율적입니다.
또, 이는 이전에 설명된 데이터를 가져올 때에만 사용되는 BUFFER parameter 와
종종 혼동됩니다. 두가지 버퍼가 있는 이유는 쓰기 버퍼가 SQL 문장들을 포함할 수
있기 때문입니다. 또한 데이터베이스로부터 자료를 가져올때 이는 export 화일
형태로 format 되어 있지 않습니다. 따라서, 데이터를 올바른 format 형태로 얻을
수 있도록 몇몇 메세지들도 포함되어 있습니다.
Q> 얼마나 많은 ROW 들이 한 주기에서 FETCH 되는 지 어떻게 알 수 있습니까?
▶▶ BUFFER parameter 에서 정의된 것 처럼 이 값은 버퍼의 크기를 한 row 의
크기로 나눔으로써 얻어질 수 있습니다. 한 row 의 크기는 대략 다음과 같습니다.
(sum of all internal columns sizes ) + 4 x (number of columns)
Q> LONG 데이터 타입도 같은 방법으로 작업할 수 있습니까?
▶▶ 아닙니다. LONG 데이터의 경우에는 현재로서는 오로지 한 row 씩의 fetch 만
가능합니다. LONG 데이터 타입은 2GB 까지의 길이를 가질 수 있으므로 위와 같은
방법으로 사용되어지는 것은 바람직하지 않기 때문입니다.
Q> PARALLEL 에서 MULTIPLE EXPORTS 를 할 수 있습니까?
▶▶ incremental exports 가 아니라면 가능합니다. incremental exports 는
dictionary 의 정보를 기록하게 되고, 실행중인 여러개의 session 들이 정보의
충돌을 야기할 것이기 때문입니다.
Q> RECORD PARAMETER 는 무엇입니까?
▶▶ 위 parameter 는 incremental export 에 적용됩니다. incremental export 는
이전의 incremental/cumulative/complete export 중에서 변화가 생긴 객체들만
export 하는 것입니다. 따라서 data dictionary 의 변경 timestamp 가 INCEXP
테이블의 timestamp 와 비교되고, 객체가 export 될때 새로운 timestamp 가 INCEXP
테이블에 반영됩니다.
RECORD=Y 로 정해주시면 INCEXP 테이블의 현 정보가 유지됩니다. 그렇지 않으면
아무런 정보가 남지 않습니다. 다시 말하면 RECORD=N 상태이면 모든 객체들이 export
됩니다. 종종 이 parameter 는 쓰기버퍼나 incremental export 와 관계없는
RECORDLENGTH 와 혼동되기도 합니다.
Q> 테이블의 FLAG 을 "MODIFIED" 로 바꾸는 것들은 어떤 경우입니까?
이는 추가적 INCREMENTAL EXPORT 를 해야함을 의미합니까?
▶▶ INSERT, DELETE, UPDATE 문을 사용하셔서 데이터를 변경하셨다면 객체가 변경
되었다고 나타나게 됩니다. 컬럼을 not null 로 바꾸시거나 storage 를 변경하는
등의 DDL 은 테이블을 변경시키게 됩니다. 심지어 테이블에 grant 나 comment 를
추가하셔도 테이블이 변경되었다고 나타납니다.
Q> 데이터가 EXPORT 될 때의 시점에서 모든 데이터의 일관성이 유지됩니까?
"SNAPSHOT TOO OLD" 에러는 무엇인가요?
▶▶ Export 는 일련의 SELECT 문을 생성함으로 데이터를 가져오게 되고, 각각
테이블 데이터의 snapshot time 이 SELECT 문의 생성 시간과 대응합니다. 만약,
어떠한 데이터 작업도 없다면 이것은 크게 중요하지 않습니다. 그러나, export 가
시작된 후 테이블을 변경시키는 경우가 가능합니다. 그러한 경우에는 데이터의
snapshot 이 중요할 수 있습니다. Export 는 테이블에 exclusive lock 을 걸지
않기 때문입니다.
option 중 CONSISTENCY=Y 라는 것이 있는데, 이 것을 enable 시키면 EXPORT 는
export 를 시작하기 전에 먼저 SET TRANSACTION READ ONLY 명령어를 수행합니다.
그러나, 오랫동안 계속되는 export 의 경우에는 rollback segment 의 공간이
부족해서, "snapshot too old" 에러가 생길 위험이 있습니다.
Q> PRE-TABLE 과 POST-TABLE ACTIONS 은 무엇입니까?
▶▶ pre-table actions 은 테이블이 import 되기 전에 실행되는 PL/SQL
routines 이고, post-table actions 은 모든 테이블들이 import 된후에 실행되는
PL/SQL routines 입니다. 그러므로 프로시져들은 테이블 데이터가 import 된후
변경 작업을 하게 됩니다. 이러한 options 은 사용자들이 실행하길 원하는
routines 을 지정할 수 있도록 앞으로의 release 에서 제공될 것입니다. 이는
import session 중에서 데이터를 변경할 수 있도록 해줄 것입니다.
Q> IMPORT 는 ARRAY INSERTS 를 사용하는데 이것은 어떤 것입니까?
▶▶ Export 가 테이블 데이터를 select 하는 것처럼 import 는 데이터베이스로
다시 데이터를 insert 합니다. 한번에 한 row 를 insert 하는 것은 자원 집약적
입니다. 데이터베이스로 통신하는 횟수는 한번에 여러 row 들을 insert 함으로써
줄일 수 있습니다. 이것이 바로 array insert 의 개념입니다.
Q> LONG 컬럼의 테이블을 IMPORT 할 때 한번에 한 컬럼 씩 INSERT 되는데,
이것이 정상적으로 수행되는 것입니까?
▶▶ 정상입니다. LONG 컬럼에 대해서는 array 크기의 default 는 1 입니다.
Export 는 insert 하기 전에 모든 LONG 컬럼을 올려놓을 연속적인 메모리를 필요로
하기 때문입니다. 또, 적당한 upper bound 를 찾아낼 방법도 없습니다. 장차 LONG
컬럼을 조각조각 insert 하는 데이터베이스의 지원이 이루어 질때 이러한 작업은
변화될 것입니다.
Q> IMPORT BUFFER 는 무엇입니까?
▶▶ 테이블의 rows 이 저장되기 위해서 데이터베이스로 보내기 전에 사용자 쪽에
할당될 메모리의 용량을 지정하는 parameter 입니다.
Q> 각각의 ARRAY INSERT 에 COMMIT 할 수 있습니까?
▶▶ COMMIT=Y 로 지정하시면 가능합니다. 한번의 통신에서 commit 되는 정확한
rows 의 수는 버퍼의 크기와 얼마나 많은 rows 가 해당 버퍼에 저장 되었는 것에
달려있습니다.
Q> RECORDLENGTH PARAMETER 는 무엇입니까?
▶▶ import 는 한 번에 한 글자씩 export 화일로부터 정보를 읽지 않습니다.
대신에 버퍼의 값만큼의 분량의 정보를 메모리로 읽습니다. RECORDLENGTH 는 이
읽기버퍼의 크기입니다. 이를 O/S 블럭 크기의 배수로 유지하는 것이 가장 효율적
입니다. 이 parameter 는 종종 테이블 데이터에만 영향을 미치는 BUFFER parameter
와 혼동되기도 합니다. 테이블 데이터에 나뉘어져 저장된 SQL 문장들이 있어서
데이터가 분리될 필요가 있으므로 또다른 분리된 버퍼들을 가지는 것이 필요합니다.
Q> DESTROY OPTION 은 IMPORT 시에 어떤 역할을 합니까?
▶▶ CREATE TABLESPACE 문은 사용자가 존재하는 데이터 화일을 재사용할 수 있게
하여주는 REUSE 절을 가지고 있습니다. 그러나, 사용자가 다른 테이블스페이스 속한
화일을 실수로 없애버리는 바람직하지 않은 효과를 낼 수도 있으므로 주의해야
합니다. DESTROY=N 으로 import 를 실행하면 CREATE TABLESPACE 문에서 REUSE
절을 사용하지 않게 됩니다.
Q> IMPORT 를 실행 시 "SEALS DON'T MATCH" 라는 메세지를 접하게 됩니다.
SEAL이 어떤 건가요?
▶▶ seal 은 export session 에 대해 정보를 가지고 있는 export 화일 헤더의
또 다른 이름입니다.
Q> IMPORT 를 실행시 "ABNORMAL END OF FILE" 이라는 메세지를 보게 됩니다.
이것이 무슨 의미인가요?
▶▶ 이것은 어떤 이유로 인해서 export 화일이 손상되었음을 의미합니다.
보통 import 는 화일의 특정 포인트를 얻으려 하는데, 만약 화일이 손상되었
다면 import는 아마도 정상적이지 않게 약간 앞쪽에서 찾으려 하게 됩니다.
그 결과 화일이 비정상적으로 끝났다고 생각하게 되는 겁니다.
한쪽 기종에서 다른 기종으로 정상적으로 옮겨지지 않았다면 export 화일은 손상을
입었을 가능성이 있습니다. export 하는 기종에서 다시 한번 화일을 보내도록
하십시오. 또 한가지 화일의 transport protocol 이 binary mode 인지 확인
하시기 바랍니다.
Q> FROMUSER / TOUSER 기능을 사용하고 있는데, TOUSER 수 보다도 FROMUSER 에서
많은 사용자를 지정하고 있습니다. 이 때, 여분의 사용들에게 어떤 일이 생기나요?
▶▶ import 는 적절한 수의 TOUSER 만큼 FROMUSER 수를 mapping 합니다. 여분의
사용자들은 스스로에게 mapping 되므로 시작 시점에서 지정되지 않을 수도
있습니다.
Q> FROMUSER / TOUSER 기능을 사용하고 있는데, FROMUSER 수 보다 많은 TOUSER
수를 사용합니다. 여분의 TOUSER 는 어떻게 됩니까?
▶▶ 그들은 무시되게 됩니다.
3) 어떻게 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을 생성해 놓는 것이
바람직합니다.
4) (V9.X) 8I -> 9.X EXPORT/IMPORT 수행 시 ORA-25150 에러 해결방법
==============================================================
PURPOSE
-------
이 자료는 Oracle 8i 버젼에서 export받은 dump file을 가지고 Oracle 9i
데이타베이스 서버에 import할 때 발생하는 ORA-25150 에러 해결방법에
대한 자료이다.
Problem Description
-------------------
Oracle 8i 버젼에서 export를 수행하였는데, 8i의 tablespace는 DICTIONARY
managed tablespace이다. 이 8i export dump file을 9i 데이타베이스로
import를 하게 되면 다음과 같은 에러 메시지가 발생할 수 있다.
importing table "WWA_MODULE_CALL_STACK$" 186 rows imported
. . importing table "WWA_MODULE_EVENTS$" 588 rows imported
. . importing table "WWA_MODULE_LOV_BINDINGS$" 1 rows imported
. . importing table "WWA_MODULE_SCRIPTS$" 0 rows imported
IMP-00017: following statement failed with ORACLE error 25150:
"ALTER TABLE "WWA_MODULE_SESSION_ELEMENTS$" PCTFREE 10 PCTUSED 40 INITRANS"
"1 MAXTRANS 255 LOGGING STORAGE( NEXT 10485760 MINEXTENTS 1 MAXEXTENTS 1000"
"PCTINCREASE 0 BUFFER_POOL DEFAULT)"
IMP-00003: ORACLE error 25150 encountered
ORA-25150: ALTERING of extent parameters not permitted
Workaround
----------
none
Solution Description
--------------------
Oracle 9i에서는 생성되는 tablespace가 모두 default로 Locally-managed
tablespace이다. ORA-25150 에러를 해결하기 위해서는
DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_FROM_LOCAL 프로시져를 이용하여
Locally-managed tablespace를 Dictionary-managed tablespace로 migrate
해야 한다.
DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_FROM_LOCAL 프로시져와
DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL 프로시져는
Locally-Managed tablespace를 Dictionary-managed tablespace로,
또한 Dictionary-managed tablespace를 Locally-Managed tablespace로
전환하기 위해 사용되는 프로시져이다.
Dictionary-managed tablespace를 Locally-Managed tablespace로 전환하는
방법에 대한 자료는 <Bulletin:18260>을 참조하도록 한다.
이 자료는 Locally-Managed tablespace를 Dictionary-managed tablespace로
전환하는 방법에 대한 자료이다.
Oracle 9i 데이타베이스에서 다음과 같이 수행하면 된다.
SQL> connect / as sysdba
Connected.
SQL> execute DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_FROM_LOCAL('USERS');
PL/SQL procedure successfully completed.
ORA-25150 에러는 Locally-managed tablespace 안에 있는 object에 대해서
EXTENT parameter를 변경하는 것이 가능하지 않기 때문에 발생한다.
SQL> select TABLESPACE_NAME, EXTENT_MANAGEMENT
FROM DBA_TABLESPACES
where tablespace_name='USERS';
TABLESPACE_NAME EXTENT_MAN
------------------------------ ----------
USERS LOCAL
DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_FROM_LOCAL('USERS'); 프로시져를
수행하고 나면, USERS tablespace가 Locally-managed tablespace에서
Dictionary-managed tablespace로 변경된 것을 알 수 있다.
SQL> select TABLESPACE_NAME, EXTENT_MANAGEMENT
FROM DBA_TABLESPACES
where tablespace_name='USERS';
TABLESPACE_NAME EXTENT_MAN
------------------------------ ----------
USERS DICTIONARY
5) 특정 테이블을 제외하고 EXPORT 하는 방법 IN V8
=============================================
특정 테이블에서 corruption block 이 발견되었을 때, 또는 특정 테이블을 제
외하고 user / full mode 로 export backup 을 수행해야 할 경우 적용할 수
있는 방법을 제시하고자 한다.
에러가 발생된 테이블을 DEPT_COPY 라 가정한다.
1. Copy $ORACLE_HOME/rdbms/admin/catexp.sql to a new name(new_catexp.sql)
2. Modify new_catexp.sql:
위 파일에서 'CREATE OR REPLACE view exu81tabs' 구문을 찾아 아래 문장
다음 라인에 o$.name != 'DEPT_COPY' 문장을 추가한다.
WHERE t$.obj# = o$.obj# and t$.ts# = ts$.ts# and
u$.user# = o$.owner# and o$.obj# = c$.obj#(+) and
c$.col#(+) is null and
하나 이상의 테이블을 제외하기 위해서는 not in 연산자를 활용한다.
o$.name not in ( 'DEPT_COPY', 'COPY_EMP') and
3. 새롭게 구성된 파일을 수행
$ svrmgrl
SVRMGR> connect internal
SVRMGR> @ new_catexp.sql
수행시 아래와 같은 에러는 무시하고 진행한다.
CREATE ROLE exp_full_database
*
ORA-01921: role name 'EXP_FULL_DATABASE' conflicts with another user or role name
and
CREATE ROLE imp_full_database
*
ORA-01921: role name 'IMP_FULL_DATABASE' conflicts with another user or role name
4. Export 수행
exp system/manager full=y
5. Export 수행 후 dictionary 정보를 예전의 것으로 유지하기 위하여
catexp.sql을 반드시 수행한다.
Reference Documents
-------------------
HOW TO EXPORT YOUR DATABASE BYPASSING A TABLE IN ORACLE V8
(Note : 115578.1)
HOW TO EXPORT YOUR DATABASE BYPASSING A CORRUPT TABLE
(Note : 2009.1)
6) 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 |
|
|
|
7) 많은 개수의 TABLE을 한번에 TABLE 별로 EXPORT받는 방법
=====================================================
Purpose
-------
export를 table 별로 받아야 하는 데, export를 받아야 할 table이 매우
많은 경우 tables option에 모두 적는 것이 불가능한 경우가 있다.
이러한 경우에 대해 보다 쉽게 작업할 수 있는 방법을 알아보자.
Explanation
-----------
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);
}
8) 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 가 된다.
9) EXPORT 실행 시 ORA-1403 에러가 발생되는 경우가 있는데, 이 에러는 테이블 혹은
index에 문제가 있는 경우 발생할 수 있다.
여기서는 ROWID를 사용하여 table을 복구시키는 방법을 소개한다.
1. 기존 테이블과 같은 구조를 갖는 테이블을 만든다.
SQL> CREATE TABLE TEMP
AS SELECT *
FROM EMP
WHERE 1=2;
2. 기존 테이블에서 RECORD를 FETCH하여 새로운 테이블에 입력.
이 때, INDEX가 설정되어 있는 COLUMN을 WHERE 조건에 부여함.
<create.sql>
declare
row_id char(18);
cnt number;
cursor c1 is select rowid
from emp
where empno>0;
begin
cnt := 0;
open c1;
loop
fetch c1 into row_id;
insert into temp select * from emp where rowid=row_id;
cnt:=cnt+1;
if cnt = 100 then /* commit per 100 records */
commit;
cnt:=0;
end if;
exit when c1%notfound;
end loop;
commit;
end;
/
3. create.sql file 실행
sql> @create