2013. 3. 12. 11:25ㆍ데이터전환
데이터 펌프 유틸리리 expdp, impdp를 사용하여 시스템 간 데이터를 추출하고 적재하는 옵션은 아래와 같다.
A의 경우에는 타깃 시스템의 TNSNAMES.ORA에 등록된 소스 시스템의 오라클 인스턴스 식별자(예: astns)를 이용하여 테이블을 파일로 덤프하는 경우이다.
B의 경우에는 타깃 시스템의 TNSNAMES.ORA에 등록된 소스 시스템의 오라클 인스턴스 식별자(예: astns)를 이용하여 덤프 파일을 테이블로 적재하는 경우이다.
A와 B의 경우 덤프 파일은 모두 소스 시스템의 디스크(로컬, 공용)에 위치한다.
주의사항은 양쪽간 expdp/impdp 유틸리티간의 버전 호환성이 존재해야 한다. 만약에 버전 호환성이 존재하지 않으면 다음과 같은 에러를 출력한다.
소스시스템의 오라클 버전은 10.2.0.4.0, 타깃 시스템의 오라클 버전은 11.2.0.3.0 인 경우 A 처럼 expdp를 실행한 경우의 에러다.
Export: Release 11.2.0.3.0 - Production on Mon Mar 11 11:18:40 2013 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. |
C의 경우에는 타깃 시스템에 설정된 소스 시스템의 DB LINK(예: aslink)를 이용하여 소스 시스템의 테이블을 파일로 덤프하는 경우이다. 이 때 덤프파일의 위치는 타깃 시스템의 디스크이다.
D의 경우에는 타깃 시스템에 설정된 소스 시스템의 DB LINK(예: aslink)를 이용하여 소스 시스템의 테이블을 파일로 덤프하지 않고 곧바로 타깃 시스템의 테이블로 적재하는 경우이다.
항상 덤프 및 적재시 고려해야 할 사항은 시스템의 캐릭터 셋 변환, 업무상 데이터의 크기 변환(예: 암호화/복호화)을 고려해야 한다.
가령 소스 데이터베이스의 캐릭터 셋이 KO16KSC5601(한글은 2 바이트로 표현된다)이고 타깃 데이터베이스의 캐릭터 셋이 AL32UTF8(한글은 3바이트로 표현된다)인 경우 테이블을 덤프/적재시에는 테이블의 컬럼 데이터 크기가 적절하게 바뀌어 있어야 한다.
C의 경우에는 데이터에 들어있는 한글 데이터 뿐만 아니라 아스키 데이타까지 모두 3바이트로 확장하여 덤프 파일을 구성한다. 예를 들면 데이터 값이 '111한글'인 경우 소스 시스템에서는 바이트 수가 7바이트(1+1+1+2+2)이지만 타깃 시스템에 덤프로 파일은 무조건 3배로 크기를 확장하여 21바이트로 확장한다. 타깃 시스템의 컬럼 크기가 모두 3배로 선언되지 않은 경우 문제가 된다.
D의 경우에는 한글 데이터만 확장하여 9바이트(1+1+1+3+3)확장하여 테이블에 적재한다.
[참고]
가령 소스 시스템의 캐릭터 셋이 오라클의 환경변수중 하나인 NLS_LANG을 보면 KOREAN_KOREA.KO16MSWIN949, AMERICAN_AMERICA.KO16MSWIN949, KOREAN_KOREA.KO16KO16KSC5601 와 같이 사용하는데. 언어_영역.캐릭터셋의 구조로 되어 있다. 흔히 UTF를 사용하고자 한다면 NLS_LANG을 바꿔야 하는거냐고 오해하는데 NLS_LANG은 데이타베이스 캐릭터 셋과 상관없다. (NLS_LANG가 데이타베이스 캐릭터 셋과 항상 같아야 한다면 굳이 따로 설정해야 할 필요가 없다.) NLS_LANG은 원격지의 데이타베이스 환경이 아니라 자신이 속해 있는 환경을 데이타베이스에 알려주는 역할을 한다. 이 NLS_LANG 값의 의거해 데이타 베이스는 실제 UTF8로 저장이 된 데이타를 MSWIN949 코드로 변경하여 사용자에게 보여준다.
'데이터전환' 카테고리의 다른 글
EXTERNAL TABLE 딕셔너리 (0) | 2013.03.21 |
---|---|
오라클 한글 Characterset (0) | 2013.03.12 |
CLOB 컬럼 저장 구조 (0) | 2013.03.11 |
LOB STORAGE의 STORAGE IN ROW 옵션 (0) | 2013.02.16 |
DBMS_FILE_TRANSFER 패키지 (0) | 2013.02.05 |