DB V10.5 케플러가 출시된 올해, V9.7 코브라는 이제 오래된 제품처럼 여겨진다.
얘기하고자 하는 내용은 V9.7 때 있었기 때문에 지금은 달라졌을 수도 있다고 생각한다.
샘플 데이터
| db2 +p –tv << EOF create table t1 (c1 int); insert into t1 values (1),(2); select * from t1; EOF |
테스트 SQL
|
select c1, case when c1=1 then '1234' else '12' end c1_string, length( case when c1=1 then '1234' else '12' end) c1_length from t1 |
(Case 1) 오라클 호환성 없는 환경
| C1 C1_STRING C1_LENGTH --- ------------- --------------- 1 1234 4 2 12 2 |
(Case 2) 오라클 호환성 켜지 않고 생성된 DB에 ORA값을 적용한 경우
| C1 C1_STRING C1_LENGTH --- ------------- --------------- 1 1234 4 2 12 4 |
위 2개의 사례로 보면 “오라클 호환성”을 적용함으로서 데이터 길이가 틀리게 인식됨을 확인할 수 있다.
IBM Lab에서는 다음과 같이 정리해서 답변을 주었다.
case1) ORA mode + DB2_COMPATIBILITY_VECTOR=
case2) ORA mode + DB2_COMPATIBILITY_VECTOR=ORA
case3) Non ORA mode + DB2_COMPATIBILITY_VECTOR=
| C1 C1_STRING C1_LENGTH --- ------------- --------------- 1 1234 4 2 12 2 |
case4) Non ORA mode + DB2_COMPATIBILITY_VECTOR=ORA
| C1 C1_STRING C1_LENGTH --- ------------- --------------- 1 1234 4 2 12 4 |
ORA mode 는 “호환성 변수를 적용하고 DB 생성”함을 의미한다.
결론은 “호환성 모드가 아닌 DB에 ORA 값을 적용한 경우, 문자열이 CHAR로 변환”이 된다는 점이다.
즉 출력되어야 문자열 중 “가장 긴 길이를 기준”으로 문자열 길이가 정해져서, 짧은 문자열이 출력되어도 패딩처리되어 문자열 길이는 동일하게 처리되는 것이다. (varchar로 인식이 되었다면 이런 문제는 발생하지 않았을 것이다.)
Trace 분석 결과 (0x20은 ASCII에서 공백문자를 의미함)
|
10509 data DB2 UDB runtime interpreter sqlri_trace_bno_zvals fnc (3.3.112.1463.0.0) pid 3436680 tid 2829 cpid 2711578 node 0 sec 4 nsec 200418531 probe 0 bytes 17 Data1 (PD_TYPE_DEFAULT,12) Hexdump: 6161 6161 6161 2020 2020 2020 aaaaaa |
개인적으로 오라클 호환성 변수 사용을 권장하지는 않지만, 사용을 해야 되는 경우 F 정도까지는 무난하지 않나 싶다.
오라클 호환성 옵션 사용 시 검토할 기술문서를 소개하고 마무리 해 본다.
'Note' 카테고리의 다른 글
| [개발] db2jcc 와 db2jcc4 의 차이 (0) | 2013.11.28 |
|---|---|
| [개발] Windows에서 ESQL 컴파일 및 Connect By Siblings (0) | 2013.11.28 |
| [보안] 인스턴스 구성변수(dbm cfg) authentication (0) | 2013.10.11 |
| [이중화] 로그 쉬핑(shipping)을 통한 복제서버 구성 (0) | 2013.09.26 |
| [관리] db2dart 와 db2 inspect (0) | 2013.08.27 |