java.sql.SQLException: IO 예외 상황: The Network Adapter could not establish the connection
No. 11126
(V7.2)EXPORT/IMPORT에 대한 Q&A
==============================
PURPOSE
-------
이 자료는 Oracle 7.2의 export/import에 관한 FAQ 자료이다.
Explanation
-----------
1.Q) CATEXP.SQL은 어떤 스크립트 화일인가?
A) Export는 데이타베이스 내의 모든 오브젝트들에 대해 SQL 문장들을
generation해주는 역할을 한다. 이를 위해, Export는 데이타 딕셔너리를 조회하
여 각 오브젝트에 관한 모든 정보를 얻어야 한다. 많은 정보들은 여러 개의 데이
타 딕셔너리 테이블에 흩어져 있기 때문에, export는 필요한 정보들을 얻기 위해
CATEXP.SQL 안에 있는 뷰 definition을 사용한다.
CATEXP.SQL 에는 각 타입의 오브젝트에 대해 적어도 하나의 뷰가 존재한다.
(예를 들어, EXU7TBS는 모든 테이블스페이스를 가지고 있으며, EXU7ROL은 모든
롤들을 가진다. )
참고로, 이 화일은 Release 7.1 이전에는 EXPVEW.SQL이라는 이름으로 제공되었
다.
2. Q) Export를 수행하던 중, ORA-942가 발생하였다. 해결 방법은?
A) ORA-942는 테이블이나 뷰가 존재하지 않는다는 전형적인 에러 메시지이다.
이것은 아마도 CATEXP.SQL을 실행시키지 않아서 Export 뷰를 인스톨하지 않았다
는 메시지일 것이다. 만약, CATEXP.SQL을 실행을 했는데, 이 에러가 발생했다면
그것은 적용되지 않는 버젼을 사용했을 가능성이 가장 크다. 맞는 버젼인지 다시
확인해 보아야 한다.
3. Q) Import를 하기 위해서 CATEXP.SQL을 실행해야 하는가?
A) YES. Import는 Export와 몇 개의 뷰를 공유하며, 이러한 뷰들은 CATEXP.SQL
을 실행시킴으로써 로드된다. 이러한 뷰들은 같은 뷰이기 때문에, 별도의
CATIMP.SQL과 같은 화일은 존재하지 않는다.
Oracle 7 Release 7.2의 경우에는 공통적인 뷰들은 CATEXP.SQL 스크립트의
윗 부분에 옮겨 놓았기 때문에 Import만을 수행할 때에는 import와 관련되지 않
은 뷰는 제외하고 스크립트 일부만을 수행시켜주면 된다.
4. Q) CATEXP.SQL 을 실행하기 전에 CATALOG.SQL도 실행해야 하는가?
A) NO. CATEXP.SQL은 CATALOG.SQL에서 불려지기 때문에 CATEXP.SQL에는
CATALOG.SQL 내에 정의된 뷰에 의존하는 뷰는 없다. CATEXP.SQL에서 만들어지는
뷰들은 SYS를 owner로 가지기 때문에, SYS 유저로만 실행시킬 수 있다.
5. Q) CATEXP.SQL에서 정의되는 뷰들의 owner는 누구인가?
A) SYS 유저이다. 스크립트의 윗 부분을 보면 알 수 있다.
6. Q) Export/Import 실행 화일들을 찾을 수가 없다. 해결 방법은?
A) 실행 화일의 이름은 exp와 imp이다. 만약, 존재하지 않는다면, manual하게
만들어야 한다. 이 화일들은 Oracle 실행 화일들과 같은 디렉토리에 존재한다.
사용하는 환경이 유닉스 환경이라면, $ORACLE_HOME/bin 디렉토리 내에 존재해야
한다.
7. Q) Export와 Import와 관련된 일반적인 compatibility 원칙은?
A) Export와 Import는 client utility이기 때문에, 데이타베이스 버젼과 다를
수 있다.
데이타베이스 버젼과 Export 버젼을 고려하여 4가지 가능성을 생각하기로 한다.
데이타베이스 버젼(또는 Export 버젼)을 X, Y라 하고, Y > X라 가정한다.
1> Base Compatibility
데이타베이스 X로부터 Export 버젼 X를 사용하여 export하고, 데이타베이스
X로 Import 버젼 X를 사용하여 import할 수 있다.
2> Upward Compatibility
데이타베이스 X로부터 Export 버젼 X를 사용하여 export하고, 데이타베이스
Y로 Import 버젼 Y를 사용하여 import할 수 있다.
3> Downward Compatibility
데이타베이스 Y로부터 Export 버젼 Y를 사용하여 export하고, 데이타베이스
X로 Import 버젼 X를 사용하여 import할 수 있다.
4> Cross Compatibility
데이타베이스 Y로부터 export하기 위해 SQL*Net과 같은 접속을 통해 Export
버젼 X를 사용하고, Import할 때 X나 Y버젼을 사용하여 import할 수 있다.
Upward Compatibility는 항상 가능한 반면, Downward Compatibility는 많은
작업이 필요하다.
Cross Compatibility는 export 코드와 synchronize되지 않을 수 있기 때문에
더 어려운 작업이다.
예를 들어, 데이타베이스 X로부터 export 버젼 Y를 사용하여 export하였는데,
새로운 버젼에는 이전에 데이타베이스에서 돌린 CATEXP.SQL이 생성하지 않았던
새로운 뷰나 컬럼들이 존재할 수 있다.
이 때의 해결방법은 새로운 뷰의 생성을 위해 export 버젼과 일치하는 스크립
트를 수행하여 현재 사용 중인 export usage 환경을 맞추어 주는 것이다.
새로운 스크립트를 돌려주더라도, 이전의 export 버젼에서 사용하던 뷰나 컬럼
들은 중복이 되어도 삭제되지 않는다.
8. Q) Cross Compatibility가 중요한 이유는?
A) Cross Compatibility는 다른 Oracle 버젼을 갖는 여러 다른 machine들이
존재하는 환경에서 데이타를 다루어야 하기 때문에 중요한 내용이다.
데이타베이스 관리자는 하나의 시스템에서 모든 export를 하기를 원할 것이다.
문제는 Export 버젼은 각각의 데이타베이스 버젼에 대하여 다를 수 있다는 것
이다.
9. Q) 최신 export 버젼을 사용하여 생성한 화일을 import할 때, 최신 release
의 new feature를 사용할 경우 어떤 현상이 발생할 수 있는가?
A) 이 경우는 downward compatibility의 예이다. New feature는 이전 release
에 의해서 사용될 수 없기 때문에, warning이나 에러가 발생할 수 있다.
export는 계속 진행될 것이고, 남아 있는 export 화일들을 처리하려고 할 것이다.
마지막에는 결국, 예상했던 대로 warning과 함께 끝날 것이다.
10. Q) Downward Compatibility가 실패로 끝나는 경우의 예?
A) Oracle 7.2에는 hash cluster를 만들 때, 자신만의 hash 함수를 명시할 수
있도록 'hash cluster expressions' 라는 옵션이 있다. 이 옵션은 Release
7.1과 7.0에서는 지원되지 않는다.
그 결과, Release 7.2 hash cluster에 대한 CREATE CLUSTER 명령을 실행하면
이 옵션을 가지고 수행될 경우, Release 7.0과 7.1에서는 실패할 것이다. 단,
이 옵션을 사용하지 않고, Release 7.2에서 생성된 클러스터들은 Release
7.0과 7.1에서는 성공적으로 import될 것이다.
또 다른 예를 하나 든다면, Release 7.1에 추가된 job queue이다. Release
7.0으로 import할 때, job queue를 만들기 위해 실행한 DDL 명령문은 수행이 되
지 않을 것이다.
11. Q) Export를 수행하던 중, ORA-904 에러가 발생하였다. 해결 방법은?
A) ORA-904는 일반적으로, 뷰 안에 컬럼이 빠졌다는 에러이다. 이것은 현재
사용 중인 export의 버젼이 CATEXP.SQL의 버젼과 맞지 않아, 필요한 뷰가 존재
하지 않기 때문에 발생한 것이다.
이 문제를 해결하려면 현재 사용 중인 export의 버젼과 매치되는 CATEXP.SQL
을 수행시켜 주어야 한다.
12. Q) Export를 수행하던 중, EXP-37 에러가 발생하였다. Export 뷰가 데이타
베이스 버젼과 일치하지 않는다는 메시지였다. 해결 방법은?
A) 데이타베이스에 존재하는 뷰가 export 뷰 버젼보다 이전 버젼이라는 점에서
Cross-compatibility 문제이다. 해결방법은 export 뷰의 버젼과 매치되는 뷰를
인스톨하는 것이다. 이 compatibility 메시지는 ORA-904 에러를 피하기 위해
Release 7.1에 추가되었다.
13. Q) Oracle 7 DB의 내용들을 Oracle 6 DB로 가져오는 방법은?
A) Oracle 7 데이타베이스를 export 버젼 6로 export한다. 이 때, export 버젼
6는 나중에 import 버젼 6를 사용하여 버젼 6 데이타베이스로 import될 수 있는
export 화일을 생성한다.
Export 버젼 7으로 export하여 버젼 6로 import하는 것은 불가능하다.
왜냐하면, Oracle 6와 7은 화일 format이 다르고, 새로 변경된 format은
Import 버젼 6를 지원하지 않기 때문이다.
14. Q) Export 버젼 6는 trigger, procedure, role과 같은 Oracle 7 New
feature들을 export할 수 있는가?
A) NO. Export 버젼 6는 버젼 6가 지원하는 오브젝트만 export할 수 있다.
15. Q) CATEXP6.SQL은 어떤 스크립트 화일인가?
A) 이 화일에는 export 버젼 6가 지원하는 뷰들을 생성하는 스크립트가 있다.
만약, Oracle 7 데이타베이스에서 이 스크립트를 실행한다면, Export 버젼 6
는 Oracle 7 데이타베이스를 버젼 6로 인식할 것이다.
Release 7.1 이전에는 이 화일이 EXPVEW6.SQL이라는 이름으로 사용되었다.
16. Q) Oracle 버젼 5로 export하여 버젼 7에서 import할 수 있는가?
A) YES.
Oracle 5에서 생성한 'CREATE SPACE DEFINITION'과 같은 문장은 똑같은 형태의
Oracle 7 문장으로 변환된다.
17. Q) Export 화일 format은 release에 따라서 다른가?
A) YES. 모든 export화일은 대부분의 release에 따라 다르다.
특히, Downward Compatibility의 경우에는 각각의 release 사이에 호환이
되게 하기 위해 많은 작업이 필요하다.
만약, format이 바뀌더라도, 여전히 이전 화일들을 사용할 수 있다.
18. Q) Export 화일이란 무엇인가?
A) Export 화일에는 테이블 데이타와 관련된 SQL 문장과 그 밖의 DDL 문장에
따르는 헤더가 존재한다.
19. Q) Export 화일은 readable하거나 portable한가?
A) 비록 이 화일은 binary 화일이지만, 유닉스 시스템 상에서 emacs와 같은
에디터로 불러오거나, od를 사용하여 가져와 보면, 사용자가 읽을 수 있는
형태로 번역될 수 있다.
이 화일은 모든 데이타가 다양한 플랫폼에 걸쳐 이식성이 있는 오라클 DB
format으로 export될 수 있기 때문에 portable하다고 할 수 있다.
20. Q) Export 화일이 전송되는 방식은?
A) Export 화일은 binary 화일이므로, binary 모드로 FTP를 사용하거나 기타
프로토콜을 사용하여 전송될 수 있다.
21. Q) Export 화일은 수정될 수 있는가?
A) NO. Export 화일을 수정하는 것은 불가능하다.
22. Q) 일반적으로, export와 import는 Positional 또는 Keyword method를
이용하여 수행된다. 이 두 가지 방법의 차이점은?
A) Keyword를 사용하는 방법은 사용자로 하여금 명령 라인 상에서 각각의
keyword에 대한 특정 값을 명시할 수 있도록 해 준다. 예제는 다음과 같다.
> exp userid=system/manager recordlength=1024 buffer=102400
file=test.dmp
위 예제에서 각 keyword(USERID, RECORDLENGTH, BUFFER, FILE)는 사용자가
지정한 특정값을 가지고 명시되어 있다. 아래에 제시하는 예제는 위의 예제와
동일하다.
> exp system/manager 1024 102400 test.dmp
이 방법은 Positional method이다. 만약, keyword가 명시되지 않는다면,
파라미터 값은 export가 예상하는 순서대로 인식된다. 예를 들어, BUFFER는
세번 째 파라미터이고, 그 값은 102400이다.
그러나, 이 방법은 순서를 따로 기억해야 하는 단점이 있으므로, 가능하면
keyword method를 사용하는 것이 낫다.
23. Q) Export나 Import를 수행하는 중에 프로세스가 hanging 상태가 되었을
때 얼마 만큼의 row가 처리되었는지 확인하는 방법은?
A) FEEDBACK 옵션을 사용하면 된다. 이 옵션은 디스플레이 상에 dot를 사용하여
프로세스 진행 상황을 보여준다. 스크린 상의 각 dot는 사용자가 명시한 row의
갯수와 일치한다. 이 옵션은 Release 7.2부터 적용된다.
24. Q) 사용자모드 export의 종류와 방법은?
A) 사용자모드 export 방법에는 두 가지가 있다.
1> 사용자 자신이 만든 오브젝트를 export하는 방법이다.
exp scott/tiger file=myexp.dmp
2> system/manager로 접속한 DBA가 여러 유저가 사용하고 있는 화일을 export
하는 방법이다.
exp system/manager owner=scott raghu file=user.dmp
위의 두 가지 방법은 user level export로 분류된다. 두번 째 방법의 경우
에는 import를 할 때에도 DBA 권한이 있어야 한다. FROMUSER/TOUSER 옵션은
두번 째 방법을 사용하여 생성된 export 화일을 import할 때에 사용될 수 있다.
Example
-------
none
Reference Documents
-------------------
<Note:175624.1>
java.sql.SQLException: IO 예외 상황: The Network Adapter could not establish the connection
No. 11137
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 와 관계없는
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 는 어떻게 됩니까?
▶▶ 그들은 무시되게 됩니다.
java.sql.SQLException: IO 예외 상황: The Network Adapter could not establish the connection
No. 11166
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을 생성해 놓는 것이
바람직합니다.
java.sql.SQLException: IO 예외 상황: The Network Adapter could not establish the connection
No. 11167
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 파일에 쓰여집니다.
577
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
