[SQL] 오라클 호환성에 따른 문자열 길이 변화

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 정도까지는 무난하지 않나 싶다.

오라클 호환성 옵션 사용 시 검토할 기술문서를 소개하고 마무리 해 본다.

 

https://www.ibm.com/developerworks/mydeveloperworks/blogs/SQLTips4DB2LUW/entry/about_the_db2_compatibility_vector_and_what_not_to_say_at_the_dinner_table282?lang=en