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을 생성해 놓는 것이
바람직합니다.


출처 : Technical Bulletin (Korean)