Database에서 코드페이지는 지원되는 문자 데이터의 언어를 의미한다.  한국 고객들이 흔히 사용하는 코드페이지는 970, 1363, 1208 등이다. 970은 완성형 한글로 KSC5601의 2,350자를 지원하며,  1363은 MS949를 지원하는 확장형 한글로 11,172글자 수를 지원한다.  그리고 1363은 Windows 환경뿐 아니라,  Linux, Unix환경에도 공통으로 지원된다.  1208은 UTF-8이며 최근에는 글로벌 시대에 발 맞추어 새로 구축하는 시스템 대부분에서 사용된다.

Db2 에서 코드 페이지는 get db  cfg명령으로  확인한다.

# db2 get db cfg for sample

Database territory = ko_kr
Database code page = 1208
Database code set = utf-8
Database country/region code = 82

Java 또는 WAS서버에서 코드페이지는  JVM속성에 의해 결정된다.  이값을 설정하지 않으면 OS 로케일값이 적용된다.

-Dclient.encoding.override= UTF-8

-Dfile.encoding=UTF-8

UTF-8에서 문자 데이터는 1~4바이트의 공간을 차지한다.  실 데이터에 따라 차이가 있으나 970, 1363에 비해 통상 스토리지 사용율은 증가된다.  만일 스토리지 절감을 위해  데이터베이스 코드 페이지를 970 혹은 1363 을 선택하는 경우라면,   970은  EUC-KR(KSC5601), 1363은 MS949로 JVM 속성값을 설정한다.  MS949는 Windows 서버 뿐 아니라 Linux, Unix서버의 JVM도 그대로 지원된다.

Db2에서 코드 페이지는 Database를 생성할 때 결정되며 추후 변경이 되지 않는다. 코드 페이지 선택시 우선 고려할 것은 업무 요구사항에 대응할 수 있는 코드 페이지이다.   즉 다국어 처리 요건이 있다면 코드페이지는 1208로 한다.  최근에는 굳이 다국어 요건이 없더라도 여러 주변의 애플리케이션들이 UTF-8을 기반하는 경우가 대부분이므로 Database도 UTF-8을 선택하는 경우가 많다.  특히 Java 애플리케이션 환경에서는 db2 jdbc 드라이버가 UTF-8 에 최적화되어 있으므로 1208이 시스템 성능 상 보다 유리하다.

만일 Database와 애플리케이션 환경과 코드페이지가 불일치되면 자동 코드 페이지 변환이 일어난다.  변환 작업은 데이터를 받는 쪽에서 일어나며 추가적인 자원사용과 성능  저하가 동반된다.  즉 조회의 경우 애플리케이션서버에서, 입력의 경우 DB서버에서 발생된다. 영향도는 쿼리에 따라 차이가 있으나 일반적으로 짧은 OLTP 쿼리일 수록 크다.

따라서 DB서버와 애플리케이션의 코드 페이지는 일치시키는 것이 데이터 무결성 및 시스템 처리 성능 모두에 바람직하다 할수 있다.