Oracle과 한글 그리고 UTF-8
이제부터 오라클의 Character Set을 변경하는 방법에 대해서 살펴보도록 하겠다. 다만 여기서 설명하는 방법으로 Character Set을 변경했을 경우 100% 데이터를 보장하지 않는다.
오라클 DB Character Set 변경 전에…
오
라클 DB Character Set을 변경하고자 한다면 먼저 혼자 판단하기 전에 오라클 DB Character Set변경에 총
책임을 질 수 있는 책임자, Application 개발자 및 운용자와 심사숙고하고 변경하기 전에 꼭!꼭!꼭! Full
Backup을 받고 진행해야 한다.
라클 DB Character Set을 변경하고자 한다면 먼저 혼자 판단하기 전에 오라클 DB Character Set변경에 총
책임을 질 수 있는 책임자, Application 개발자 및 운용자와 심사숙고하고 변경하기 전에 꼭!꼭!꼭! Full
Backup을 받고 진행해야 한다.
오라클 DB Character Set 변경 종류
오라클 DB에 대한 Character Set을 변경한다는 것은 다음의 두 가지를 의미한다. 변경하는 방식이 무엇인지 정확하게 파악하고 작업을 시작해야 한다.
Case 1> Character Set Dictionary 정보 변경 + 데이터 불변
Character Set 변경시도 시점을 기준으로, DB에 저장되어 있는 데이터 자체는 전혀 변경하지 않은 채, Dictionary에 있는 Character Set 정보만을 변경하는 작업이다.
일
반적으로 Character Set에 맞게 데이터를 잘 저장시켜 온 DB에는 사용할 수 없는 방법이다. 예를 들어
KO16MSWIN949 Character Set을 가진 DB에 한글을 Windows-949의 코드페이지에 맞게 잘 저장하고
사용해왔다면 이 DB의 Dictionary 정보만을 UTF8로 바꿔서는 전혀 엉뚱한 결과를 얻게 되는 것이다. 주로 다음과 같은
상황에서 사용할 수 있다.
반적으로 Character Set에 맞게 데이터를 잘 저장시켜 온 DB에는 사용할 수 없는 방법이다. 예를 들어
KO16MSWIN949 Character Set을 가진 DB에 한글을 Windows-949의 코드페이지에 맞게 잘 저장하고
사용해왔다면 이 DB의 Dictionary 정보만을 UTF8로 바꿔서는 전혀 엉뚱한 결과를 얻게 되는 것이다. 주로 다음과 같은
상황에서 사용할 수 있다.
–
비어있는(Empty) DB Instance : DBCA(Database Configuration Assistants)를 이용해
DB Instance를 생성할 때, Character Set을 잘못 선택했다면 도중에 작업을 중단하는 방법도 있지만(사실
중단하기를 권장한다!), 생성을 마친 후 Character Set 정보를 변환함으로써 문제를 해결할 수 있는 경우가 있다.
KO16MSWIN949로 생성해야 할 데이터베이스를 KO16KSC5601로 설정하여 생성했다면, 생성을 마친 후 간단한 절차를
거쳐 KO16MSWIN949로 변경할 수 있는 것이다.
비어있는(Empty) DB Instance : DBCA(Database Configuration Assistants)를 이용해
DB Instance를 생성할 때, Character Set을 잘못 선택했다면 도중에 작업을 중단하는 방법도 있지만(사실
중단하기를 권장한다!), 생성을 마친 후 Character Set 정보를 변환함으로써 문제를 해결할 수 있는 경우가 있다.
KO16MSWIN949로 생성해야 할 데이터베이스를 KO16KSC5601로 설정하여 생성했다면, 생성을 마친 후 간단한 절차를
거쳐 KO16MSWIN949로 변경할 수 있는 것이다.
–
Character Set과는 전혀 엉뚱하고도 다른 Character Set으로 인코딩된 정보를 강제 저장해온 Instance :
이런 경우가 상당히 많은데, DB Character Set은 US7ASCII밖에 없는 것으로 생각을 했던 것일까?
US7ASCII은 그 이름만 보아도 절대 한글을 저장할 수 없을 것 같은 Character Set인데, 여기에 한글 데이터를
버젓이 저장해온 시스템들이 상당히 많다. Character Set은 US7ASCII이지만, 실제로는 완성형+한글 원도우즈 코드
페이지(KO16MSWIN949)의 데이터를 저장해 온 경우, 데이터는 현재 상태에서 가공하지 않은 채, Dictionary에 있는
Character Set 정보만을 강제로 KO16MSWIN949로 변환하는 방식으로 문제를 해결할 수 있다.
Character Set과는 전혀 엉뚱하고도 다른 Character Set으로 인코딩된 정보를 강제 저장해온 Instance :
이런 경우가 상당히 많은데, DB Character Set은 US7ASCII밖에 없는 것으로 생각을 했던 것일까?
US7ASCII은 그 이름만 보아도 절대 한글을 저장할 수 없을 것 같은 Character Set인데, 여기에 한글 데이터를
버젓이 저장해온 시스템들이 상당히 많다. Character Set은 US7ASCII이지만, 실제로는 완성형+한글 원도우즈 코드
페이지(KO16MSWIN949)의 데이터를 저장해 온 경우, 데이터는 현재 상태에서 가공하지 않은 채, Dictionary에 있는
Character Set 정보만을 강제로 KO16MSWIN949로 변환하는 방식으로 문제를 해결할 수 있다.
“ALTER DATABASE CHARACTER SET” 명령어가 이에 해당한다.
Case 2> Character Set Dictionary 정보 변경 + 데이터 변경
Character
Set의 변경과 함께 DB가 가지고 있는 데이터의 인코딩까지도 변경하는 마이그레이션 작업을 포함하는 경우로, Case
1>에 비해 상당히 긴 시간이 소요되는 방대한 작업이며, 그에 따라 위험성도 크다. 기존 DB의 백업은 물론 당연하며,
새로운 Character Set을 가진 새 DB Instance를 생성하여 그곳에 현재 DB로부터 데이터를 마이그레이션을 하는
것이 가장 안전하다. 이 경우 보통 exp/imp를 사용하여 해결할 수 있다. 현존하는 DB의 데이터를 직접 변경하려고 할 경우를
대비해 오라클에서는 CSSCAN이라는 툴을 제공하고 있다.
Set의 변경과 함께 DB가 가지고 있는 데이터의 인코딩까지도 변경하는 마이그레이션 작업을 포함하는 경우로, Case
1>에 비해 상당히 긴 시간이 소요되는 방대한 작업이며, 그에 따라 위험성도 크다. 기존 DB의 백업은 물론 당연하며,
새로운 Character Set을 가진 새 DB Instance를 생성하여 그곳에 현재 DB로부터 데이터를 마이그레이션을 하는
것이 가장 안전하다. 이 경우 보통 exp/imp를 사용하여 해결할 수 있다. 현존하는 DB의 데이터를 직접 변경하려고 할 경우를
대비해 오라클에서는 CSSCAN이라는 툴을 제공하고 있다.
ALTER DATABASE 명령을 이용한 Dictionary 변경
Case
1>에 해당하는 것으로 데이터에 대한 어떠한 검토나 수정은 없이 Dictionary의 Character Set 정보만을
교체하는 작업이다. KO16KSC5601을 KO16MSWIN949로 변경할 때 유용하다. 그리고 한글만을 저장해 온
US7ASCII DB 또한 이 방식으로 KO16MSWIN949로 변경할 수 있다.
1>에 해당하는 것으로 데이터에 대한 어떠한 검토나 수정은 없이 Dictionary의 Character Set 정보만을
교체하는 작업이다. KO16KSC5601을 KO16MSWIN949로 변경할 때 유용하다. 그리고 한글만을 저장해 온
US7ASCII DB 또한 이 방식으로 KO16MSWIN949로 변경할 수 있다.
SQL > Shutdown Immediate;
SQL > Startup Mount;
SQL > Alter System Enable Restricted Session;
SQL > Alter System Set Job_Queue_Processes=0;
SQL > Alter System Set Aq_Tm_Processes=0;
SQL > Alter Database Open;
SQL > Alter Database Character Set KO16MSWIN949;
SQL > Shutdown Immediate;
이 방식을 사용하려면 반드시 새로운 Character Set은 기존 Character Set의 SupterSet이어야 한다. 그렇지 않으면 기존 데이터의 안전이 보장될 수 없기 때문이다.
기존 Character Set 새로운 Character Set 변경 가능 여부
US7ASCII KO16KSC5601/KO16MSWIN949/UTF8/AL32UTF8 가능
KO16KSC5601 KO16MSWIN949 가능
KO16MSWIN949 UTF8 불가능
UTF8 AL32UTF8 가능
안녕하세요, 내용을 참고하여 캐릭터셋 변경 작업에 큰도움을 받았습니다.
글 작성기간이 오래되었으나
별도로 궁금한점이 있어 문의 댓글을 남깁니다.
기존 DB의 캐릭터셋이 US7ASCII인 상태에서 데이터를 full로 백업 받았습니다. (user export)
이 상태에서 KO16MSWIN949의 캐릭터셋으로 구성된 DB에 import를 하였을 때
당연히 깨진것으로 데이터가 나오는데 이 경우 정상적으로 한글로 데이터를 변경할 수 있는 방법이 존재할까요?
글의 내용을 참고하자면 case2 의 방법으로 위 방법이 해당 되는지 궁금합니다.
안녕하세요. 시간이 좀 지나서 보게되었네요.
우선 말씀하신 내용은 오라클 레퍼런스를 찾아보니 imp/exp를 이용하면 자동으로 캐릭터셋이 변경된다고 나옵니다.
https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch11charsetmig.htm#CEGCHGIJ
그런데 여기서 유의할 점은 서로 다른 케릿터셋에서 문자열 차지하는 길이가 다르므로, 데이터를 임포트하기 전에 컬럼크기를 늘려 놓으라고 되어 있습니다. 예컨데 기존에 US7ASCII를 쓰고 있다면 영문 1byte, 한글은 2byte를 사용하는데, 새로운 DB가 AL32UTF8를 사용한다면 영문 2byte, 한글 3byte를 사용합니다. 그러니 새로운 DB에서 컬럼크기를 미리 늘려놓아야 한다고 합니다. 그리고 데이터 임포트 후에 새로운 DB에서 한글이 깨지는 경우에는 클라이언트의 NLS_LANGUAGE를 새로운DB 케릭터셋으로 변경하고 다시 조회해 보시기 바랍니다. 보통 구DB에 맞도록 클라이언트 NLS_LANGUAGE 셋이 설정되어 구DB에서는 한글이 정상적으로 보여도, 새로운 DB에서는 깨져서 보일 수가 있기 때문입니다.