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



1. DMU

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

 

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

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

 

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

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이 다른 databasemigration하는 경우에 아래의 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에서 unicodemigration할 때, character 값이 확장되면서 더 많은 bytes를 요구하게 된다. 이것은 database에 더 많은 공간을 요구하게 되는데, 예를 들어 CHAR VARCHAR2 column의 경우 Unicodemigrate시 필요한 컬럼 길이(width)가 늘어나게 되므로 데이터가 잘릴 위험이 있다. 이럴 경우에는 길이 제한을 조정하거나, 이관 전에 CLOB data type으로 변경해야 한다.

 

l  Invalid binary storage 표현식

User data에 있을만한 일반적인 문제는, column안에 있는 data 실제로는 character set에 없는 경우이다. 다른 character set 에 존재하는 문자를 사용했거나, 이진(binary, 예를 들어 워드프로세서 포멧의 문서 또는 사용자가 지정한 방법으로 암호화된 텍스트 등) 혹은 단일 column에 다중 character set이 있을 수 있다.

pass-through 구성*에서는, clinetcharacter 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 설정을 하지 않고 DBcharacter set을 따르도록 하는 구성을 말한다(NLS_LANG을 지정하지 않음)

 

l  Partitioning (파티셔닝)

Range Partitionpartitioning key 값과 partition boundary 값을 비교하여 row들을 partition에 분배한다. 이러한 방식은 character 값의 binary storage representation*을 확인하는데, key값과 boundary값의 binary storage representationUnicode로 변환될 때 요구사항 대로 변경되지 못할 수도 있으며, 다음 세가지 문제점을 야기시킨다.

1.     주어진 partitioning key가 가진 partition boundary값과는 다르게 정렬(sort)되는 문제.

2.     Partitionboundary값의 순서와 동일한 순서로, 내부적 넘버링이 되는 경우. 만약 Unicodemigrate되는 동안 boundary 값이 sort 순서를 변경하게 된다면 내부적 넘버링이 invalid 하게 됨.

3.     드문 경우이지만, 일부 multibyte 동아시아 character set*에서는 서로 다른 문자가 동일한 Unicode 문자에 mapping되어 두개의 partition boundary가 같아지는 경우가 있음.

만약 partition boundarynon-ASCII 문자를 사용한다면 Partition table을 수정된 DDL을 사용해 재생성해야 할 수도 있다. Partition key값에 영향이 생겨 row가 이동되어야 하는 상황이 오면 row movement 가 반드시 enable되어 있어야 한다.

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

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

 

l  Maximum index key size

Indexkey size key column의 최대 길이에 따라 달라진다. 지원되는 최대 key size database block size에 대해 제한되고, Unicodeconvert 후에 확장된 column 데이터를 target쪽으로 집어넣으려면, column의 길이를 확장하거나 column length semanticsBYTE 에서 CHAR로 변경해야 한다.

이를 해결하는 방법으로는 아래와 같다:

·         Block size를 늘림

·         Indexdrop

·         composite index의 특정 column을 삭제

 

l  Unique keyprimary key

사전에 제약조건을 충족하도록 key을 변환하더라도, Unicode로 변환 후 unique 조건이나 PK조건을 위반하게 되는 경우가 2가지 있다.

·         일부 character set의 일부 문자들이 동일한 Unicode 값으로 mapping되는 경우에, 2개의 다른 TEXT 값이 AL32UTF8로 변경 후 동일한 값이 됨.
(
예를 들어, 2개의 JA16SJI code0xED40 0xFA5CU+7E8A로 동일하게mapping)

·         최대 column길이를 초과한, 끝부분만 다른 2개의 text값이 convert시의 truncate로 인해 동일하게 보이게 되는 경우.

일반적으로, key값을 매뉴얼하게 수정하여 이 문제를 해결한다.

 

l  파생 또는 암호화된 data

Application에서 저장되어있는 정보는 databinary storage representation에 따라 drive된다. 예를 들어 text 길이는 숫자형 column에 있는 text와는 다르게 저장된다. Text가 확장되면 이러한 column들은 자동으로 갱신되지 않는다. 또는, application에서 문자 값의 checksum이나 암호화된 형식을 계산하여 저장할 수도 있다. database character setbinary storage representation를 기반으로 하는 경우, 이렇게 checksum 또는 암호화된 textcharacter set 변환에 의해 유효하지 않게 될 수도 있다.

이러한 식으로 파생된 값은 migration후 반드시 재동기화(resynchronize) 과정을 거쳐야 한다. 암호화된 text의 경우에는 일반적으로 변환 직전에 복호화를 진행하고, 변환 후 다시 암호화를 진행한다. 보안상의 이유로 복호화된 시간을 최소화하고 서버의 보안을 강화해야 하는 작업이 필요하게 될 수 있다. (Oracle TDE를 사용 하는 경우 수동으로 복호화-암호화 하는 과정이 불필요 하다)

 

l  Binary Data TypesCharacter Data 적재

ApplicationRAW, LONG RAW, BLOB등의 Binary type 문자 데이터를 적재할 수 있다. Application은 이러한 데이터들을 해석(interpret)하고 처리하기 위해 database character set을 사용한다. 만약 database character setmigrate 되었을 때, 새로운 문자셋에 매치되는 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규칙을 설정했을 때의 의도와 다른 내용이 로깅될 수 있다. 따라서 tableconvert하기 전에 trigger diable해야 하는데, DMU에서는 이런 부분을 자동적으로 관리할 수 있다.

 

    3.3.    Read-only & Inaccessible object

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

 

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

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

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

 

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

 

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

 

    3.4.    Downtime

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

 

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

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

 

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


 

4. Using DMU

이 문서에서 DMUtest하기 위해 설치한 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 release10.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 기반이어야 한다. 예를 들어 databaseEBCDIC-based platfromIBM z/OS Fujitsu BS2000support되지 않는다.

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

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

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

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

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

 

추가적으로 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 archivedatabase 안에 없어야 한다.

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

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

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

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

 

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

 

   4.1.2. Java runtime 요구사항

DMUjava 기반의 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 fileunzip한 위치)

$ 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 fileunzip, 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 panneldatabase에서 우클릭.

 

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 : 접속하려는 instanceservice name

 

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

 

   4.4.   Install Migation Repository

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

 



à [Next]

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


[export migration profile wizard 실행]

 


Migratetarget databasecharacter set을 설정한다. (recommandAL32UTF8)

à [Next]


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

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

 

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

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]




작업에 필요한 공간은 전체 datascan을 위해 설정한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]

 

 

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

 

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

"Collect rowids only according to 'Rowids to Collect' table property" DMUtable의 속성인 'Rowids to Collect' 값을 각 tableinitial 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" tableconversion method가 할당(assign)되지 않았으므로, 최초 scan의 경우에는 첫번째 옵션과 차이점이 없다.

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

 

Scan할 대상을 Databaseapplication 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개의 rowscan된 것이 확인된다.

 

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

 

 

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

 

 

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

 

좌측 그림처럼 navigator에서 problem data report를 누르면 wizard가 실행되어, column에 대한 report를 확인 할 수 있다.

 

dog tablevarchar2(10)name이라는 column을 가지고 있다.

 

 

 

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

 

 

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

 

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

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

-       Standby database인 경우

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

-       database convert되는 primary key-basedOIDs(object identifiers)가 있는 경우

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

-       Conversion performance 를 향상시키기 위하여 Database 혹은 tablespaceFORCE LOGGING modeTurning off 해야 할 때. (대신 media recoveryabillity가 저하되는 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 rowcounting한다.

 

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

-       Need conversion : convert가 필요함

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

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

-       Exceed data type limit : data typelimit으로 인해 잘리는 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 planSQL문 형태로 보여준다.

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

 

 

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

 

 

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

 

 

 

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

 

5.2.    Data conversion

이제 실제로 dataconvert 해서 Unicode character set으로 변경한다.

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

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

 

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

1.      Restricted modedatabase를 변경

2.      Job queue processedisable

3.      Index drop 혹은 disable.

4.      Triggers와 제약조건을 disable.

5.      User tabledata 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.

 

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

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


 

5.3.    Object properties

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

l  [General]

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

 

current database character set : Database에 적재된 data type(varchar2, char, long, clob)을 해석(interpret) 하기 위해 현재 정의된 databasecharacter 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 혹은 AL32UTF8target character set을 지정한다. 이 값을 변경하기 위해서는 migration repository를 새로 install해야 한다.

 

l  [Scanning]

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

 

Number of Scanning Processes

databasescan하는데 사용되는 process의 개수. scan processDMUparallel thread와 이 thread가 만드는 serverdatabase session 로 구성되는데, default 값은 database serverCPU 수에 따라 달라진다. 

 

Scan Buffer Size

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

 

Scan Status

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

-       In progress : 현재 scan 진행 중.

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

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

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

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

 

Tables to Convert

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

 

Rows to Convert

convert가 필요한 tableConvert 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는 자동적으로 각각의 scantable에 대해 한가지 이상의 convert method를 제시(assign)한다. 만약 작업자가 생각하기에 더 좋은 방법이 있다면, DMU의 추천을 무시하고 변경할 수 있다.

 

Degree of Parallelism

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

 

Number of Converting Processes

**4.5Data scaning 참조.

 

Enable Row Movement for Partitioned Tables

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

 

Consider CTAS with Row Movement Disabled

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

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

 

Consider CTAS with User-named LOB Segments

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

 

Handling of Read-Only Materialized Views

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

-       Refresh Automatically After Conversion

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

-       Generate SQL Script

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

-       Do Nothing

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

 

Handling of Updatable MViews

Master tableconvert한 후 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, 사용자는 실패한 구문에 대해 retryscript로 떨구는 것, 혹은 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

dropdomain index에 관련된 항목이다.

-       Recreate Automatically After Conversion

Convert 후 자동으로 dropdomain index recreate 하는 옵션이다. (default)

-       Generate SQL Script

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

-       Do Nothing

Dropdomain 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문을 skipconvert를 계속 진행한다.

-       Export Failing SQL to Script and Continue

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

 

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 scriptexport 한다.

.

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 생성부터 적용된다.

 

이제 databaseunicodeconvert할 수 있다.

 

 

[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, scanconvert 단계에서 제외할 수 있다.

 

single columnmultiple character set인 경우.

 

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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

6.2.   Handling Non-Accessible Data

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

 

6.2.1. Read-Only Tables 고려사항

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

 

6.2.2. Read-Only Tablespaces 고려사항

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

 

만약 partition, CLOB, varray, IOT overflow segments 를 포함한 tableread-only talespacesegmentconvert하는 경우에는 DMU가 정상적으로 convert할 수 없다. DMUconvert와 관련된 issuemigration status tabreport 하고, 문제가 해결되기 전까지는 coversion 단계로 넘어가지 않는다.

 

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

 

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

 

convert data가 있는 모든 read-only tablespace에 대해 충분한 disk storage 공간을 (임시적으로든 영구적으로든) 준비할 수 있다면, storagetablespacecopy하고, 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 databaseDatabase 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 fileoffline으로 변경할 경우, 그 안의 data에 대한 변경이나 읽고 쓰기가 불가능해진다. Offline tablespacedata file에 대한 다양한 administrative operations(예를 들자면 rename이나 다른 storage로의 move)이 필요하다.

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

 

6.2.4.  Working with External Tables

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

 

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

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

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

 

ORACLE_DATAPUMP filecharacter set export 될 때 file자체에 저장된다.

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

 

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

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

 

6.2.5. Cleansing External Tables

DMUexternal tableconvert하지 않더라도, migration processscan단계에 포함이 된다. 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가 발견된다면, 해당 컬럼의 길이나 타입을 변경할 수 있다. DMUexternal table에 대한 cleansing 작업을 지원하지 않으므로, SQL*PLUS/SQL Developer등의 다른 툴을 이용하여 작업해야 한다. VARCHAR2 컬럼은 CLOB으로 변경할 경우 4000 bytes 이상 지원이 된다. CLOB으로 column data type을 변경하기 위해서는 반드시 external tablere-create해야 하는데, Metadata만 변경이 되므로 빠르게 작업할 수 있지만 grants등의 종속적인 object는 다시 생성(적용)하는 번거로움이 있다.

 

6.2.7. ORACLE_LOADER FileCorrecting Character Set Declaration

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

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

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

 

6.2.8. ORACLE_DATAPUMP FileCorrecting Character Set Declaration

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

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

 

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

 

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

-       Data Pump filecharacter set 설정과 동일한 auxiliary database 를 생성

-       (pass-though 구성이라면) Dump fileImport

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

-       (Unicodemigrate) file export하고 main database external table 로 이용

참고로 Data pump filecharacter set을 알아야 하는 경우가 있다면 그냥dump filevi 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 BLOBexternal table이 사용하는 이진 데이터 타입으로 재정의(redefine)해야 한다.

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

 

6.2.11. Performance Considerations for ORACLE_LOADER Files

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

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

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

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

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

 

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

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

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

-       Single-bytes character setUTF8 혹은 AL32UTF8convert하기로 했다면, query성능 극대화가 중요할 경우 field length positionbytescharacter로 표현한다.


 

6.3.   Migrating Data Dictionary Contents

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

DMUdata dictionary에 있다고 인식하는 schemaNavigator panelData Dictionary node에 표시된다.

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

DMUdictionary 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에 포함된 dataconvert를 해야 하는 경우에는 노란 삼각형 경고 아이콘으로 표시되고, convert 단계로 넘어가지 않는다)

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

 

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

 

DMU convert하는 몇몇 columnissue가 없는 경우 [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

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

 

Cleansing Data Length Issues

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

 

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

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

Objectrename한 후에는 PL/SQL이나 Java codeapplicationcode가 참조하고 있는 이름까지 수정해야 한다.

 

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

 

Cleansing Invalid Binary Representation Issues

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

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

 

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

 

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

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

 

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에 저장된 metadatatype mapping하는 것이다. DMU interface에 제공된 Data dictionary tabledata dictionary view (dba_tables, dba_tab_comlumns, dba_rules, dba_scheduler_jobs )로 확인해야 한다. .

 

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

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

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

-       MOSOracle Technology Network Web siteglobalization forum에 질문을 올린다.

 

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

 

6.3.3. Converting Data Dictionary Tables

DMUdata dictionaryconvert할 수 있다.

-       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의 모든 *stopliststopword

 

SYS, SYSTEM, CTXSYS schema에 포함된 50여개의column들과 다양한 object들의 comment.

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

 

multiple tablePL/SQL source code view source text가 보관되는데, DMUsource 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는 상기 나열된 tablecolumn convert 이슈를 report하지 않는다.  

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

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

 

6.3.4. Scan을 건너뛰는 Data Dictionary Tables

DMU는 아래 tablescan 하지 않는다.

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

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

·         SYSTEM schemaDMU repository table.

·         CSMIG schema에 있는 CSSCAN repository tables.

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

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

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

DMUCSSCAN 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$sysstatv$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 contentspurge하기 전에 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 columnmultiple character set 작업 방법:

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

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

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

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

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

Convert에서 제외할 multiple character setdata를 포함한 cloumn을 표시

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

databaseconvert.

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)

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

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

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

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

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

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

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

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

 

6.5.2. Convertibility Issues: 인덱스 크기

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

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

·         databasecharacter setcolumn 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를 시도하기 전에, 반드시 varchar2char 로 선언된 모든 index의 명세를 확인해야 하여 length 이슈를 피해갈 수 있도록 조치해야 한다.

 

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

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

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

반드시 모든 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안에 있는 tableconvert 대상이 되지 않으므로, scan 전에 미리 수동으로 purge를 해 두는 것이 좋다. (만약 recycle binconvert해야 하는 data가 있다면 convert단계를 시작할 수 없다)

 

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

DMUPL/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 anmelocal identifier.

-       리터럴 문자

-       코멘트

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

DMUconvert되는 식별자의 길이에 대한 제약조건(일반적으로 30 bytes)을 체크하지 않는다. 만약 unicodeconvert되었을 때 허용된 길이보다 식별자가 길어지게 될 경우, 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

Unicodedatabasemigrate한다는 것은, 접속해있는 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 setexternal file에 문자 데이터를 저장할 수 있다. 이러한 file의 사용자는 새로 file 인코딩을 처리하기 위한 과정을 따로 숙지해야 할 수도 있다.

SQLPL.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

만약 databasepass-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 metadatarepiar할 수 있다. CSREPAIR 스크립트는 DMU clinet에 접속(conjunction) 하고, DMU repository에 엑세스해서 동작하기 때문에, DMUdatabase를 전체 scan해야 사용이 가능하다. database character set 선언(declaration)만 변경하고, 데이터 자체는 변환되지 않는다.

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

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

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

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

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

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

 

7. Using the DMU to Cleanse Data

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

 

7.1.   Cleansing Data

7.1.1. Cleansing editor

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

 

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 설정

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

 

 

Client character encoding 설정이 위와 같이 unicode로 설정된 상태에서 databaseinsert를 하는 경우, 기존 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 listassumed column character set을 선택할 수도 있다.

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

 

8. Repository 삭제

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



9. Reference

 

참고 URL :

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

<>


이 글을 공유하기

댓글(0)

Designed by JB FACTORY