[기술노트78회] DMU(Database Migration Assistant for Unicode)

1. DMU

DMU(Database Migration Assistant for Unicode)는 scan/csalter보다 더 interative한 GUI based tool이며, 자동으로 Unicode character set (UTF8혹은 AL32UTF8)로의 migrate를 지원한다.

 

현재 DMU의 최신 버전은 2.2 (2018년 03월기준) 이며, 무료로 사용할 수 있다.

버전 2.1부터는 OGG의 replication기술을 이용한 Near-zero downtime migration model을 지원한다.

 

Oracle에서 character set은 Database에 저장가능한 문자의 집합을 말하는데, 각 문자(character)를 memory 혹은 disk에, bytes의 sequence를 매핑하는 방식을 말한다.

oracle에서 사용하는 varchar2, char, log, clob뿐만 아니라 sql, pl/sql, java stored code 모두 이 character set의 영향을 받기 때문에, 문자 코드가 다른 DB로 데이터가 이관된다는 것은 다양한 문제를 야기시킨다.

가장 일반적인 문제는, 문자를 표현하는데에 있어 더 많은 bytes를 필요로 하는 character set 으로 이관되는 경우 데이터가 설정된 column의 길이를 넘어서는 것이다. 이러한 문제를 분류하고 확인할 수 있도록 database character set scanner (CSSCAN) 또는 DMU(Database Migration Assistant for Unicode)를 이용하여 이관하는 것이다.

 

2. Character Set Migration Tool

DMU를 포함하여, Character set이 다른 database로 migration하는 경우에 아래의 tool이 사용된다

   2.1.   CSSCAN

CSSCAN (Database Character Set Scanner utility)은 command-line utility로, database의 모든 character data를 체크하여 새로운 character set으로의 이관에 대한 summary report를 제공한다. Express edition을 제외한 모든 edition에서 사용 가능하고, DMU와 기능적 유사하나 12c부터는 사용을 권장하지 않는다.

        à 참고: 12c WARNING: Possible Data Loss In Character Set Conversions (문서 ID 2241155.1)

 

   2.2.   DATA PUMP Utility

Export- import를 이용하여 다른 character set 으로 이관할 수 있으나, 세부적인 수정사항을 체크하는데에 공수가 많이 들고, 이관될 DB를 구성해야 하는 등의 문제가있다.

 

3. 왜 DMU를 사용하는가

    3.1.    데이터 무결성(Data Integrity)

Character data를 re-encording 할 때, 작업자는 무결성을 고려해야 한다.

 

l  Data의 확장성(expansion)

기존 encoding에서 unicode로 migration할 때, character 값이 확장되면서 더 많은 bytes를 요구하게 된다. 이것은 database에 더 많은 공간을 요구하게 되는데, 예를 들어 CHAR 와 VARCHAR2 column의 경우 Unicode로 migrate시 필요한 컬럼 길이(width)가 늘어나게 되므로 데이터가 잘릴 위험이 있다. 이럴 경우에는 길이 제한을 조정하거나, 이관 전에 CLOB data type으로 변경해야 한다.

 

l  Invalid한 binary storage 표현식

User data에 있을만한 일반적인 문제는, column안에 있는 data 실제로는 character set에 없는 경우이다. 다른 character set 에 존재하는 문자를 사용했거나, 이진(binary, 예를 들어 워드프로세서 포멧의 문서 또는 사용자가 지정한 방법으로 암호화된 텍스트 등) 혹은 단일 column에 다중 character set이 있을 수 있다. pass-through 구성*에서는, clinet의 character set이 (일반적으로는 NLS_LANG를 설정한다) 그대로 database character set과 동일하게 설정된다. Character set 이 동일하기 때문에, oracle communication protocol은 변환이 필요없다고 생각하여 client/server character set conversion을 시도하지 않는다. 이 경우에는 data에 대해 유효성 검사나 변환(conversion)이 수행되지 않으므로 잘못된 문자가 읽고 써질 수 있다. 만약 migration 동안 default character set의 변환이 data에 잘못 적용되는 경우, 일부 데이터는 변환에 실패하고 garbage가 된다. 이러한 상황을 피하기 위해 이진 데이터를 RAW 혹은 LONG RAW형식으로 data type을 변경하거나, 권장되지는 않지만, 새 character set으로 migration하는 동안 문제가 의심되는 column의 변환을 스킵하는 방식으로 어플리케이션이 pass-though구성을 계속 사용하도록 하는 것이다. (단일 column에 여러 character set이 저장되어 있고, 이러한 character set을 자동으로 검색하지 못하는 경우에 사용 한다) 마지막으로 DMU를 통해서 source database의 character set이 변환될 때 어떠한 방식으로 mapping될 것인지 확인 할 수 있다.

* pass-through 구성: client에 따로 Character 설정을 하지 않고 DB의 character set을 따르도록 하는 구성을 말한다(NLS_LANG을 지정하지 않음)

 

l  Partitioning (파티셔닝)

Range Partition은 partitioning key 값과 partition boundary 값을 비교하여 row들을 partition에 분배한다. 이러한 방식은 character 값의 binary storage representation*을 확인하는데, key값과 boundary값의 binary storage representation이 Unicode로 변환될 때 요구사항 대로 변경되지 못할 수도 있으며, 다음 세가지 문제점을 야기시킨다. 1.     주어진 partitioning key가 가진 partition boundary값과는 다르게 정렬(sort)되는 문제. 2.     Partition이 boundary값의 순서와 동일한 순서로, 내부적 넘버링이 되는 경우. 만약 Unicode로 migrate되는 동안 boundary 값이 sort 순서를 변경하게 된다면 내부적 넘버링이 invalid 하게 됨. 3.     드문 경우이지만, 일부 multibyte 의 동아시아 character set*에서는 서로 다른 문자가 동일한 Unicode 문자에 mapping되어 두개의 partition boundary가 같아지는 경우가 있음. 만약 partition boundary가 non-ASCII 문자를 사용한다면 Partition된 table을 수정된 DDL을 사용해 재생성해야 할 수도 있다. Partition key값에 영향이 생겨 row가 이동되어야 하는 상황이 오면 row movement 가 반드시 enable되어 있어야 한다.

* binary storage representation: 이후 [이진 스토리지 표현식 / 이진 표현식]로 표기한다. 고정길이형 컬럼에서 사용하며 image, 동영상등의 text외data에 사용되는 표현식이다. 일반적으로 바이너리(Binary) 코드라고 부르며 ASCII코드와 반대되는 개념이다.

** 대표적으로 한자/한글 등

 

l  Maximum index key size

Index의 key size는 key column의 최대 길이에 따라 달라진다. 지원되는 최대 key size는 database 의 block size에 대해 제한되고, Unicode로 convert 후에 확장된 column 데이터를 target쪽으로 집어넣으려면, column의 길이를 확장하거나 column length semantics를 BYTE 에서 CHAR로 변경해야 한다. 이를 해결하는 방법으로는 아래와 같다: ·         Block size를 늘림 ·         Index를 drop ·         composite index의 특정 column을 삭제

 

l  Unique key와 primary key

사전에 제약조건을 충족하도록 key을 변환하더라도, Unicode로 변환 후 unique 조건이나 PK조건을 위반하게 되는 경우가 2가지 있다. ·         일부 character set의 일부 문자들이 동일한 Unicode 값으로 mapping되는 경우에, 2개의 다른 TEXT 값이 AL32UTF8로 변경 후 동일한 값이 됨. (예를 들어, 2개의 JA16SJI code인 0xED40 와 0xFA5C가 U+7E8A로 동일하게mapping) ·         최대 column길이를 초과한, 끝부분만 다른 2개의 text값이 convert시의 truncate로 인해 동일하게 보이게 되는 경우. 일반적으로, key값을 매뉴얼하게 수정하여 이 문제를 해결한다.

 

l  파생 또는 암호화된 data

Application에서 저장되어있는 정보는 data의 binary storage representation에 따라 drive된다. 예를 들어 text 길이는 숫자형 column에 있는 text와는 다르게 저장된다. Text가 확장되면 이러한 column들은 자동으로 갱신되지 않는다. 또는, application에서 문자 값의 checksum이나 암호화된 형식을 계산하여 저장할 수도 있다. database character set의 binary storage representation를 기반으로 하는 경우, 이렇게 checksum 또는 암호화된 text가 character set 변환에 의해 유효하지 않게 될 수도 있다. 이러한 식으로 파생된 값은 migration후 반드시 재동기화(resynchronize) 과정을 거쳐야 한다. 암호화된 text의 경우에는 일반적으로 변환 직전에 복호화를 진행하고, 변환 후 다시 암호화를 진행한다. 보안상의 이유로 복호화된 시간을 최소화하고 서버의 보안을 강화해야 하는 작업이 필요하게 될 수 있다. (Oracle TDE를 사용 하는 경우 수동으로 복호화-암호화 하는 과정이 불필요 하다)

 

l  Binary Data Types의 Character Data 적재

Application이 RAW, LONG RAW, BLOB등의 Binary type 문자 데이터를 적재할 수 있다. Application은 이러한 데이터들을 해석(interpret)하고 처리하기 위해 database character set을 사용한다. 만약 database character set이 migrate 되었을 때, 새로운 문자셋에 매치되는 binary data type으로 인코딩 되지 않는다면 application에서 fail이 발생하게 된다. 때문에 DMU등을 이용하지 않을 경우 모든 상황에 맞는 변경 작업을 수동으로 해야 한다.

 

    3.2.    Dependent object

변환 과정 중에 테이블에 있는 데이터가 수정되면, standard/ functional/ domain index 나 mview 와 같은 이 데이터의 copy를 저장하는 모든 object가 영향을 받는다. 변환 방법이 따라, 이러한 object들은 drop하거나 다시 재생성해야 할 수도 있고, database에 의해 자동적으로 동기화될 수 있다. 성능상의 이유로, 자동적인 동기화 보다는 재생성이나 drop 쪽이 더 효율적일 수 있다.

 

Trigger는 수정사항에 반응하는 방식이 관리자의 의도와는 다를 수 있다. 예를 들어 trigger가 마지막 수정 날짜와 user id를 migrate 프로세스의 진행에 따라 수정할 수 있으므로, 관리자가audit규칙을 설정했을 때의 의도와 다른 내용이 로깅될 수 있다. 따라서 table을 convert하기 전에 trigger를 diable해야 하는데, DMU에서는 이런 부분을 자동적으로 관리할 수 있다.

 

    3.3.    Read-only & Inaccessible object

Read-only 로 명시적으로 지정된 table, external table, read-only TBS에 포함되어 있는 table들은 모두 read-only 가 되는데, 이러한 table은 read-write로 바꾸기 전에는 covert할 수 없다. 따라서 일시적으로 remove할 수 있는 read-only 명시 table의 경우를 제외하면, 모두 수동으로 조치를 취해야 한다.

 

External table은 conversion할 필요가 없다. 만약 external table을 sql*loader나data pump등으로 load하기 위한, source file의 character set이 올바르게만 선언되어 있다면, database는 자동적으로 문자 데이터를 file에서 patch할 때 마다 새로운 database의 character set 으로 convert 한다. 물론 이러한 방법은 성능에 영향이 있으므로, 파일을 영구적으로 convert하는 것이 좋다.

만약 Source file의 character set이 올바르게 정의되어 있지 않고, file 내용이 pass-through 구성에 의해 "Invalid Binary Storage Representation of Data"*와 유사한 상태로 가져오게 될 경우, character set을 올바르게 declare해야 한다. 만약 data pump의 dump파일이 이 경우에 해당하면 더욱 복잡해진다.

* Invalid Binary Storage Representation of Data :  https://docs.oracle.com/database/121/DUMAG/ch1overview.htm#CJAHJBDG 참고

 

Read-only tablespace는 CD-ROM 이나 DVD-ROM같은 read-only media에 저장할 수있는데, 이렇게 media에 저장한 read-only TBS에 변환할 data가 포함되어 있다면, 반드시 tablespace를 표준 disk storage로 이동하여 read/write를 수행 후, data를 convert한 뒤 tablespace를 다시 read-only로 변경해야 한다. 그리고 마지막에 read-only media에 copy하는 것이다.  예를 들어 이러한 (아카이빙 용) tablespace가 database에 많은 경우, disk storage의 요구사항에 따라 conversion 전에 모두 read/write로 전환 후 old database character set database를 생성해 move한 다음 read-only TBS를 새로운 database로 TTS를 이용해 옮기는, 매우 번거로운 과정을 고려해야 할 수도 있다.

 

Table을 offline 상태로 전환된 tablespace 또는 data file에 저장한 경우도 있는데, 이러한 table의 data는 access할 수 없고, migration을 위해 data를 scan하거나, convert할 수도 없다. 때문에 offline TBS와 data file안의, 문자column을 포함한 table은 반드시 migrate를 시작하기 전에 online으로 변경해야 한다.

 

    3.4.    Downtime

Downtime은 database의 shutdown으로 모든 application이 접속할 수 없는 상태를 말한다. (migration tool만에 접속 가능) database의 convert를 위해서는 downtime이 필요하고, 그 외 issue를 scan하거나 cleansing, column 확장 등은 peak시간만 피한다면 database가 올라와 있는 상태에서 parallel로 작업이 가능하다.

 

Migration time은 최대한 downtime이 적도록 해야 하며, 이관되는 시간 외에도 문제가 발생할 가능성, 그리고 문제 해결에 걸릴 수 있는 시간까지 염두에 두어야 한다.

DMU는 문제가 발생할 소지가 있는 table만을 선택해 scan할 수 있어 downtime을 최소화 할 수 있다.

 

DMU를 사용하는 것과 CSSCAN을 사용하는 것은 기실 GUI로 작업하느냐와 command line으로 정리하느냐의 차이라고 볼 수 있다. DMU에게 이슈가 있는 모든 데이터를 자동으로 수정해주는 마법같은 기능은 없지만, 비슷한 이슈를 직관적으로 분류하고, 어느 부분이 문제이며, 간단한 클릭으로 수정하는 편의성을 제공한다고 생각하면 된다.

 

4. Using DMU

이 문서에서 DMU를 test하기 위해 설치한 database의 정보이다.

항목	Source database
OS	Red Hat Enterprise Linux Server release 6.8
Oracle version	12.2.0.1.0
DMU version	DMU 2.2.
DB Characer set	KO16MSWIN949 à AL32UTF8

 

문서상에서는 migrate(이관)과 convert(전환)을 혼용해서 사용했지만, 정확히는 source database자체가 지정한unicode character set으로 convert 되는 것을 가정하고 작성하였다.

(물론 상황에 따라 DMU가 convert 하지 못하는 경우가 있으므로, 새로운 data base를 설치하고 CTAS등을 이용하여 이관하는 방법이 추천될 수 있다)

  

    4.1.    Requirement

DMU를 사용하기 위해서는 아래와 같은 요구사항을 체크해야 한다. 

   4.1.1. Database 요구사항

l  DMU를 지원하는 Oracle database release는 10.2.0.4, 10.2.0.5, 11.1.0.7, 11.2.0.1과 그 이후 release이다. DMU를 사용하기 위해서는 설치파일의 release note에 기재된 추가적인 patch 설치가 필요하다.

 

Oracle version	Requirements
12cR1 (12.1.0.1) and higher	※ 필요한 patch 없음 SQL>conn / as sysdba SQL>@?/rdbms/admin/prvtdumi.plb
11.2.0.3 and 11.2.0.4
11.2.0.2 and lowner (including 10g)	※ Server side patch필요 Unix platform Oracle version 필요 patch 11.2.0.2.7 patch 9825461 적용 11.2.0.2.0 11.2.0.2.0~3까지는 patch 9825461 적용. 11.2.0.2.4~6까지는 DMU 사용 불가 11.2.0.1 PSU 11.2.0.1.3 까지 올리고 patch 9825461 적용 11.1.0.7 PSU 11.1.0.7.5 까지 올리고 patch 9825461 적용 10.2.0.5 10.2.0.5.0~3까지는 patch 9825461 적용 10.2.0.5.4는 Patch 12419392 적용 10.2.0.4 PSU 10.2.0.4.4 까지 올리고 patch 9825461 적용 Windows platfome Oracle version 필요 patch (bundle) 11.2.0.2 Patch 6 or higher 적용 11.2.0.1 Patch 12 or higher 적용 11.1.0.7 Patch 39 or higher 적용 10.2.0.5 Patch 10 or higher 적용 10.2.0.4 Patch 46 or higher   SQL>conn / as sysdba SQL>@?/rdbms/admin/prvtdumi.plb

 

l  Database의 character set이 반드시 ASCII 기반이어야 한다. 예를 들어 database가 EBCDIC-based platfrom인 IBM z/OS와 Fujitsu BS2000은 support되지 않는다.

l  Bash 쉘이 설치되어 있어야 하고, 릴리즈 2.2는 AIX가 지원되지 않는다
(2018년 5월 기준)

l  SYS.DBMS_DUMA_INTERNAL 패키지가 반드시 설치되어 있어야 한다.
이 패키지는 기본적으로 DB생성시에 사용이 가능하도록 설치되며, 수동으로 설치하려면 SYSDBA 계정으로 @?/rdbms/admin/prvtdumi.plb를 수행한다.

(최신 파일을 다운받아 설치하는 것을 권장)

l  Oracle Database Vault는 반드시 DMU migrate전에 disable 해야 한다.

l  Database는 반드시 read-write mode로 open되어 있어야 한다.

 

추가적으로 DMU가 변환해야 하는 database에는 아래와 같은 사항을 체크해야 한다.

(필수 사항은 아님)

 

l  standard PL/SQL package에 의해 생성된 object를 포함하여, DBMS_RULE, DBMS_DATA_MINING, 또는 DBMS_WM등의 모든 database object는 반드시 ASCII 문자집합의 표준 문자를 사용하여 naming 되어야 한다. 마찬가지로 CHECK 제약사항의 표현식, virtual column이나 다른 database feature도 표준 문자를 사용해서 만들어야 한다.

l  미리 정의된 system workspaces 와 Oracle Applications workspaces 외의OLAP analytical workspaces는 존재해서는 안된다.

l  flashback data archive가 database 안에 없어야 한다.

l  변환 대상중에 offline되거나 read-only된 tablespace가 없어야 한다.

l  cluster key column 과 partition key column 둘 다 character length semantic로 정의되어야 한다.

l  Recycle bin안의 table에 있는 data는 변환되지 않는다.

l  reference partitioning key column의 data는 변환되지 않는다.

 

DMU에서는 12c의 PDB migrate도 지원한다. CDB에서 DMU를 사용해 PDB로 convert하는 경우, root 컨테이너의 character set이 migration되는 대상 character set과 동일해야 한다. 물론 동일하지 않아도 DMU에 의한 스캐닝 작업이나 클리닝 작업은 가능하지만 convert 작업은 허용되지 않는다.

 

   4.1.2. Java runtime 요구사항

DMU는 java 기반의 GUI tool이며, 2.1 버전 이하는 J2SE SDK 6 이상(Java JDK 1.6 or later), 2.2버전은 JDK 8이 필요하다.

 

   4.1.3. DMU 보안에 대한 고려

DMU에서는 connect 하는 유저에게 SYSDBA권한을 필요로 한다. 따라서 일반적인 사용자에게 migration repository database objects(DUM$ 또는 DBMS_DUMA로 시작하는 object들)에 대한 권한을 부여해서는 안된다.

만약 DMU가 공유 workstation이나 server에 설치된다면, 반드시 install file을 소유자만이 수정가능 하도록 해야 한다.

 

4.2.    Install & Setting DMU

Oracle에서는 빠르고 안정적인 local area network를 가진 database server host또는 여기에 연결된 workstation에서 DMU를 수행할 것을 권고한다.

 

Download URL: http://www.oracle.com/technetwork/database/database-technologies/globalization/dmu/downloads/index-330959.html

 

DMU Clinet 설치 절차는 아래와 같다.

 

[Target databae]

$ sqlplus “/as sysdba”

SQL> @?/rdbms/admin/prvtdumi.plb

  

 

[UNIX / LINUX]

$ cd $ORACLE_HOME $ mv dmu dmu.bak  (or delete) $ cd (dmu install file을 unzip한 위치) $ mv dmu $ORACLE_HOME/   $ chmod 744 dmu.sh   à 설치 직후에는 644로 되어 있다. $ ./$ORACLE_HOME/dmu/dmu.sh   Unix provide on the "specify the full pathname of a J2SE installation" prompt the $ORACLE_HOME/jdk FULL path (alias가 아닌 full path를 기재) à (예시) /home/oracle2/product/12.2.0/dbhome_1/jdk   path를 잡아주면 다음 실행부터는 자동으로 적용되어 재차 묻지 않는다.   à 기존에 설치한 이전 버전의 DMU가 있을 경우, 구성정보를 import할 수 있다.

 

 

[Windows]

보통 DMU를 사용하여 작업하는 업무PC는 대부분이 Windows일 것이다. 다운받은 zip file을 unzip후, exe 파일을 실행한다.     JDK home을 입력한다. à (예시) C:\jdk (요구사항보다 낮은 java 버전일 경우 수행되지 않는다.)

 

[Start page]

 

   4.3.    Create db connect

DMU로 migration 및 analyze를 하려면 target db의 접속에 사용할 connection 정보가 필요하다. tnsnames.ora 에 설정한 접속 정보와 동일하게 입력한다.

 

[tnsnames.ora]

 

[Create database connection]

 [File] à [New Database Connection] 혹은 Navigtor pannel의 database에서 우클릭.

 

l  Connection name : DMU에서 사용하는 접속명

l  User name : SYSDBA 권한을 가진 유저

l  Password

l  Role : only SYSDBA role

l  Host Name : 지정된 DNS name이나 IP

l  Port : net serveice (TNS) 리스너의 TCP/IP port

l  Service Name : 접속하려는 instance의 service name

 

[Save]로 등록을 완료하면 navigator 패널에 해당 connection name의 brunch가 생성된다. Test connection으로 연결 테스트도 가능하며, status: Success라고 뜨는 경우 정상적으로 연결이 가능하다.

 

   4.4.   Install Migation Repository

Target database에 처음으로 접속하는 경우, repository를 구성해야 한다.

 

à [Next]

이전에 사용한 profile을 export해 놓은 output file이 있다면(아래 그림 참조), import하여 repository를 생성할 수도 있다.

[▲export migration profile wizard 실행]

 

Migrate할 target database의 character set을 설정한다. (recommand는 AL32UTF8)

à [Next]

Repository를 구성할 tablespace를 지정한다.

default tablespace는 SYSAUX이며, recommand는 repository tablespace를 만들어 따로 분리하여 조각화를 방지하는 것이다.

 

Tablspaces의 필요 size를 산정하기 위해서는 현재 covert가 필요한 table의 size를 확인해야 한다.

SELECT CEIL((t.cnt*300+c.cnt*1000)/1048576)||' MB' "Initial Size" FROM (SELECT COUNT(*) cnt FROM sys.tab$) t, (SELECT COUNT(*) cnt FROM sys.col$ WHERE obj# IN (SELECT obj# FROM sys.tab$) AND BITAND(property,65536)=0 AND type# IN (1,8,58,96,112) AND charsetform=1) c ;

 

à [Finish]

작업에 필요한 공간은 전체 data의 scan을 위해 설정한rowid collection level에 따라, 그리고 character data의 전체 양에 따라 달라진다. 때문에 지정한Tablespace가 전체 disk 공간을 소모하지 않도록 maximum size를 지정하는 것이 좋고, autoextend on으로 설정하여야 한다.

 

최초로 한번 repository를 생성하면, 다른 client에서 접속을 하더라도 정보가 계속 남아있게 된다.

 

   4.5.    Scan the Database

Migration과 관련된 정보들은 DMU의 메인 패널에서 확인 가능하다.

Migrration status 탭에서 step별로 진행상황을 확인할 수 있다. 현재는 migration repository만 설치된 상태이므로 step 2부터 진행한다.

Step 2. 의 Next Action을 눌러 Database를 scan하게 되면 scan wizard를 생성하게 된다.

 

à [Next]

 

 

Database를 scan 하는데에 사용되는 process 수를 지정할 수 있고, scan buffer size도 설정 할 수 있다.

 

Table에 대한 initial rowid collection level을 지정하여 scan할 수 있는데,

ⓐ "Collect rowids only according to 'Rowids to Collect' table property" 는 DMU가 table의 속성인 'Rowids to Collect' 값을 각 table의 initial rowid collection level 수준으로 사용하는 것을 말한다.

ⓑ "Collect also rowids for Update Convertible Rows conversion method" 는 DMU가 "Update only convertible rows" 를 위해 rowid 주소를 미리 사전 수집(pre-collection)하는 것을 말한다.

이 옵션을 사용하면 initial rowid collection level이 "All to Convert"로 설정되고, 선택된 모든 table에 대해 속성 rowid가 수집된다. 일반적으로 이 방법은 convert가 시작되는 단계에서 자동으로 실행되는 추가 scan시 수행된다.

사전 수집된 rowid에 변경사항이 생겨서 추가적인 scan이 필요해 진 경우, downtime 시간을 최소로 해야 하는데, 만약 추가로 convert 해야 하는 row가 마지막 scan과 비교하여 많이 추가 된 경우, convert 직전 단계에서 재수집을 해야 하므로 퍼포먼스적 문제가 있으며, data가 틀리게 인코딩 될 수도 있다. 따라서 사전 수집기능은 변경사항이 거의 없는 큰 table에 대해서만 선택적으로 수행하는 것이 좋다.

"Collect also rowids for Update Convertible Rows conversion method" 는 table에 conversion method가 할당(assign)되지 않았으므로, 최초 scan의 경우에는 첫번째 옵션과 차이점이 없다.

ⓒ "Do not collect rowids"는 scan중에 rowid를 수집하지 않겠다는 옵션이다. Convert 해야하는 cell이 다량이면서 issue가 많을 경우, 그리고 scan한 table에 대해 Cleansing Editor 를 이용한 filtering option을 사용하지 않을 생각이라면 매우 유용하다. Rowid collection은 sys schema에 있는 dictionary table 같은 특수한 table에 대해서는 off 할 수 없고, 이러한 dictionary table들은 "Rowids to Collect"이 [All to convert]로 고정되어 있다.

 

Scan할 대상을 Database나 application Schema 단위로 선택이 가능하다.

à [Next]

 

 

 

Rowed to collect도 변경 가능하다.

dictionary table의 경우에는 all to convert로 고정되어 있다.

à [Finish]

 

 

Scan이 종료되면 migration status 탭에서 상세한 결과를 확인할 수 있고, issue해결 후 retest도 가능하다.

 

현재 이DB를 바로 convert할 수 없는 이유가 나열되어있다.

[View the scan report]를 클릭하여 어떠한 문제가 있는지 확인할 수 있고, Cover column limit 에 표시된 숫자를 클릭하여 상세 확인 및 수정이 가능하다. 아래 그림에서는 over column limit문제로 6개의 row가scan된 것이 확인된다.

 

[View the scan report] 의 modify column기능을 이용하여 column 길이를 조정하거나, data 자체를 수정할 수도 있다. (자세한 사항은 cleansing 항목을 참조)

 

 

Apply 후 database에서 확인하면 column이 수정되어 있는 것을 확인할 수 있다.

 

 

혹은 수정해야 하는 issue가 많을 경우, report 자체를 xls 파일로 내려받아 확인하는 것이 가능하다.

 

좌측 그림처럼 navigator에서 problem data report를 누르면 wizard가 실행되어, column에 대한 report를 확인 할 수 있다.   ※ dog table은 varchar2(10)의 name이라는 column을 가지고 있다.

 

 

 

문제가 있는 데이터를 선별적으로 원하는 조건을 걸고 엑셀화 할 수 있다.

 

 

Unicode로 변경되면서 글자 당 2 bytes 에서 3 bytes로 늘어난다. 때문에 data의 뒷부분이 잘리게 되므로 report의 over column limit tab에 기재된 것을 확인할 수 있다.

 

DMU에서 warning이 발생하는 경우는 다음과 같다.

-       유저가 정의한(user-defined) OLAP analytical workspace가 존재하는 경우

-       Standby database인 경우

-       convert해야 하는 데이터가 external table에 들어있는 경우

-       database에 convert되는 primary key-based의 OIDs(object identifiers)가 있는 경우

-       row movement가 disable되어 있어 CTAS를 이용해야 하는 경우.

-       Conversion performance 를 향상시키기 위하여 Database 혹은 tablespace의 FORCE LOGGING mode를 Turning off 해야 할 때. (대신 media recovery의 abillity가 저하되는 trade-off 有.)

-       row movement option이 enable로 설정되지 않아 일부 Partition table의 convert시에 ORA-14402에러가 발생하는 경우.

-       일부 테이블이 conversion scan에서 제외된 경우.

-       일부 Column의 호환 이슈를 무시하고 convert할 경우.

 

Scan 결과에서 나온 warning을 무시하고 convert하는 것도 가능하다.

하지만 붉은 색으로 표시되는 blocking issue는 해결하지 않고 진행할 수는 없다. Step 3에 "No unresolved convertibility issue found" 가 표시된 후 convert 하는 것이 안전하다.

 

만약 테스트 변환에서 data자체의 이슈가 발생할 경우, DMU는 다음과 같이 문제를 분류해 scan report에 row를 counting한다.

 

-       Need no conversion : convert가 필요하지 않음

-       Need conversion : convert가 필요함

-       Invalid Binary representation : 잘못된 이진 표현식이 있음

-       Exceed column limit : column limit으로 인해 잘리는 data가 있음

-       Exceed data type limit : data type의 limit으로 인해 잘리는 data가 있음

 

예를들어, dog table이 가지고 있던 over column limit 문제는 exceed column limit이슈로 분류된다.

 

** Cleansing과 관련된 사항은 7. Using the DMU to Cleanse Data를 참조

5. Data conversion

5.1.    Data conversion 준비

OR

 

위에서부터 진행해왔던 대로 Migration status 탭에서 step 4를 누르거나, Migration 메뉴에서 convert database를 누르면, DMU 는 3가지 사항에 대해 변환 가능성 테스트(conversion feasibility test)를 수행한다.

-       요구사항에 따른 모든 database의 변환 가능성.

-       Database의 유효한 scan결과.
(정리(cleaning) 작업에서 scan 결과가 무효화(invalid) 될 수 있음)

-       이진 표현식이나 length 관련 이슈 유무.

 

만약 테스트가 성공하면, DMU는 수행 가능한 action plan을 SQL문 형태로 보여준다.

상기 결과를 확인해보면, 변경이 필요한 파라미터에 대한 command와, Trigger의 diable등을 제시하고 있다.

 

 

DMU가 데이터베이스를 변환하는 방식에 대한, database-level 및 table-level옵션이 여러가지가 있는데, 이것을 에디터로 커스텀할 수 있다. 예를 들어, 지정된 테이블에 대한 변환 방법 또는 변환 단계에 참여하는 프로세스의 수를 변경하고 싶다면, edit를 눌러 매개변수를 편집할 수 있다.

 

 

생성된 계획(command)를 step detail에서 확인하면, 아래처럼 database의 character set 변경과, convert 이후의 Task까지 제시하는 것을 확인할 수 있다.

 

 

 

만약 convert를 위한 parallel 수를 3으로 수정했다면, 아래와 같이 command가 수정되어 생성된다.

 

5.2.    Data conversion

이제 실제로 data를 convert 해서 Unicode character set으로 변경한다.

[Convert]를 클릭하면 step대로 conversion이 진행된다. DMU는 이 변환 작업에 issue가 존재하지 않아도, 다시 반복적으로 가능성 테스트를 수행하여 database를 체크한다. 또한 다른 세션이 database에 연결되지는 않았는지, database가 exclusive mode로 mount되었는지도 확인한다. 그런 다음에 plan에 따라 conversion을 수행한다.

Conversion progress 탭에서 진행상황을 확인할 수 있다.

 

DMU가 data를 convert하기 위해 사용하는 과정은 다음과 같다.

1.      Restricted mode로 database를 변경

2.      Job queue processe를 disable

3.      Index drop 혹은 disable.

4.      Triggers와 제약조건을 disable.

5.      User table와 data dictionary table의 데이터를 Unicode 로 Convert.

6.      Data dictionary 안의 CLOB column들을 convert

7.      Issue the ALTER DATABASE CHARACTER SET statement.

8.      Triggers 및 제약조건enable, indexe와 제약조건 재생성.

9.      Database instance parameter들을 restore.

 

Table의 conversion 은 update절에 의한 column update 혹은 CREATE TABLE AS SELECT(CTAS) 절에 의한 table 재생성으로 이루어진다. Table의 재생성은 거의 모든 row를 update해야 하는 경우, 속도가 더 빠르다.

Conversion이 완료된 후, DMU는 이전에 삭제되거나 diable설정된 모든 object를 다시 생성하거나 enable하도록 설정한다. 이 과정에 대한 오류발생 여부는 하단 log 창에서 확인이 가능하다.

 

5.3.    Object properties

Wizard를 이용하지 않아도 메인 pannel의 Database Properties tab (connect name, 아래 그림에서는LIONEL)을 클릭하면, 4개의 sub-tab에서 정보나 과정 확인, convert 작업 진행이 가능하다.

l  [General]

Connect 의 상세 내용과 database의 character set 정보를 확인할 수 있다.

 

ⓐ current database character set : Database에 적재된 data type(varchar2, char, long, clob)을 해석(interpret) 하기 위해 현재 정의된 database의 character set의 정보이다.

 

ⓑ assumed database character set : DMU는 문자 data를 scan/ convert하는  과정에서, 설정되어 있는 가정(assume) character set을 사용할 수 있다. pass-through구성에서는 database에 설정된 character set과는 다른 data를 client workstation의 설정에 따라 적재할 수 있으며, 이러한 경우 database의 실제 character set을 식별한 후, 이를 Assumed Database Character Set으로 설정하여 DMU가 데이터를 해석(interpret- 정확히는 사용자가 보기 쉽게)할 수 있도록 돕는다.

 

ⓒ target database character set : UTF8 혹은 AL32UTF8로 target character set을 지정한다. 이 값을 변경하기 위해서는 migration repository를 새로 install해야 한다.

 

l  [Scanning]

Scan과 관련된 process를 컨트롤할 수 있으며, scan 결과와 database의 size를 살펴볼 수 있다.

 

ⓐ Number of Scanning Processes

database를 scan하는데 사용되는 process의 개수. 각 scan process는 DMU의 parallel thread와 이 thread가 만드는 server의 database session 로 구성되는데, 이 default 값은 database server의 CPU 수에 따라 달라진다. 

 

ⓑ Scan Buffer Size

DMU가 table을 scan할 때, 각 database server session에 allocate하는 buffer의 크기. Default size는 1000KB이다. buffer 공간의 크기는 scan 횟수에 이 buffer 크기를 곱한 값이다. 이 속성값을 늘리면 scan 속도가 빨라질 수 있지만, 할당된 buffer memory가 server의 가용 RAM에 맞게 설정되어 있는 경우에 한한다.

 

ⓒ Scan Status

-       Never scanned : migration repository가 설치 된 후 한 번도 scan되지 않음

-       In progress : 현재 scan 진행 중.

-       Scanned : database의 모든 table이 scan되어 유효한 검사 결과가 나옴.

-       Partially scanned : 일부 table에서 유효한 scan 검사 결과가 나왔으나 일부 table은 아직 scan이 되지 않았거나, cleaning 작업 또는 DMU 외부의 metadata수정으로 scan 결과가 무효화 된 경우.

-       Issues found : 하나 이상의 table이 convert에 관련된 이슈를 포함하고 있는 경우.(길이 제한, 유효하지 않은 2진 표현식, data dictionary에 변경데이터가 있는 경우 등)

-       Failed : 하나 이상의 table에서 error로 인한 실패가 있는 경우.

 

ⓓ Tables to Convert

convert가 필요하다고 식별된 table의 수

 

ⓔ Rows to Convert

convert가 필요한 table의 Convert property values 의 row 합계

 

ⓕ Scan Results

-       Invalid binary representation : 잘못된 이진 표현. column에 설정된 character set이 잘못되었거나, image 혹은 암호화된 데이터 등 이진 형식 데이터의 일부 문자 코드가 손상되었을 경우.

-       Exceed data type limit : convert 후의 cell data가 data type이 지원하는 길이보다 긴 경우.

-       Exceed column limit: convert 후의 cell data가 설정된 column의 길이보다 긴 경우.

-       Need conversion : cell data를 반드시 convert 해야 하는 경우.

-       Need no conversion : convert해야 하는 data가 없는 경우.

 

cell에는 사전 범주에 2번 분류(assign)된다. 첫번째 분류는 “Current data” 탭 아래에 나오는 내역으로, 현재 컬럼의 정의를 기반으로 기재되는 정보이다. 두번째 분류는 "Including effects of scheduled cleansing" 탭 아래 나오며, 어플리케이션에 스케쥴된 정리(cleansing) 작업에 따른 결과를 바탕이 된다. 데이터가 변환 단계에서 실제로 유발할 수 있는 오류가 나오므로 필요한 정리(cleanse) 작업을 확인할 수 있다. 만약 모든 정리작업이 삭제된 경우, “Current data” 탭을 참고하여 convert를 준비할 수 있다.

 

ⓖ Database Size

현재 database의 tablespace별 정보이다.

 

ⓗ Estimate Tablespace Extension

DMU가 모든 tablespace에 대한 최대최소의 확장 가능 사이즈 예상치를 산정해준다. 버튼을 클릭하면 아래와 같이 정보 컬럼이 확장된다.

 

 

l  [Readiness]

아래 세가지의 값 중 하나가 표시된다.

 

ⓐ Does not need conversion : scan 결과 convert가 필요하지 않음.

ⓑ Ready for conversion : convert를 진행해도 되는 상태.

ⓒ Not ready for conversion : convert 전에 해결해야 하는 issue가 있음.

 

l  [Converting]

 

[Conversion Method]

-       Exclude from conversion :

-       Copy data using ‘CREATE TABLE AS SELECT’ (CTAS)

-       Update all rows

-       Update only convertible rows

-       Scan and update only rows changing in conversion

 

상기 방법을 고려하여 convert setting을 할 수있다.

DMU는 자동적으로 각각의 scan한 table에 대해 한가지 이상의 convert method를 제시(assign)한다. 만약 작업자가 생각하기에 더 좋은 방법이 있다면, DMU의 추천을 무시하고 변경할 수 있다.

 

ⓐ Degree of Parallelism

CTAS를 이용해 convert를 하게 된다면, 이 항목으로parallel degree를 조정할 수 있다.

 

ⓑ Number of Converting Processes

**4.5의Data scaning 참조.

 

ⓒ Enable Row Movement for Partitioned Tables

range혹은 hash Partitioning key column 값을 convert하게 되면 현재 row를 포함하고 있는 partition이 아닌 다른 partition을 가리킬 수 있다. 만약 키 값이 성공적으로 update하려면, Database는 반드시 old partition에서 new partition으로 row를 move해야 하므로, 이 항목을 yes로 설정하면 DMU가 일시적으로 Row Movemen를 enable로 전환하게 된다.

 

ⓓ Consider CTAS with Row Movement Disabled

CTAS를 사용하여 table을 convert하면, table 내의 row의 물리적인 주소가 변경되기 때문에, 이러한 주소를 static하게 설정한 어플리케이션의 경우 원하는 row를 찾지 못할 수 있다. DMU는 기본적으로 ALTER TABLE ENABLE ROW MOVEMENT 가 설정되어 있지 않은 table에 대해 CTAS를 사용하도록 권고하지 않는다. (게다가 새로 만들어진Table은 row movement가 default로 disable되어 있다)

만약 application이 특정 rowid를 찾도록 connect되는 방식이 아니라면, [Consider CTAS with Row Movement Disabled] 설정을 yes로 설정해서 DMU가 enable여부와 관계 없이 CTAS conversion method를 고려할 수 있도록 할 수 있다.

 

ⓔ Consider CTAS with User-named LOB Segments

기본적으로 DMU는 table의 LOB segment를 CTAS로 convert하도록 권장하지 않는다. LOB segment의 name을 CTAS로는 동일하게 가져갈 수 없기 때문이다. 만약 유저가 직접 설정한 LOB segment name이 존재한다면 이 항목을 NO로 설정해야 한다. 만약 LOB segment name을 보존할 필요가 없다면, YES로 설정 하여 CTAS로 convert 하는 것을 고려할 수 있다. ("$DMU"를 붙여서 rename함)

 

ⓕ Handling of Read-Only Materialized Views

이 항목은 master table convert 후의 read-only Materialized view(이하 mview)에 대한 항목이다.

-       Refresh Automatically After Conversion

default 옵션이며, convert 후 자동적으로 read-only mview를 refresh한다.

-       Generate SQL Script

Read-only mview를 자동적으로 refresh하지 않고, SQL script를 생성하여 DMU 외부에서 refresh를 수행하도록 한다.

-       Do Nothing

read-only mview에 대해 아무런 action을 하지 않는다.

 

ⓖ Handling of Updatable MViews

Master table을 convert한 후 Updatable mview(*생성시 for update 절을 포함해 생성한 mview)와 관련된 항목이다.

-       Refresh Automatically After Conversion

mview를 convert후 자동으로 update한다.

-       Generate SQL Script

mview를 자동적으로 refresh하지 않고, SQL script를 생성하여 DMU 외부에서 refresh를 수행하도록 한다

-       Do Nothing

Default 옵션이며, updatable mview에 대해 아무런 action을 하지 않는다.

 

ⓗ Error Handling for Refreshing or Recreateing Materialized Views

mview에 대한 재생성이나 갱신 시의 오류를 처리하는 방법에 관련된 항목이다.

-       Suspend Conversion and Ask

실패한 sql문을 일시 중단하고, 사용자에게 적절한 작업을 선택하도록 한다. 이 옵션은 default로, 사용자는 실패한 구문에 대해 retry나 script로 떨구는 것, 혹은 skip하는 것도 가능하다..

-       Skip Failing SQL and Continue

실패한 sql문제 대해 자동으로 skip후 이어수 convert한다.

-       Export Failing SQL to Script and Continue

실패한 sql 구문을 external script로 자동으로 export 해서 DMU 외부에서 convert를 수행할 수 있도록 한다.

 

ⓘ Handling of Dropped Domain Indexes

drop된 domain index에 관련된 항목이다.

-       Recreate Automatically After Conversion

Convert 후 자동으로 drop된 domain index를 recreate 하는 옵션이다. (default)

-       Generate SQL Script

Drop된 domain index를 다시 생성하는 대신 DMU 외부에서 수행할 수 있는 sql script를 생성한다..

-       Do Nothing

Drop된 domain index에 대해 아무런 action도 하지 않는다.

 

ⓙ Error Handling for Recreating Domain Indexes

이 항목은 domain index를 재생성하는 것과 관련된 항목이다.

-       Suspend Conversion and Ask

실패한 sql문을 일시 중단하고 사용자가 적절한 action을 선택하도록 한다. Defult 옵션이며, 실패한 sql문을 재수행하거나, script로 떨어뜨리거나, skip하는 것이 가능하다.

-       Skip Failing SQL and Continue

자동적으로 실패한 sql문을 skip후 convert를 계속 진행한다.

-       Export Failing SQL to Script and Continue

실패한 sql에 대해 DMU외부에서 convert를 수행할 수 있도록 external script로 export 한다.

 

ⓚ Error Handling for Rebuilding Other Indexes

에러 발생으로 rebuild 한 index와 관련된 항목이다.

-       Suspend Conversion and Ask

실패한 sql문을 일시 중단하고 사용자가 적절한 action을 선택하도록 한다. Defult 옵션이며, 실패한 sql문을 재수행하거나, script로 떨어뜨리거나, skip하는 것이 가능하다.

-       Skip Failing SQL and Continue

실패한 sql문에 대해 자동적으로 skip하고 계속 convert를 진행한다.

-       Export Failing SQL to Script and Continue

실패한 sql에 대해 DMU외부에서 convert를 수행할 수 있도록 external script로 export 한다.

.

ⓛ Directory for the SQL Scripts and its location (Browse button)

지정한 위치에 sql script가 다음 이름(default)으로 생성된다.

-       read-only materialized view refresh script
(RefreshMV_connectionName_timestamp.sql)

-       updatable materialized view refresh script
(RefreshUpdMV_connectionName_timestamp.sql)

-       domain index recreation script
(DomainIndexDDL_connectionName_timestamp.sql)

-       fail된 mview refresh SQL script
(FailedMVRefresh_connectionName_timestamp.sql)

-       fail된 domain index 재생성 SQL script
(FailedDomainIndex_connectionName_timestamp.sql)

-       fail된 기타 index rebuild SQL script
(FailedOtherIndex_connectionName_timestamp.sql)

 

script 위치를 convert 중에 변경하면, 그 다음 script 생성부터 적용된다.

 

이제 database를 unicode로 convert할 수 있다.

 

 

[convert전]

[convert후]

 

6. Advanced Topic in DMU

DMU를 사용하는데 있어서 추가적으로 확인해야하는 topic들이 있다.

아래와 같은 Convert 대상에서 제외하는 방법, access가 불가능한 데이터에 대한 핸들링, Data dictionary과 관련된 사항들, 그리고 다중언어 컬럼(Multilingual Columns) 등이다.

 

6.1.   Excluding Columns and Tables from Migration

아래와 같은 특정 상황에서, 사용자는 원하는 column이나 table을, scan과 convert 단계에서 제외할 수 있다.

 

ⓐ single column에 multiple character set인 경우.

 

ⓑ character column에 이진 data가 포함되어 있는 경우.
RAW, LONG RAW, BLOB 등의 이진 데이터는 이관이 불가능하다. application에서의 database access를 수정해야 하기 때문에, pass-through 구성에서는 convert를 원하지 않을 수도 있다.

 

ⓒ convert 대상이 아닌, TB단위의 매우 큰 table.

-       Application의 Internal code, yes/no 플래그, 신용카드 번호 혹은 basic ASCII 코드로 이루어진 데이터를 가진 table.

-       End user의 키보드가 non-ASCII문자가 지원된다고 하더라도, 영문자만을 입력 받은 table.

 

큰 table에 대한 scan time을 줄이고 싶다면, 이런 table들을 한번 수행 후 2차 scan 작업부터는 제외할 수도 있다.

 

ⓓ 매우 큰 table의 경우와 마찬가지로, 느린 storage 에 archival data용으로 적재된 read-only tablespaces도 제외하고 scan하는 것이 가능하다. (당연히 convert가 필요없다는 확신이 있어야 한다)

 

ⓔ read-only tablespace 혹은 table은, read/write로 변경하지 않으면 convert할수 없다. 때문에 이러한 tablespace나 table를 Unicode로 변경하길 원한다면, convert 전에 일시적으로 read/write로 변경 하여 DMU가convert를 수행 한 후 다시 read-only로 되돌리는 방법을 사용해야 한다.

 

ⓕ read-only tablespace와 마찬가지로, online 상태로 전환할 수 없는 offline tablespace혹은 offline datafile이 있는 경우, DMU는 그 data를 scan하거나 convert할 수 없다. 하지만 사용자가 이를 제외한 나머지 부분의 convert를 원하거나, offline data들을 추후 사용할 의도가 있다면, DMU의 유효성 검사 모드(validation mode)로 나중에 convert가 가능하다.

 

※ ⓔ와 ⓕ의 경우, 자세한 내용은 6.2. "Handling Non-Accessible Data"를 참조.

 

Table을 scan에서 scan wizard의 object 선택 페이지에서 간단히 클릭으로 지정해 제외할 수도있다. Column을 convert에서 제외하려는 경우, [Column Properties tab]의 Viewing and Setting Column Properties 를 열고 Converting subtab의 conversion 속성을yes로 변경해 제외할 수 있다. DMU에서는 convert 단계로 갈 수 없게 만드는 호환성 문제를 체크할 때, conversion 과정에서 제외된 column은 확인하지 않는다. 만약 table을 conversion 단계에서 제외하면 포함된 모든 column이 convert에서 제외된다.

(database scan report에서 해당 table의 컬럼을 우클릭 해도 설정 가능하다)

 

[Allow Conversion of Data with Issues] 를 yes로 설정할 경우, 해당 컬럼에 있는 모든 이슈를 무시하고 convert를 진행할 수 있다. 만약 [Exclude from Conversion]를 yes로 설정할 경우 이 컬럼은 conversion 단계를 skip한다. 이전 character set의 데이터로 남겨두겠다는 이야기다. 물론 이런 경우에는 DMU로convert후 수동으로 추가작업을 해야 한다는 것을 염두에 두어야 한다.

 

6.2.   Handling Non-Accessible Data

Database에 있는 특정한 type은 application에서 access가 불가능할 수도 있다. 이러한 data는 update나 read가 불가능 하므로 DMU도 핸들링 할 수 없다. Access가 제한(restrict)되는 data는 다음과 같은 object 들이다.

 

6.2.1. Read-Only Tables 고려사항

11gR1이후의 모든 oracle database는 table의 read-only mode를 지원한다. 따라서 사용자는 update로부터 table의 내용을 보호하기 위해 read-only mode로 table을 변경할 수 있는데, 이러한 table들은 segment를 move하거나 shrink, expand하는 것은 가능해도 column은 (어떤 방식으로도) 수정할 수 없으며 row를 추가할 수도 없다. DMU는 table의 convert 작업 전에 자동으로 read-only table을 read/write table로 변환한다. 그리고 convert가 종료된 후 다시 read-only로 변환하게 된다. read-only table은 물론 CTAS를 이용해 table을 재생성하는 방식으로 convert를 수행할 수도 있다.

 

6.2.2. Read-Only Tablespaces 고려사항

Tablespace를 read-only로 설정하면 data가 변경이 되지 않는다. 사용자는 Read-only tablespace의 data file을 read-only media(CD-ROM등)에 적재할 수 있고, access가 적은 저장용(archived) data의 경우 저가의 storage를 사용할 수도 있다. 물론 일반적인 read/write disk storage에 적재할 수 있다.

 

만약 partition, CLOB, varray, IOT overflow segments 를 포함한 table과 read-only talespace의 segment를 convert하는 경우에는 DMU가 정상적으로 convert할 수 없다. DMU는 convert와 관련된 issue를 migration status tab에 report 하고, 문제가 해결되기 전까지는 coversion 단계로 넘어가지 않는다.

 

Convert 관련 issue를 해결하기 위한 접근방식에는 tablespace가 왜 read-only로 전환되었는가에 따라 달라진다. 만약 백업시간을 줄이기 위해 전환되었고, standard disk device에 저장되어 있다면 tablespace을 read/write 로 전환하고 convert 후 다시 read-only로 변경한 뒤에 backup을 갱신(refresh)하면 된다.

 

만약 tablespace를 read-only로 변경하고 read-only media로 move할 경우, 아래 사항을 고려해야 한다.

 

ⓐ convert할 data가 있는 모든 read-only tablespace에 대해 충분한 disk storage 공간을 (임시적으로든 영구적으로든) 준비할 수 있다면, 이 storage에 tablespace를 copy하고, read/write로 전환 후 다른 data들과 함께 convert할 수 있다.  Read-only로 재전 후 다시 read-only media로 밀어넣을 수 있다. 물론 convert해야 하는 read-only tablespace의 비율이 많은 경우 이 방법은 실행이 불가능하다.

 

ⓑ main database와 같은 character set으로 auxiliary database를 만드는 경우, 즉 복제된 db의 read-only tablespace를 논리적으로 TTS를 이용해 이관하여 현재 위치에 물리적으로 파일을 남겨둔다. main database에 Database link를 생성해 새로 생성된 db를 바라보게 한다. auxiliary view를 만들거나 application을 변경함으로써, auxiliary database안의 read-only data를 main database에 연결된 application에 보이도록 하면, database link를 통해 transport하면서 convert할 수 있다.

 

6.2.3.  Offline Tablespaces 와 Data Files Considerations

Tablespace나 그 안의 data file을 offline으로 변경할 경우, 그 안의 data에 대한 변경이나 읽고 쓰기가 불가능해진다. Offline tablespace는 data file에 대한 다양한 administrative operations(예를 들자면 rename이나 다른 storage로의 move)이 필요하다.

partition, LOB, VARRAY, IOT overflow segments를 비롯한 table의 segment가 convert가 필요할 수도 있는 문자 data를 포함하고 있으면서 offline tablespace/data file에 속한 경우, DMU는 scan과 convert 모두 수행할 수 없다. 반드시 scan 및 convert전에 online으로 변경해야 한다. 그렇지 않으면 ORA-00376같은 에러가 발생한다(Migration Status tab에 report 된다).

 

6.2.4.  Working with External Tables

external table은 table전체가 database의 바깥쪽에 존재하는데, table의 column정의(metadata)만 database에 존재하고, table을 참조하는 query가 실행되면 external file에서 row를 가져오게 된다. Oracle database는 external file읽기 위한 2가지(ORACLE_DATAPUMP. ORACLE_LOADER)의 access driver를 지원한다.

 

External table을 수정하는 DML문은 지원되지 않는다. ORACLE_DATAPUMP external file은 ‘CREATE TABLE … ORGANIZATION EXTERNAL … AS SELECT’ 구문으로 external table을 생성한 경우, table에 data를 채워넣을 수는 있지만 나중에 database 내부적인 수정이 불가능하다.

ORACLE_LOADER file은 반드시 database의 외부에서 생성 및 수정해야 한다. DMU는 datanase의 내용(contents)과 마찬가지로 external file의 convert를 지원하지 않는다.

external table을 만들 때, data file의 character set은 아래 사항으로 확정(establish)된다.

 

ⓐ ORACLE_DATAPUMP file의 character set은 export 될 때 file자체에 저장된다.

ⓑ ORACLE_LOADER file의 character set은 external table 정의의 매개변수 절에 CHARACTERSET 파라미터로 지정되고, 만약 지정되어있지 않더라고 database의 character set을 이용하여 file의 내용을 해석(interpret) 한다.

 

만약 external file에 선언되어 있는 character set이 database와 다르면, database는 해당 파일을 읽는 동안 자동으로 convert를 수행한다.

만약 database의 character set이 변경이 되었다면 external file를 convert할 때 database가 자신의 새로운 구성으로 변경(adapt) 시킨다.

 

6.2.5. Cleansing External Tables

DMU가 external table을 convert하지 않더라도, migration process의 scan단계에 포함이 된다. Scan 결과에서는 새로운 unicode character set으로 migrate후 선언된 컬럼 길이안에 file contents가 다 들어가는지 여부가 표시된다. External file에 잘못된 character code가 있는지 여부도 확인할 수 있으므로 즉시 file내용을 변경하여 다시 scan하면 된다.

 

6.2.6. Cleansing Length Issues

만약 scan 결과에 external table contents의 length issue가 발견된다면, 해당 컬럼의 길이나 타입을 변경할 수 있다. DMU는 external table에 대한 cleansing 작업을 지원하지 않으므로, SQL*PLUS/SQL Developer등의 다른 툴을 이용하여 작업해야 한다. VARCHAR2 컬럼은 CLOB으로 변경할 경우 4000 bytes 이상 지원이 된다. CLOB으로 column data type을 변경하기 위해서는 반드시 external table을 re-create해야 하는데, Metadata만 변경이 되므로 빠르게 작업할 수 있지만 grants등의 종속적인 object는 다시 생성(적용)하는 번거로움이 있다.

 

6.2.7. ORACLE_LOADER File의 Correcting Character Set Declaration

만약 external table의 문자 값이 pass-though 구성에서 ORACLE_LOADER 드라이버를 통해 read되는 경우(지정한 character set과 database의 character set이 동일하지만 data content의 character set과는 다른 경우), external table definition의 access parameters절 안에 있는 real character set를 선언(declare)하는 것으로 구성을 고칠 수 있다. Convert 하기 전에 production database안의 선언문을 변경해서는 안되는데, pass-though 구성이 손상되어 table을 읽을 수 없게 되기 때문이다.

Database를 convert하기 전에, 영향을 받는 external table columns 의 [Assumed Column Character Set] 설정을 바꾸어야 한다. 그리고 다시 scan을 하면 DMU가 추가적인 length 문제나 잘못된 이진 표현식 문제를 다시 검색한다.

Oracle은 database에서 영향을 받는 모든 access parameter절의 수정 스크립트를 생성해 convert 단계 바로 직후에 수행할 것을 권고한다.

 

6.2.8. ORACLE_DATAPUMP File의 Correcting Character Set Declaration

만약 pass-through 구성에서 ORACLE_DATAPUMP 드라이버를 이용하여 external table을 read하는 경우, Data Pump 의 input file에 대한 tag를 unicode로 convert한 database의 실제 character set으로 올바르게 re-tag해줘야 한다.

상기 loader와는 다르게, data pump의 dump 파일 안에 설정되어 있는 character set 선언문은 쉽게 수정할 수 없고, 더 복잡한 procedure가 필요하다. 아니면 ORACLE_LOADER format으로 external table file을 제공해 access parameters 절 안의 character set 선언문에 대한 권한을 갖도록 할 수도 있다.

 

만약 data pump file(dump)을 pass-through 구성에서 사용하려고 한다면, export한 source database도 동일하게 구성되어 있어야 한다. 그렇지 않으면 잘못 tag된 파일로 생성이 된다. 따라서 data pump file의 character set 선언을 수정하는 가장 좋은 접근 방식은 source database의 character set을 고치는 것이다.

 

만약 source database의 character set에 대한 control 권한이 없다면, 반드시 아래와 같이 수행한다.

-       Data Pump file의 character set 설정과 동일한 auxiliary database 를 생성

-       (pass-though 구성이라면) Dump file을 Import

-       Dump file의 실제 character set으로 현재 database character set을 변경

-       (Unicode로 migrate후) file을 export하고 main database 의 external table 로 이용

참고로 Data pump file의 character set을 알아야 하는 경우가 있다면 그냥dump file를 vi editor로 열어서 확인하는 것이 빠르다.

 

6.2.9. Fixing Corrupted Character Codes

External table에서 잘못된 이진 표현식 이슈가 생긴다면, 그 중에서는 user error나 application defect, temporary configuration problem 의 결과로 character code자체가 corrupt 된 경우도 있다. source database의 올바른 값으로 다시 export 하거나 unload하면 된다. (물론 ORACLE_LOADER file은 잘못된 코드를 text editor로 직접 수정할 수 있긴 하지만 다시 새로 받는 것이 좋다)

 

6.2.10. Handling Binary Data

External table의 잘못된 이진 표현식 이슈는 external table 드라이버에 의해 문자 이터가 이진 데이터로 선언 및 패치(fetch)될 때 많이 발생한다. 이러한 이슈를 해결하기 위해서는, 반드시 대상 컬럼을 RAW나 BLOB등 external table이 사용하는 이진 데이터 타입으로 재정의(redefine)해야 한다.

oracle에서는 UTF8 또는 AL32UTF8등의 멀티바이트 character set의 database안의 이진 데이터를 fetch하기 위해 pass-through 구성을 사용하지 않을 것을 강력히 권고한다. 이러한 구성은 예상치 못한 문제들의 원인이 될 수 있다.

 

6.2.11. Performance Considerations for ORACLE_LOADER Files

Oracle Database Utilities Guide에 ORACLE_LOADER 드라이버의 성능을 위한 몇가지 힌트가 존재한다. 이러한 힌트는 특히 Unicode로 convert되는 character set의 context와 연관이 있다.

-       Single-byte character set이 가장 빠르게 처리된다.

-       고정길이 character set이 가변길이 character set 보다 빠르게 처리된다.

-       가변길이 character set는 Byte-length를 구하는 것 보다 character-length를 구하는 것이 빠르다.

-       Data file에 설정된 character set을 database의 character set에 맞추는(match) 것이, character set conversion보다 빠르다. 

 

만약 ORACLE_LOADER file의 현재 character set을 유지하거나, 새로운 Unicode database character set에 맞춰 file을 재배치 하는 것 중 선택해야 한다면 아래 사항을 참고해야 한다:

-       File의 현재 character set이 multibyte 라면, database의 character set (UTF8 혹은 AL32UTF8)을 이용한 구문분석 시간이 크게 소요되지 않는다. 즉, 파일의 record 및 field를 분할하는 쪽에 시간이 소요된다는 뜻이다. External table을 참조하는 query의 성능이 더 좋다.

-       File의 현재 character set이 single-byte라면, UTF8 혹은 AL32UTF8 character set을 이용한 구문분석이 느려지지만 conversion 시간이 절약된다.

-       Single-bytes character set을 UTF8 혹은 AL32UTF8로 convert하기로 했다면, query성능 극대화가 중요할 경우 field length와 position를 bytes대 character로 표현한다.

 

6.3.   Migrating Data Dictionary Contents

DMU는 소유자(schama)의 data dictionary에 기반해 table을 분류한다.

DMU가 data dictionary에 있다고 인식하는 schema는 Navigator panel의 Data Dictionary node에 표시된다.

만약 사용자가 (SYS 나SYSTEM 같은) data dictionary schema로 table을 만든 경우, DMU는 이를 다른 data dictionary table과 같이 인식한다. (아래 그림의 flower)

DMU가 dictionary table에 보관되어있는 metadata의 서브셋에 대해서만 character set conversion을 지원하므로, 아래 내용처럼 dictionary table과는 다르게 처리한다.

상기 이미지를 보면 우측 user table(dog)에 존재하는 editor가 좌측의 dictionary table(flower)에는 없는 것을 확인할 수 있다.

 

6.3.1. Scanning Data Dictionary Tables

대부분의 data dictionary table은 user가 만든 table과 동일한 방식으로 scan된다. 일반적인 convert issue (column 길이 제한이나 data type 제한, 잘못된 이진 표현식)도 동일하게 처리한다. 차이점이 있다면, unicode character set으로 convert가 필요한 data에 대한 report이다. 왜냐하면이 버전의 DMU는 몇가지 예외를 제외하고는data dictionary contents에 대한 convert를 지원하지 않기 때문이다. (non-convertible column에 포함된 data에 convert를 해야 하는 경우에는 노란 삼각형 경고 아이콘으로 표시되고, convert 단계로 넘어가지 않는다)

Database Scan Report filter 조건의 [With Some Issues] 를 선택여 문제가 있는 Data만 살펴볼 수도 있다.

 

[Viewing Data]의 view data 탭에 data dictionary와 non-modifiable tables을 위한 Cleansing Editor의 read-only version에 대한 서술이 있다. (오렌지와 검정으로 구별이 가능한데 색편집도 가능하다)

 

DMU가 convert하는 몇몇 column은 issue가 없는 경우 [Converting Data Dictionary Tables]에 리스트업 된다.

구현상의 이유로, SYS.SOURCE$, SYS.ARGUMENT$, SYS.IDL_CHAR$, SYS.VIEW$, SYS.PROCEDUREINFO$, and SYS.PLSCOPE_IDENTIFIER$ table들은 scan시 "Rowids to Collect" parameter가 "All to Convert"로 항상 지정되어 있다.

("Converting Data Dictionary Tables" 참조)

 

6.3.2. Cleansing Data Dictionary Tables

Oracle은 data dictionary의 구조를 바꾸는 것(altering structure)과 그 안의 컨텐츠를바꾸는 것, 둘 다 서포트 하지 않기 때문에, DMU는 이러한 table의 cleansing작업을 수행할 수 없다. Data dictionary table의 column에 character set를 설정할 수는 있지만, View Data 탭에 column이 표시되는 경우에만 설정한다. Convert를 위한 source character set은 언제나 database의 character set이다.

 

ⓐ Cleansing Data Length Issues

만약 data dictionary(metadata)의 내용에서 data length 이슈가 발견된다면, cleasing할 수 있는 유일한 방법은 metadata를 더 짧은 버전으로 replace하는 것이다.

 

가장 흔한 length 이슈는 object명이 convert후 허용된 길이보다 길어지는 것이다. 보통 (한글을 포함한)non-ASCII 문자는 제한된 30bytes를 초과하기 쉽다. 

이런 경우, database object의 rename을 고려해야한다. 어떤 object는 rename이 되지 않고 재생성해야 하는 경우도 있는데, 연관된 다른 object에 미칠 영향도 생각해야 한다. 예를 들어, table이나 view, swquence, private synonym은 rename이 가능하지만, cluster등은 간단히 rename이 불가능하다. 만약 cluster를 drop 하는 경우, privilege, index, trigger, row-level security policy, outline들에 영향이 있다. 이러한 경우에는 data pump나 metdata API가 도움이 될 수 있다.

Object를 rename한 후에는 PL/SQL이나 Java code등 application의 code가 참조하고 있는 이름까지 수정해야 한다.

 

또 다른 타입의 length 이슈는 다양한 object에 붙어있는 comment가 허용된 최대치를 초과하게 되는 것이며, 이 경우 적절한 SQL문 또는 PL/SQL 패키지로 수정할 수 있다.

 

ⓑ Cleansing Invalid Binary Representation Issues

잘못된(invalid) 이진 표현식의 가장 흔한 원인은 "Invalid Binary Storage Representation of Data"에서 서술된pass-through 구성이다.

만약 이런 구성에서 SQL문이나 PL/SQ call이 실행되는 경우, database의 character set과는 맞지 않는 문자가 포함되어 object가 생성될 수 있다.

 

Database object명에 Invalid한 이진 표현식이 들어가는 것은 식별자에 허용되는 문자 제한이 생성시에 직관적으로 보이기 때문에 발생하는 경우가 드물고, object의 comment에서 발생하기가 더 쉽지만 수정하기는 어렵지 않다.

 

pass-through 구성에서 잘못된 이진 표현식 문제를 해결하려면, database character set

설정을 database contents의 real character set으로 설정한다. 혹은 "Cleansing Data Dictionary Tables” 와 비슷한 접근방식으로 convertibility issues가 일어나지 않는 버전으로 metadata를 update하는 방법도 있다.

 

PL/SQL 과 Java source code, 혹은 view의 명세에 있는 잘못된 표현식 이슈는 metadata API를 사용하여 DDL 구문을 뽑아 object를 생성할 때 문제가 되는 문자를 수정 후 재생성하는 것으로 해결할 수 있다. CREATE OR REPLACE 구문을 시용하여 privilege같은 related objects를 변경하지 않고 코드를 수정할 수도 있다.

 

ⓒ Identifying Metadata

 

data dictionary의 호환성(convertibility) 문제에서 가장 어려운 단계는 database scan report에 표시된 이슈를 table 과 columns에 저장된 metadata의 type 에 mapping하는 것이다. DMU interface에 제공된 Data dictionary table은 data dictionary view (dba_tables, dba_tab_comlumns, dba_rules, dba_scheduler_jobs 등)로 확인해야 한다. .

 

호환성 문제가 있는 metadata의 type을 식별하려면, 아래 제시된 순서대로 하나씩 시도해볼 수 있다.

-       [View Data tab]에서 문제가 있는 문자값을 확인한다.

-       이슈가 발생한 table 이름을 cat*.sql/cd*.sql라는 sql script file에서 찾아본다($ORACLE_HOME/rdbms.admin/아래) 이러한 script는 [Oracle Database Reference] 에 문서화 된 data dictionary view를 정의 하는데, maaping된 table과 column/ 우측의 문서화 view를 비교하여 이슈가 있는 meradata를 확인할 수 있다.

-       MOS나 Oracle Technology Network Web site의 globalization forum에 질문을 올린다.

 

호환성 이슈로 report된 metadata를 식별한 후에는 oracle 문서를 참조하여 이 metadata를 change하기 위한 올바른 절차를 확인해야 한다.

 

6.3.3. Converting Data Dictionary Tables

DMU로 data dictionary를 convert할 수 있다.

-       CLOB columns – single-byte database에만 필요.

-       이름에 XDB.X$QN% 와 XDB.X$NM%가 포함된Binary XML token manager table.

-       PL/SQL source code
(CREATE PROCEDURE, CREATE FUNCTION, CREATE PACKAGE, CREATE PACKAGE BODY, CREATE TYPE BODY, CREATE TRIGGER, CREATE LIBRARY…);

단, CREATE TYPE..은 불가능.

-       View definitions (CREATE VIEW..)

-       아래에 해당되는column:

SYS.SCHEDULER$_JOB.NLS_ENV : Database Scheduler jobs (DBMS_SCHEDULER)의 NLS 환경설정.   SYS.SCHEDULER$_PROGRAM.NLS_ENV : Database Scheduler job programs (DBMS_SCHEDULER)의 NLS 환경설정   SYS.JOB$.NLS_ENV: : legacy jobs (DBMS_JOB)에 대한NLS 환경설정   CTXSYS.DR$INDEX_VALUE.IXV_VALUE : Oracle Text 정책(policy)의 속성값   CTXSYS.DR$STOPWORD.SPW_WORD : Oracle의 모든 *stoplist의 stopword   SYS, SYSTEM, CTXSYS schema에 포함된 50여개의column들과 다양한 object들의 comment.

* stoplist : oracle text에서 index화 되지 않는 단어(stopword)의 list. (예를 들어 영어의 this / that)

 

multiple table에 PL/SQL source code와 view source text가 보관되는데, DMU는 source code 와 view 정의를 처리할 때 필요한 관련 column들을 check한다.

 

SYS.VIEW$.TEXT : view 정의문. SYS.SOURCE$.SOURCE : PL/SQL 및 Java 의 source code SYS.ARGUMENT$.PROCEDURE$ : PL/SQL 인수 정의 (프로시저명) SYS.ARGUMENT$.ARGUMENT : PL/SQL 인수 정의 (인수명) SYS.ARGUMENT.DEFAULT$ – PL/SQL 인수 정의 (default값) SYS.PROCEDUREINFO$.PROCEDURENAME : pkg의 프로시저명과 function정의 SYS.IDL_CHAR$.PIECE : PL/SQL 의 내부(internal) 표현식 SYS.PLSCOPE_IDENTIFIER$.SYMREP : PL/SQL의 내부 표현식(11gR1~)

 

DMU는 상기 나열된 table과 column의 convert 이슈를 report하지 않는다.  

Data dictionary의 (convert가능한 data를 가진) table과 comlomn은 convert 이슈를 migration status탭의 scan report항목에서 flag를 통해 관리된다.

이 플래그 data가 삭제되지 않는 한 data convert는 진행되지 않는다.

 

6.3.4. Scan을 건너뛰는 Data Dictionary Tables

DMU는 아래 table을 scan 하지 않는다.

·         column histogram statistics를 포함한 SYS.HISTGRM$.

·         Automatic Workload Repository(AWR) object statistics history 가 있는 tables.
(SYS.WRI$_OPTSTAT_OPR 와 SYS.WRI$_OPTSTAT_%_HISTORY)

·         SYSTEM schema의 DMU repository table.

·         CSMIG schema에 있는 CSSCAN repository tables.

이러한 table의 내용들은 DMU의 고려대상이 아니다.

SYS.HISTGRM$ table은 EPVALUE column (end-point value)이 이진 데이터를 지고 있을 수도 있기 때문에scan에 포함되지 않는다. Histogram과 다른 테이블의 통계는, 문자 컬럼 안에 있는 데이터의 이진 표현식에 depend하기 때문에 모든convert된 re-gather 해야 한다. 통계수집을 통해 SYS.HISTGRM$ table의 내용이 갱신되고, 새로운 database character set 가 재확인(revalidate) 되는데, 만약 통계 갱신을 건너뛰에 된다면 옵티마이저가 잘못된 실행계획을 탈 수도 있다.

마찬가지로, AWR에서 가지고 있는 historical object 통계도 문자 데이터의 이진 표현식에 depend 하므로, convert 후에는 낡은 정보가 된다. DMU는 이러한 통계정보를 갱신하지 않는다. 때문에 convert후 DBMS_STATS.PURGE_STATS(SYSTIMESTAMP)를 이용해 수동으로 purge해야 한다.

DMU와 CSSCAN repository data는 새로운 character set으로 convert 된 후에는 invalid 상태가 되므로, 필요에 따라 drop, 재생성이 필요하다.

 

6.3.5. Automatic Workload Repository Table

 

SYS schema는 WRI$, WRH$%, WRR$_로 시작하는 AWR관련 table을 많이 가지고 있다.  "6.3.4. Scan을 건너뛰는 Data Dictionary Table" 에 언급된 historical object 통계 외에도, fixed view등의 virtual system 통계도 존재한다. 예를 들어 v$sysstat과 v$sqlarea 가 있다.

 

Non-ASCII 문자들을 SQL문(comment등)이나 object name으로 사용한 경우, AWR table에서 해당 정보를 찾을 수 있다. DMU scan은 호환가능한 data dictionary 컨텐츠 같은 문자들을 report하여 database의 convert를 방지한다. 이 data를 완전히 remove하려면, sqlplus에서 sysdba권한으로 아래 스크립트를 수행하여 AWR을 재생성 해야 한다.

SQL> @?/rdbms/admin/catnoawr.sql SQL> @?/rdbms/admin/catawr.sql

catawr.sql 은 10.2.0.4 이전 버전에는 존재하지 않는다. Oracle의 권고사항은 AWR contents를 purge하기 전에 10.2.0.5 patch set을 설치하는 것이다.

 

6.4.   Multilingual Columns

[Cleansing Incorrect Character Set Declaration]에 설명한 것처럼, Cleansing Editor에서 column 내용을 분석하기 위한 character set을 지정하지 않을 경우 모든 값이 동시에 정확히 표기되는 것을 발견할 수 있다. 하지만 각 값은 (선택한) character set중 하나를 따라 표기되는 것이다. 컬럼에 여러가지 character set이 혼재해 있을 경우, 원본 database 의 정확한 정보를 분석하는 것이 필요하다.

Pass-though 구성에서 Single column의 다중 character set 설정이 가능하고, 클라이언트가 이 컬럼에 다양한 character set로 모든 data를 적재할 경우 사용할 수 있다.

 

DMU 2.2 에서는 이러한 경우와 관련된 호환성 이슈를 해결하기 위한 기능이 추가되어 있지는 않다. Single CHAR 혹은 VARCHAR2 컬럼에서 다중 character set을 다루기 위해서는 아래 절차(6.4.1)를 따르는 것이 권고이다.

 

6.4.1. CHAR 혹은 VARCHAR2 column의 multiple character set 작업 방법:

ⓐ 영향을 받는 column 안에 있는 단일값의 실제 character set을 식별할 수 있는 auxiliary data를 찾는다.

-       값과 연관이 있는 국가 코드

-       값을 입력한 연산자의 식별자

-       값 입력을 담당하는 부수적인 식별자

ⓑ auxiliary data와 가능한 characer set의 값을 mapping하는 table을 만든다. 만약 회사에 표준화 된 특정 유형의 workstation이 있다면, 분석된 값의 source country는 입력 값의 client character set으로 정의한다.

ⓒ Convert에서 제외할 multiple character set의 data를 포함한 cloumn을 표시

ⓓ column의 length issue가 없는지 확인하고, 필요한 경우 길이를 조정하거나 값을 줄여 해결한다. (CLOB으로 migrate하지 말 것)

ⓔ database를 convert.

ⓕ mapping table을 이용하여, CONVERT 함수를 사용해 영향받는 컬럼을 convert 한다. (두번째 인수에 대상 Unicode character set을 지정, 세번째 인수에 identified value character set을 지정한다)

[Multilingual Column Considerations 예시] 특정 컬럼에 있는 값이 length issue에 해당하는지 체크할 수 있다. SELECT c.ROWI  FROM customers c, created_by_to_charset_mapping csm  WHERE VSIZE(CONVERT(c.customer_name_original, 'AL32UTF8', csm.character_set)) > 80  AND c.created_by = csm.created_by 동일한 함수로 database convert후, update한다. UPDATE customers c    SET c.customer_name_original =          (SELECT CONVERT(c.customer_name_original, 'AL32UTF8', csm.character_set)          FROM created_by_to_charset_mapping csm    WHERE csm.created_by = c.created_by) 이렇게 되면 가정한 character set(두번째 인수인 'AL32UTF8')에 따라 column의 개별 값이 변환된다.

 

6.5.   Advanced Convertibility Issues

아래처럼 조금 발생빈도가 적은 호환성 이슈가 있는데, 이러한 이슈들은 DMU에서 자동적으로 핸들링해주지 않으므로 DMU tool 외적으로 추가적인 스캐닝이나 클렌징이 필요하다. 

 

6.5.1. Convertibility Issues: 고유성 검증(Uniqueness Validation)

Unicode로 convert후, Table에 있는 일부 row의 내용이 더 이상 UK혹은 PK조건을 만족할 수 없는 두가지 경우가 있다.

①    UK혹은 PK column 의 길이 이슈. 즉, 길이제한으로 인하여 데이터가 깨지는 경우인데, "Allow Conversion of Data with Issues" 속성을 yes로 지정할 경우, DMU는 자동으로 뒷부분을 잘라(truncate)버린다. ‘아메리카노’ 와 ‘아메리카나’ 나 고유한 값이었다가, convert후 ‘아메리카’로 잘리는 경우가 여기에 해당된다.

②    다양한 oracle character sets 에서는 single Unicode code point에 multiple character codes가 mapping될 수 있으므로, 다음과 같은 문제가 발생하기도 한다

-       과거 Character set 변경이나 다른 벤더 간 해석(interpretation)에 대한 호환성 문제

-       Unicode에 정확히 mapping할 수 없는 코드를 위한 단순화된 mapping을 지원하지 못하는 문제. (실제 mapping은 Unicode 코드의 시퀀스로 구성되어 있는데, oracle 의 coversion architecture가 이를 지원하지 않는 문제 등)

-       Unicode 의 표준 통합 규칙 상 특정 그룹에 단일 코드 포인트를 할당하는 한문의 경우, 기존 동아시아 문자셋(legacy East Asian character set)으로 별도로 인코딩될 수 있음.

만약 단일 컬럼에 있는 두개의 문자값이 유니코드에 대해 동일한 mapping 값을 가질 경우, convert 후에 동일한 글자가 되어 버린다.

참고로 DMU가 지원하는 character set 중 동일한 unicode point로 mapping되는 한글조합형 multiple code는 KO16KSCCS이다. (거의 사용하지 않는다)

 

6.5.2. Convertibility Issues: 인덱스 크기

index key의 최대 사이즈는(모든 key 컬럼의 최대bytes 길이 합 + rowed 길이 + length bytes의 수) index의 table영역에서 약 25%의 오버헤드를 뺀 data block 크기를 초과할 수 없다.

만약 convert 중에 index key에 속하는 문자 컬럼의 최대 bytes 길이가 증가하는 경우, 아래와 같은 이유중 하나가 원인이 된다.

·         새 database의 character set의 column character length가 재계산됨.

혹은

·         길이 이슈 관련 cleansing action이 컬럼에 정의됨.

최대 bytes length로 인해, index key에서 허용하는 최대 length 보다 초과될 수 있다. 이런 경우, DMU 2.2 에서는 convert단계에서 변경되는 index key 길이를 사전에 확인하지 않는다. 따라서, "ORA-01450: maximum key length (maximum) exceeded" 혹은 "ORA-01404: ALTER COLUMN will make an index too large" 가 alter table/ create index/ alter database character set 구분에서 발생하게 딘다.

Convert를 시도하기 전에, 반드시 varchar2와 char 로 선언된 모든 index의 명세를 확인해야 하여 length 이슈를 피해갈 수 있도록 조치해야 한다.

 

6.5.3. Convertibility Issues: 파티션 범위 무결성(Partition Range Integrity)

DMU 가 partition bounds require conversion이 필요한 database convert를 지원하지는 않지만, data pump를 이용하여 이러한 database를 migration할 수 있다. 이러한 과정을 준비할 때, 파티션의 무결성과 관련하여 다음과 같은 잠재적인 문제를 고려해야 한다.

Oralce database는 range partution의 row를 분배할 때 parition 범위(bound)에 따른 parititioning key column을 비교하여 분배한다. 이러한 비교는 이진 정렬을 사용하므로, 디스크에 저장된 값의 byte 단위로 비교가 된다. 문자 컬럼의 경우 database character set에 따라 달라지므로 unicode로의 변환 시 변경 될 수 있다. partition 범위의 이진 표시가 변경 되면 당연히 parition이 다시 sort되어 partition간row의 분포가 크게 달라질 수 있다.

반드시 모든 range partition table을 분석해서 이러한 partition column과 관련된 이슈가 없는지 살펴보아야 convert후에도 예상대로 row가 분포된다.

 

6.5.4. Convertibility Issues: Recycle Bin 안의 object

DMU 가 drop된 table안의 문자 컬럼을 recycle bin에서 scan한다. 이러한 scan 결과는 database scan report에 포함된다. Normal application table과는 달리, recycle bin안에 있는 table은 convert 대상이 되지 않으므로, scan 전에 미리 수동으로 purge를 해 두는 것이 좋다. (만약 recycle bin에 convert해야 하는 data가 있다면 convert단계를 시작할 수 없다)

 

6.5.5. Convertibility Issues: PL/SQL Local Identifiers Greater Than 30 Bytes

DMU는 PL/SQL stored module(즉 stored procedure, function, package)의 이름을 convert하는 것을 지원하지 않지만, non-ASCII문자를 포함하여 PL/SQL source code 및 view 정의는 자동적으로 convert한다.

-       package안에 정의 된names of procedures, functions, type

-       variable names 과 type anme등 local identifier.

-       리터럴 문자

-       코멘트

Convert 단계에서, DMU는 CREATE OR REPLACEPACKAGE|PACKAGE BODY|PROCEDURE|FUNCTION|TYPE|TYPE BODY|VIEW 구문을 data dictionary에서 가져온다. Target character set으로 convert하고, UTF8 혹은 AL32UTF8로 database character set을 변경한다.

DMU는 convert되는 식별자의 길이에 대한 제약조건(일반적으로 30 bytes)을 체크하지 않는다. 만약 unicode로 convert되었을 때 허용된 길이보다 식별자가 길어지게 될 경우, pl/sql 모듈은 생성되지만 다음과 같은 에러와 함께 complie은 실패하게 된다.

“PLS-00114: identifier '<identifier>' too long". The status of the module will be "invalid".

Convert후 모든 pl/sql 저장 모듈의 상태를 확인해야 하며, 식별자가 너무 길어 모듈이 유효하지 않게 된 경우 수동으로 줄여주는 작업이 필요하다.

 

6.6.   Adapting Applications for Unicode Migration

6.6.1. Change to Applications

Unicode로 database를 migrate한다는 것은, 접속해있는 application에 영향이 있다는 것이다.

·         Application에서 새로운 character set에 맞춰 올바른 data를 읽고 쓸 수 있는가?

새로운 언어를 지원하려면 Unicode 데이터를 처리할 수 있도록 application을 조정해야 한다. Single-byte character set을 처리하도록 프로그래밍 된 application은 특히 전체 unicode 문자를 지원하기 위해 많은 수정이 필요할 수 있다. 아래 사항을 기본적으로 체크해야 한다.

ü  클렌징 작업을 거쳐서 table의 구조(컬럼의 길이나 타입)이 변경될 수 있다.

ü  문자의 최대 byte width 변경 등 database character set 의 특성이 바뀔 수 있다.  

ü  정렬 방식, 날짜 형식, number 포맷 방식이 바뀌거나, 그레고리안 력에 대한 지원 등을 포함한 새로운 언어의 특성이 있을 수 있다.

ü  Unicode에 속한 문자열의 이진 정렬 순서가 바뀔 수 있다.

·         복잡한 script를 사용하는 언어를 위해, application의 지원(?)이 필요할 수도 있다

아랍어 또는 인도어처럼, 표기와 인식에 있어서 많은 비용(판독을 위한 랜더링)을 필요로 하는 언어들이 있다. 이러한 문자들은 인접한 문자들과 서로 연결된 것처럼 조합되어 있고, 일부는 왼쪽에서 오른쪽으로 읽는 등의 특성이 있을 수 있다.

.

6.6.2. Changes to SQL and PL/SQL Code

SQL 및 PL/SQL 코드는 database 내부에서 실행되기 때문에, unicode로 이관 시 database의 character set을 따라 변경되어 인코딩 된다. (NLS_LANG가 변경되지 않는 한 character set이 유지되는 client-side application code와는 다르다)

대부분의 PL/SQL 구분과 표현식, 함수, 프로시저는 database character set과는 독립적으로 동작한다. 하지만 character set에 따라 다른 결과가 도출되는 경우의 수가 여전히 많기 때문에, 유니코드로 이관 후 아래와 같은 기능이 포함된 PL/SQL은 검토 후 필요에 따라 수정해야 한다.

·         CHR, ASCII, DUMP 와 같은 Functions depend한 이진 문자 코드.

·         character code byte 길이를 구하는 함수를 포함하는 경우: LENGTHB, VSIZE

·         byte offsets과 함꼐 동작하는 함수들을 포함하는 경우: INSTRB, SUBSTRB

·         Character set convert 함수: CONVERT

·         String-to-binary casting: UTL_RAW.CAST_TO_VARCHAR2, UTL_RAW.CAST_TO_RAW, UTL_I18N.STRING_TO_RAW, UTL_I18N.RAW_TO_CHAR

물론, UTL_FILE package를 사용하여, database character set의 external file에 문자 데이터를 저장할 수 있다. 이러한 file의 사용자는 새로 file 인코딩을 처리하기 위한 과정을 따로 숙지해야 할 수도 있다.

SQL과 PL.SQL의 표현식은, view의 정의 와 PL/SQL stored module, 사용자정의 data type method, 트리거, 체크 제약조건에서 검토해야하지만, dbms_rule_adm 같은 이벤트 룰 조건이나 row-level security(RLS/VPD) 규칙, fine-grained auditing policy(dbms_fga)그리고 sql 혹은 pl/sql의 표현식들이 참조하는 다른 auxiliary database object의 명세도 참고해야 한다.

 

6.7.   Repairing Database Character Set Metadata

만약 database가 pass-throgh구성으로 되어 있다면, client character set의 설정(NLS_LANG)과 database의 character set 설정이 동일해야 한다. 계속 강조했던 것처럼, 의도와는 다른 character set 데이터로 저장될 수 있기 때문이다. DMU를 이용해서 unicode로 변환할 때도, 사용자의 즉각적인 인식과 확인을 위해 database의 실제 character set을 정의해둘 것을 권고하고 있고, 업무상 혹은 기술적인 제약으로 즉시 마이그레이션이 불가능 할 경우, 적어도 character set이 일치하도록 일괄 설정 후 작업하는 것이 좋다.

DMU 1.2 에서는 CSREPAIR 스크립트를 이용해 database character set metadata를 repiar할 수 있다. CSREPAIR 스크립트는 DMU clinet에 접속(conjunction) 하고, DMU repository에 엑세스해서 동작하기 때문에, DMU가 database를 전체 scan해야 사용이 가능하다. database character set 선언(declaration)만 변경하고, 데이터 자체는 변환되지 않는다.

DMU가 설치된 경로의 admin 디렉토리에 CSREPAIR 스크립트가 있는데, 이 스크립트의 사용을 위한 몇가지 조건이 있다.

1.     Data의 실제 character set으로 Assumed Database Character Set 설정 후, DMU로 database를 full scan해야 한다(apply 하면 full scan한다). 만약 현재의 character set이 설정과 동일할 경우에는 아무것도 수행되지 않는데, DMU report에서 잘못된 이진 표현식이 발견이 되더라도 스크립트가 수행되지 않는다. 하지만 convert가 가능하거나, 길이 제한을 초과하는 data가 scan된 경우에는 계속 진행된다.

2.     database character set의 target character set은 US7ASCII의 이진 슈퍼셋으로 설정되어야 한다. (한글은 US7ASCII에서 이진코드 형태로 저장되므로 실질적으로 사용이 권장되는 character set이 아니다. 때문에 한글 입력 문제로 해당 스크립트 사용을 고려한다면 그냥 포기하는 것이 좋다.)

3.     Single-bytes character set은 Single-bytes character set끼리, multi-byte character set은 multi-byte character set끼리만 repair 되고, CLOB은 포함하지 않는다.

4.     만약 컬럼 레벨로 지정한 character set이 database의 character set과 동일하지 않은 경우, CSREPAIR 가 실행되지 않는다.

5.     CSREPAIR슬 수행하기 위해서는 반드시 sysdba 권한이 있어야 하고, 12c에서 PDB에 수행하기 위해서는 CDB와 PDB 모두에 sys, sysdba 권한이 둘 다 필요하다.

 

7. Using the DMU to Cleanse Data

일반적으로 scan후 DMU가 제시하는 대로, 데이터 혹은 컬럼 정의의 무엇이 문제가 되는 것인지, 뭐가 어떻게 깨진 것인지, 어떻게 수정을 해야 하는지에 대해 고민하게 된다. DMU를 이용하여 data를 클렌징(cleanse/정리) 하려고 할 때, cleansing editor를 이용하면 편리하게 table의 내용 및 오브젝트의 명세를 확인/변경 할 수 있다.

 

7.1.   Cleansing Data

7.1.1. Cleansing editor

Navigator에서 우클릭을 하거나, database scan report에서 cleansing editor 를 열 수 있다. (당연한 이야기지만, cleansing editor는 data dictionary의 table에서는 사용할 수 없다)

 

Cleansing Editor tab에서는 테이블의 contents를 확인할 수 있고, 우클릭으로 클렌징 작업을 설정해 진행할 수 있다.

[예시: edit data 를 이용해 data를 수정. length limit를 넘어서는 data는 노란색으로 표시된다]

 

Data 자체를 수정할 것인지, 컬럼 사이즈 혹은 타입을 수정할 것인지, 바로 수정작업을 적용할 것인지, 스케줄링을 할 것인지에 따라 원하는 메뉴를 클릭해 작업하면 된다.

 

여러 라인을 선택하여 작업할 수도 있고, 상단 툴바에서 원하는 이슈의 row들만 필터링 할 수도 있다.

 

관련 이슈에 따라 패널안의 셀의 색이 달라지는데, 예를 들어 length limit issue는 노란색, 잘못된 이진 표현식의 경우에는 진분홍색으로 셀의 배경색이 바뀐다. (default)

**[tool] → [preferences] 에서 원하는 컬러로 변경할 수 있다.

 

작업을 더 쉽게 하기 위해, Cleansing Editor tab에서는 필터 기능을 사용할 수 있다.

툴바에서 drop-down 리스트 중 조건 (all/ requiring coversion/Exceeding column limits/ exceed data type limit/ invalid binary representation) 을 선택하거나, 원하는 조건을 직접 sql로 기술하여 필터링할 수 있다.

 

DMU로 필터조건을 거는 것은 큰 테이블의 경우 브라우저의 속도를 떨어뜨리는 원인이 되기도 한다. 때문에 필터조건을 설정하기 전, 툴바의 [use scan log to filter data] 을 on 상태로 전환해야 빠른 필터링 속도를 보장받을 수 있다. 단, 마지막 scan 에서 더 이상 table에 변경이 없을 경우에 한한다.

 

SQL 의 where 조건을 가지고 필터링을 원한다면, 툴바의 [Customize Filtering Condition] 버튼을 눌러 입력할 수 있다.

(사실 salay 등의 범위를 조건(salary>100)으로 지정하는 것은 가능하지만 아래 그림의 history처럼특정 한글을 조건으로 주고 필터링 하는 것은 무척 어렵다. 한글 인자값을 제대로 인식하지 못하는 문제가 있는 것으로 보인다.)

 

 

 

7.1.2. Assumed Character Set 설정

client의 character set이 직접적으로 database로 입력되는 pass-through 구성에서는, 잘못된 이진 표현식과 관련된 이슈가 자주 발생한다. DMU 는 이러한 상황을 위해서 데이터의 실제 character set 과 client character set을 식별하고, 원본(source) character set으로 설정(assumed column character set)하여 데이터를 확인할 수 있게 한다.  

 

 

Client 의 character encoding 설정이 위와 같이 unicode로 설정된 상태에서 database에 insert를 하는 경우, 기존 KO16MSWIN949로 되어있는 database는 인식하지 못하는 이진 표현식으로 입력 된다. (오라클은 문자열의 이진 이미지를 그대로 저장하기 때문에 데이터가 깨진 것은 아니다)

 

만약 [assumed database character set]을 unicode로 설정하고 apply를 하면, 아래와 같이 unicode로 입력한 데이터(웰시코기)만이 보이는 것을 확인할 수 있는데, client 의 character set 설정대로 입력 된 것이다.

 

 

[assumed column character set]가 Unicode로의 convert 뿐만 아니라, Cleansing Editor등에서 data를 (사람이 읽고 수정이 용이하도록) display 하는데도 영향을 미친다는 뜻이다. [assumed column character set]는 정확히 어떤 character set으로 인코딩 되었는지 확인하는데도 유용하다. 전체적인 display를 위한 설정 말고도, (멀티플 컬럼의 경우에 한해) cleansing editor의 툴바에 있는 character set이 활성화되어 drop-down list로 assumed column character set을 선택할 수도 있다.

assumed column character set를 재설정/혹은 설정 해제하는 경우, scan result가 유효하지 않게 되므로 다시 한번 full scan 해야 한다는 것도 유념해야 한다.

 

8. Repository 삭제

Character set 변환 작업을 모두 종료한 후에는, DMU의 repository를 삭제한다.

9. Reference

 

참고 URL :

- https://docs.oracle.com/database/121/DUMAG/preface.htm#DUMAG309

- The Database Migration Assistant for Unicode (DMU) Tool (문서 ID 1272374.1)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

<끝>