(V8) ORACLE8의 CHARACTER SET의 변경에 대하여

Question

제품 : ORACLE SERVER
작성날짜 : 1997-08-26
Oracle8의 Character Set의 변경에 대하여
Oracle7에서 수행하던 DB의 DB character set(이하 dcs)을 변경하는 방법이
Oracle8에서는 공식적으로 지원하는 command로 변경되었습니다. O7에서는
props$ table의 값을 바꿈으로써 dcs를 바꾸던 방법의 결점은 다음과 같습니다.
1) 새로운 dcs가 올바른 dcs가 아닐 경우, DB를 다시 구동할 수 없슴.
2) 새로운 dcs가 이전 dcs의 super set이 아닐 경우, 새로운 dcs와의
character encoding 호환성 문제로 DB에 저장된 data를 올바른 의미
또는 올바른 값으로 사용할수 없슴.
3) dcs의 호환성 문제로 DB의 crash
물론 위의 문제는 dba의 능력에 따라 발생하지 않을 수도 있습니다. 이런 종류의
모든 문제를 해결하기 위해 O8에서는 dcs와 관련된 table들의 값을 변경하기
이전에 새로운 dcs가 올바른가를 확인하고, 새로운 dcs가 이전 dcs의 super set
인가를 확인하여 모든 것이 정상일 때에만 dcs의 값을 변경할 수 있게 하는 절차를
제공하게 되었습니다.
여기에서 super set이란 A라는 char set에 있는 모든 character가 B라는 char
set에서 똑같은 code 값으로 존재할 때 B는 A의 super set이라 합니다.
즉 한국 환경에서는 다음의 경우가 해당됩니다.
1) ko16ksc5601은 us7acsii의 super set이다.
2) utf8(unicode 2.0의 변형)은 us7ascii의 super set이다.
3) utf8은 ko16ksc5601의 super set이 될 수 없다.
- utf8의 code range는 ko16ksc5601의 super set이지만, code value는
같지 않으므로 dcs 변경 시의 super set은 아니다.
기존의 DB가 us7ascii이고 client 역시 us7ascii를 사용하여 한글 데이타를
DB에 저장시킨 경우 대부분 ksc5601 encoding scheme을 사용하여 한글을
입력시킵니다. 이 때 DB에 입력된 "가"는 0xb0a1으로 저장되는데, 이 DB를
ko16ksc5601으로 변경시키면 ksc5601에서 역시 "가"의 code 값은 0xb0a1이므로
변경된 DB는 정상적인 동작을 하게 된다.
그러나, utf8 encoding scheme을 이용하여 "가"를 입력시키면 DB에는 0xeab080
으로 입력되므로 DB를 ko16ksc5601으로 변경시킨 경우 client에서 이 값을
access하면 다음의 경우가 발생합니다.
1) utf8을 지원하는 기계에서 ko16ksc5601을 이용하는 경우
-> 이전에 입력된 "가"를 볼수 있음
2) 1)을 제외한 경우 정상적으로 data의 의미를 해석할수 없음.
즉 이전 DB에 data의 입력 방식이 ksc5601인 경우 DB를 ko16ksc5601으로
변경하면 아무런 문제 없음. 그리고 이전 DB에 utf8의 입력 방식을 사용한 경우,
DB를 utf8로 변경하면 문제없음. 즉 한국 환경에서는 us7ascii에서
ko16ksc5601으로 변경하는 경우와 us7ascii에서 utf8으로 변경하는 두가지
경우 밖에 존재하지 않는다.
1) us7ascii ----> ko16ksc5601
2) us7ascii ----> utf8
또한 O8에서는 DB의 database character set(dcs) 이외에 national character
set(ncs) 이라는 secondary character set을 지원합니다. 이것의 특징은
문자의 길이가 고정되어 있다는 것입니다. 즉, table 생성 시 특정 column을
nchar 혹은 nvarchar2로 선언하여 입력 시 N'a가'라는 data가 입력되면 이 값은
내부 처리 시, 저장 시, 외부 출력 시 0xa3e1 0xb0a1이라는 문자 당 고정 길이를
갖는 값으로 변경된다. 물론 이런 형태의 지원은 성능 향상을 위한 것이다.
이런 nchar, nvarchar2의 encoding scheme 역시 data base가 생성될 때
지정되고, DB의 dcs과 같은 방법으로 변경될 수 있다. 한국 환경에서 사용할 수
있는 ncs는 ko16ksc5601fixed와 ko16dbcsfixed라는 두 가지가 있는데 이것들은
Oracle 8.0.4부터 지원된다. 그런데 문제는 national char set 변경 시 역시
super set으로 밖에 변경할 수 없다는 제약이 있는데, 일반적인 설치 시 DB의
dcs와 같은 값으로 ncs가 지정된다.
1) ko16ksc5601fixed는 us7ascii의 super set이 아니다.
2) ko16ksc5601fixed는 ko16ksc5601의 super set이 아니다.
3) ko16ksc5601fixed는 utf8의 super set이 아니다.
그러므로 ncs를 ko16ksc5601fixed 혹은 ko16dbcsfixed로 지정하고자 하는
경우에는 DB의 생성 시 지정할 수 밖에 없다. 즉 "create database ..."에
반드시 지정되어야 한다.
또 한가지 고려 사항은 dcs와 ncs의 관계인데, 서로 다른 dcs를 사용하는
server/server, server/client의 경우 code conversion의 주체는 dcs이다.
즉 ncs는 dcs의 값으로 변경되어 상대방의 dcs로 변경되고, 이것은 다시 ncs로
변경되어 DB에 저장된다. 즉 ncs의 code 범위가 dcs보다 크다면 dcs에 포함되지
않는 ncs의 값은 default replacement character인 ?로 대치되어 전달된다는
것이다. dcs와 ncs의 관계는 code range가 초점이 된다.
1) us7ascii(dcs)에 ko16ksc5601fixed(ncs)를 사용할 수 없다.
2) utf8(dcs)에 ko16ksc5601fixed(ncs)를 사용하면 char를 nchar로 변경 시
data를 loss을 가져올 수 있다.
3) ko16ksc5601(dcs)에 ko16ksc5601fixed(ncs)의 사용은 문제 없습.
4) utf8fixed 형태의 char set은 현재까지 지원되지 않음.
Oracle8의 Character Set의 변경 시 지원되는 command
기존 DB의 char set이 us7ascii인 경우 DB char set의 변경은 ko16ksc5601
혹은 utf8으로 밖에 변경시킬 수 없다.
svrmgr>
svrmgr> shutdown
svrmgr> startup mount exclusive
svrmgr> alter system enable restricted session;
svrmgr> alter database open;
svrmgr> alter database character set KO16KSC5601;
or
svrmgr> alter database character set UTF8;
svrmgr> shutdown
svrmgr> startup
svrmgr>

Answer 1