IBM DB2 UDB Blog Center

요즘의 개발 추세는 java 기반으로 가고 있지만, 과거 시스템에는 Embedded SQL로 개발되어진 시스템들이 많다.

특히 OS390, AS400 등의 host 시스템에서는 여러 류의 ESQL 프로그램들이 사용되는 것 같다.

ESQL 이 DB와 연동하기 위해서는 테이블에 대한 정의서(DDL)와 개발 언어로 변환된 변수 선언부가 필요해진다.

수많은 테이블에 대해서 테이블의 데이터 유형을 개발 언어에 맞게 변환을 수작업으로 한다면 (단순한 일에) 많은 시간이 소요될 것이다.

그래서 DBMS마다 테이블에 대한 유형을 개발 언어에 맞게 변환해주는 유틸리티를 제공하는 것 같다.

DB2 for LUW에서는 db2dclgn 이라는 유틸리티를 제공한다.

db2dclgn를 수행하여 테이블의 데이터 유형들이 개발언어에 맞는 유형들로 변환된 결과물을 얻을 수 있다.

(내가 정보를 덜 찾아본 것일 수 있겠지만) 호스트 시스템에서 제공하는 유틸리티보다는 효용성이 떨어지는 것 같다.

테이블에 대한 정의서는 출력을 해 주지 않기 때문이다.

범용 DB2 (DB2 for LUW)에서는 db2dclgn과 db2look을 같이 사용해야 개발자들에게 필요한 “선언부 생성물”이 만들어 질 듯 하다.

고객사 지원 시 단순하게 사용했었는데, –n (접두사), –c(접미사) 를 사용하면 개발자들에게 그나마 편할 듯 하다.

접두사는 “테이블의 스키마 명" 지정하고 접미사는 –c 옵션을 주면 컬럼명을 사용하게 된다.

-s 옵션은 “구조체 명"으로 출력파일의 첫 줄을 정의하는 옵션이다.

스키마 이름이 다른 동명 테이블의 dcl를 추출하는 경우, 접두사(-n) 와 구조체 명(-s) 를 통하여 구분을 지을 수 있고,

-c 옵션으로 컬럼명을 “구조체의 필드명(변수명)"으로 사용하여 테이블 컬럼 정보를 참조할 수 있을 것 같다.

개발지원 시, 더 테스트를 했으면 개발자 분들이 조금은 더 편하게 작업을 할 수 있도록 도움을 드렸을텐데, 지금에 와서 시간을 두고 옵션들을 테스트해 보니 어떻게 db2dclgn을 사용해야 할 지가 보인다. (정보센터에서 다양한 예제가 있었으면 도움이 되었을 텐데, 그렇지 못함을 탓해 본다.)

이전에 db2 jdbc driver 버전에 대해 기술한 적이 있다.

JAVA 6 (JDK 1.6) 버전 관점에서 설명을 하고 버전 확인하는 법들을 설명했는데, Driver 버전이 4인 경우와 아닌 경우에 따른JAVA 연동 시의 문제점을 최근에 알게 되었다.

문제점

- JDBC 4.0 (db2jcc4.jar) 으로 DB2와 연동하는 경우 SELECT문의 “컬럼 별명"이 반영되지 않는(무시되는) 현상

원인

- jdbc 4.0 에서는 ResultSetMetaData.getColumnName 과 ResultSetMetaData.getColumnLabel 이 명확히 구분되어

  ResultSetMetaData.getColumnLabel 를 사용하지 않는 이상 “컬럼 명"으로 결과 값들이 반환됨

정리

DB2 V9.5 정보센터를 보면 Application Developer 변경 사항에 이에 대한 언급이 설명되어 있다.

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=%2Fcom.ibm.db2.luw.wn.doc%2Fdoc%2Fi0052606.html

DB2 V9.7 에서도 이에 대해 예제를 들어 설명해 놓았다. (오타가 있어 감안해서 봐야 될 것 같다)

http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.apdv.java.doc%2Fsrc%2Ftpc%2Fimjcc_c0052593.html

두 버전의 호환 사용방안

(방법1) useJDBC4ColumnNameAndLabelSemantics Connection  설정

(방법2) DataSource property to DB2BaseDataSource.NO (2) 설정

고객사의 connect by 관련 지원하다 C 소스 코드를 컴파일 해보는 작업을 잠시 해 보게 되었다.

윈도우 환경에서 사용되어 C 컴파일러가 필요하여 지인을 통해 무료 컴파일러인 MinGW 다운받아 설치를 했다.

그러나 bldrtn 을 이용해서 컴파일은 되지 않았다. (cl.exe 오류)

왜 오류가 날까? bldrtn을 열어보니 기본 컴파일러로 Visual Studio C++ 를 사용하도록 BLDCOMP 변수에 박여 있었다.

즉 Visual Studio를 설치해야 bldrtn을 구동할 수 있게 셋팅되어 있던 것…

MinGW 및 기타 gcc 들을 설치해 봐야 “어떤 값"을 넣어 “기본 컴파일러" 설정해야 하는지 알 수 없기에 Trial version으로 VS를 설치하였다.

물론 VC++이 설치되어 있다고 bldrtn이 실행되지 않는다.

환경변수 설정이 필요하다. (내 컴퓨터 > 속성 > 고급 시스템 설정 > 고급 탭 > 환경 변수)

1) INCLUDE 변수에 경로 추가  (stdio.h 에러)

    C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include

2) CLASSPATH, LIB 변수에 경로 추가

    C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib    (msvcrt.lib 에러)

    C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib   (kernel132.lib 에러)

    SDK가 설치 되지 않은 경우 kernel132.lib 에러가 발생하므로 Visual Studio 업데이트 파일 실행 후 kernel132.lib 라이브러리 확인 필요

이후 bldrtn 이 정상적으로 수행되었다.

오라클의 connect by 구문은 DB2 V9.7 이상부터 지원되고 있다.

(V9.5에서도 오라클 호환성 변수가 적용되어 지원은 된다.)

표준 recursive SQL 인 Common table 을 이용해서는 “위계/계층"의 순서를 살릴 수가 없다.

(common 테이블 결과는 위계/계층별로 정렬되어 보여 줌)

성능 이슈가 제기되어 DB2 의 connect by의 대안으로 ibm developer works에 소개된 c로 만든 connect by였다.

(참고: http://www.ibm.com/developerworks/data/library/techarticle/dm-0510rielau/ )

connect by 대상 테이블에 다른 테이블이 조인되어 사용되는 경우 siblings by 처리 시 미묘하게 값 정렬이 틀려진다.

성능은 좋았지만 적용할 수가 없었다.

현재까지 DB2에서 제공되는 connect by 는  self join 방식에서는 성능 문제가 없지만, 다른 테이블과 join 되는 경우 성능이 많이 느려지는 느낌을 받았고, self join 이여도 siblings by 를 추가하는 경우 느려지는 느낌을 받았다.

다른 테이블과의 join이 발생하는 경우,  connect by 처리를 inline view(subquery)로 처리하여 되도록 self join 만 하도록 해야 성능 저하를 막을 수 있을 것으로 보인다.