한글을 지원하는 캐릭터셋 비교 테이블 | ||||
KO16KSC5601 |
KO16MSWIN949 |
UTF8 |
AL32UTF8 | |
한글 지원상태 |
한글 2350자 | KO16KSC5601 + 확장 8822자(총 11172자) |
한글 11172자 |
한글 11172자 |
캐릭터셋/인코딩 버전 |
한글완성형 |
완성형코드포함 확장된 8822자는 MS Windows Codepage 949에 따라 배열 |
8.1.6 이전 : Unicode 2.1 8.1.7 이후: Unicode 3.0 |
9i Rel1: Unicode 3.0 9i Rel2 : Unicode 3.1 10g Rel1 : Unicode 3.2 1/0g Rel2 : Unicode 4.0 |
한글바이트 |
2바이트 |
2바이트 |
3바이트 |
3바이트 |
지원버전 |
7.x |
8.0.6 이상 |
8.0 이후 |
9i Release 1 이상 |
Database Characterset으로 설정 가능 여부 |
가능 |
가능 |
가능 |
가능 |
National Characterset으로 설정 가능 여부 |
불가능 |
불가능 |
가능 |
불가능 |
한글정렬 |
단순 바이너리 정렬로 구현 가능 |
KOREAN_M 또는 UNICODE_BINARY 등 특수한 옵션 필요 (한글 정렬에 관한 설명 참조) |
한글 정렬은 단순 바이너리 정렬로 가능. 한자 정렬은 KOREAN_M 옵션 필요 |
|
장점 |
- 특별한 장점이 없음. 완성형 코드만을 입출력하는 것이 확실할 경우에는 높은 성능 |
- 2바이트로 모든 한글 저장/입출력 가능. 공간의 소모가 적으면서도 모든 한글을 입출력할 수 있다 |
- 현대 한글 11172자가 정확한 순서로 배열되어 정렬이 효과적 - 다른 언어들(중국어 태국어 등) 또한 같은 데이타베이스 인스턴스에 저장되어야 할 경우 UTF8 등의 유니코드 캐릭터셋 이외에 다른 대안이 있을 수 없음 |
- 한글 지원은 UTF8과 동일 |
단점 |
- 한글을 2350자밖에 지원하지 못한다는 치명적인 단점이 있어 미래에는 사용이 자제되어야 할 캐릭터셋 |
- 완성형과 호환을 하려다보니, 글자배열순서와 정렬 순서가 다르게 됨. 단순한 "ORDER BY" 절로는 제대로 한글 정렬을 할 수 없음 |
한글 한 캐릭터가 3바이트를 소모하게 되어 공간의 소모가 크고, 유니코드 인코딩/디코딩에 성능을 소모해야 한다 |
출처 : otn.oracle.com/kr (오라클과 NLS의 찰떡궁합 들여다보기, 류정우)
'IT > Oracle' 카테고리의 다른 글
Oracle 성능분석방법론 (0) | 2009.02.02 |
---|---|
Data pump (0) | 2008.12.24 |
DB Link (0) | 2008.12.22 |
Dataguard 구성 방법 (0) | 2008.12.10 |
Oracle10g RAC Clusters 기동-정지관련 커맨드 (srvctl) (0) | 2008.12.10 |