릴리스 정보

40.6 제 3 장 고급 기능 사용

40.6.1 다중 스레드 응용프로그램 작성

"다중 스레드 혼합 응용프로그램" 섹션에 다음의 내용을 추가해야 합니다.

주:

기본 스택 크기를 사용하지 않고, 대신 스택 크기를 최소한 256 000으로 늘리는 것이 좋습니다. DB2에서는 DB2 함수를 호출할 때 최소 스택 크기는 256 000이어야 합니다. 따라서 스택의 총 크기를 할당할 때, 응용프로그램과 DB2 함수 호출을 위한 최소 요구사항을 충족시킬 수 있을 정도의 크기를 할당해야 합니다.

40.6.2 DB2 CLI 유니코드 응용프로그램 작성

다음은 이 장의 새로운 섹션입니다.

DB2 CLI 유니코드 응용프로그램 지원의 두 주요 영역이 있습니다.

1. ANSI 문자열 인수 대신에 유니코드 문자열 인수를 승인할 수 있는 함수 세트 추가.
2. 유티코드 데이터를 설명하는 새로운 C 및 SQL 데이터 유형 추가.

다음 섹션에는 이들 두 영역에 대한 추가 정보가 있습니다. 유니코드 응용프로그램으로 취급되려면, 연결하기 전에 응용프로그램이 SQL_ATTR_ANSI_APP 연결 속성을 SQL_AA_FALSE로 설정해야 합니다. 이와 같이 설정하면 CLI는 CLI와 데이터베이스 간의 기본 통신 방법으로서 유니코드를 사용합니다.

40.6.2.1 유니코드 함수

ODBC API 함수에는 해당 문자열 인수 형식을 나타내는 접미부가 붙어 있습니다. 유니코드를 승인하는 함수는 W로 끝나고 ANSI를 승인하는 함수에는 접미부가 없습니다.

주:

ODBC는 A로 끝나는 이름을 가진 동등한 함수를 추가하지만 이는 DB2 CLI에는 사용되지 않습니다.

SQLBrowseConnect        SQLForeignKeys          SQLPrimaryKeys
SQLColAttribute         SQLGetConnectAttr       SQLProcedureColumns
SQLColAttributes        SQLGetConnectOption     SQLProcedures
SQLColumnPrivileges     SQLGetCursorName        SQLSetConnectAttr
SQLColumns              SQLGetDescField         SQLSetConnectOption
SQLConnect              SQLGetDescRec           SQLSetCursorName
SQLDataSources          SQLGetDiagField         SQLSetDescField
SQLDescribeCol          SQLGetDiagRec           SQLSetStmtAttr
SQLDriverConnect        SQLGetInfo              SQLSpecialColumns
SQLGetStmtAttr          SQLStatistics	           SQLError
SQLNativeSQL            SQLTablePrivileges      SQLExecDirect
SQLPrepare              SQLTables

항상 문자열 길이가 인수가 되는 유니코드 함수는 해당 인수를 문자 수로 해석합니다. 서버 데이터에 대한 길이 정보를 리턴하는 함수의 경우에도 표시 크기와 정밀도를 문자 수로 설명합니다. 길이(데이터의 전송 크기)가 문자열 또는 비문자열 데이터를 나타낼 수 있는 경우, 길이는 바이트 수로 해석됩니다. 예를 들어, SQLGetInfoW는 길이를 바이트수로 취하지만, SQLExecDirectW는 문자수를 사용합니다. CLI는 응용프로그램의 바인딩에 따라 결과 세트를 유니코드 또는 ANSI로 리턴합니다. 응용프로그램이 SQL_C_CHAR에 바인드할 경우, 드라이버는 SQL_WCHAR 데이터를 SQL_CHAR로 변환합니다. ODBC 드라이버 관리 프로그램은 ANSI 드라이버용으로 SQL_C_WCHAR을 SQL_C_CHAR에 맵핑하지만 유니코드 드라이버용으로는 맵핑하지 않습니다.

40.6.2.2 새 데이터 유형과 유효한 변환

Addotopmal ODBC 및 CLI 정의 데이터 유형이 유니코드 데이터베이스를 수용하도록 추가되었습니다. 이러한 유형은 기존에 존재하는 C 및 SQL 유형 세트를 대체합니다. 새로운 C 유형인 SQL_C_WCHAR은 C 버퍼에 UCS-2 데이터가 원시 endian 형식으로 있음을 의미합니다. 새로운 SQL 유형인 SQL_WCHAR, SQL_WVARCHAR 및 SQL_WLONGVARCHAR은 특정 열이나 매개변수 표시기에 유니코드 데이터가 들어 있음을 나타냅니다. DB2 유니코드 데이터베이스의 경우, 그래픽 컬럼은 새로운 유형을 사용하여 설명됩니다.

표 10. 지원되는 데이터 변환

주:

D

변환이 지원됩니다. SQL 데이터 유형에 대한 기본 변환입니다.

X

모든 IBM DBMS가 변환을 지원합니다.

공백

IBM DBMS가 변환을 지원하지 않습니다.

• 데이터가 LOB 위치 지정자로 변환되지 않고, 위치 지정자는 데이터 값을 나타냅니다. 추가 정보는 대형 오브젝트(LOB) 사용을 참조하십시오.
• SQL_C_NUMERIC은 32비트 Windows 운영 체제에서만 사용 가능합니다.

40.6.2.3 폐기된 키워드/패치 값

유니코드 응용프로그램이 지원되기 전에 1바이트 문자 데이터로 작업하도록 작성된 응용프로그램은은 GRAPHIC=1,2 또는 3, Patch2=7 등과 같이 일련의 cli ini 파일 키워드 시리즈에 의해 2바이트 그래픽 데이터로 작업하도록 만들 수 있습니다. 이와 같은 임시 조치에 따라 그래픽 데이터가 문자 데이터로 표시되며 또한 보고되는 데이터의 길이가 달라집니다.

이들 키워드는 유니코드 응용프로그램에 더 이상 필요하지 않으며, 실제로 심각한 부작용이 있으므로 사용해서는 안됩니다. 이를 알고 있지 않으면, 특정 응용프로그램이 유니코드 응용프로그램일 경우, 그래픽 데이터 처리에 영향을 주는 키워드 없이 시도하도록 권장합니다.

40.6.2.4 유니코드 데이터베이스의 리터럴

비 유니코드 데이터베이스에서 LONG VARGRAPHIC 및 LONG VARCHAR 컬럼의 데이터는 비교될 수 없습니다. 내재된 코드 페이지 변환이 지원되지 않으므로 GRAPHIC/VARGRAPHIC 및 CHAR/VARCHAR 컬럼의 데이터는 명시적 유형변환(cast) 함수를 사용하여 서로 비교하거나 할당될 수만 있었습니다. 여기에는 GRAPHIC/VARGRAPHIC 리터럴이 CHAR/VARCHAR 리터럴과 G 접두부에 의해 차별화되는 GRAPHIC/VARGRAPHIC 및 CHAR/VARCHAR 리터럴이 포함됩니다.

유니코드 데이터베이스의 경우, GRAPHIC/VARGRAPHIC과 CHAR/VARCHAR 리터럴 사이의 유형변환(CAST)은 필요하지 않습니다. 또한, G 접두부가 GRAPHIC/VARGRAPHIC 리터럴 앞에 필요하지 않습니다. 최소한 한 인수가 리터럴이면, 내재된 변환이 발생합니다. 이는 G 접두부가 있거나 없는 리터럴을 SQLPrepareW() 또는 SQLExecDirect()를 사용하는 명령문 내에서 사용할 수 있도록 해줍니다. LONG VARGRAPHIC의 리터럴은 G 접두부를 가져야합니다.

자세한 정보는 SQL 참조서의 "제 3 장 언어 요소"에서 "데이터 유형간 유형변환"을 참조하십시오.

40.6.2.5 새로운 CLI 구성 키워드

다음 세 개의 키워드를 추가하여 유니코드 응용프로그램이 데이테이스에 연결될 때 여분의 오버헤드를 피할 수 있도록 하였습니다.

1. DisableUnicode

   키워드 설명

   유니코드에 대한 기본 지원 사용안함

   db2cli.ini 키워드 구문

   DisableUnicode = 0 | 1

   기본 설정

   0(false)

   DB2 CLI/ODBC 설정 탭

   이 키워드는 CLI/ODBC 설정 노트북을 사용하여 설정할 수 없습니다. 이 키워드를 사용하려면 db2cli.ini 파일을 직접 수정해야 합니다.

   사용법 주의사항:

   유니코드 지원이 사용 가능하고, 유니코드 응용프로그램이 호출한 경우, 코드페이지 변환에 의한 불필요한 자료 손실이 없도록 보장하기 위하여 CLI는 최선의 클라이언트 코드 페이지를 사용하여 데이터베이스에 연결하려고 시도합니다. 이는 코드 페이지가 교환되므로 연결 시간을 증가시키거나 또는 이러한 지원이 추가되기 이전에는 발생치 않았던 클라이언트에서의 코드 페이지 변환을 초래할 수 있습니다.

   이 키워드를 True(1)로 설정하면, 데이터가 서버에 송신되기 이전에 먼저 모든 유니코드 데이터가 응용프로그램의 국지 코드 페이지로 변환됩니다. 이는 국지 코드 페이지에서 대표될 수 없는 데이터의 데이터 손실을 초래할 수 있습니다.

2. ConnectCodepage

   키워드 설명

   여분의 연결 오버헤드를 피하기 위해 데이터 소스에 연결하는 경우, 사용할 구체적 코드 페이지를 지정합니다.

   db2cli.ini 키워드 구문

   ConnectCodepage = 0 | 1 | <any valid db2 code page>

   기본 설정

   0

   DB2 CLI/ODBC 설정 탭

   이 키워드는 CLI/ODBC 설정 노트북을 사용하여 설정할 수 없습니다. 이 키워드를 사용하려면 db2cli.ini 파일을 직접 수정해야 합니다.

   사용법 주의사항:

   비 유니코드 응용프로그램은 언제나 응용프로그램의 지역 코드페이지 또는 DB2Codepage 환경설정을 사용하여 데이터베이스에 연결합니다. 기본적으로 CLI는 유니코드 응용프로그램이 UTF-8 및 UCS-2 코드 페이지를 사용하여 유니코드 데이터베이스에 연결되도록 합니다. 비유니코드 데이터베이스에 연결하기 위한 기본값은 Windows용 DB2, Unix용 DB2, OS/2용 DB2를 실행하는 데이터베이스 서버의 데이터베이스 코드 페이지를 사용하는 것입니다. 그러면 코드 페이지 변환으로 인한 불필요한 데이터 유실이 없습니다.

   연결시에 여분의 오버헤드를 피하기 위하여 비 유니코드 데이터베이스에 연결하는 경우, 사용자는 이 키워드를 사용하여 데이터베이스의 코드 페이지를 지정할 수 있습니다.

   1 값을 지정하면 SQLDriverConnect()가 출력 연결 문자열에 올바른 값을 리턴하게 되므로, 향후 SQLDriverConnect() 호출에 값을 사용할 수 있습니다.

3. 유니코드 서버

   키워드 설명

   데이터 소스가 유니코드 서버임을 표시. 설정 ConnectCodepage=1208 과 동일.

   db2cli.ini 키워드 구문

   UnicodeServer = 0 | 1

   기본 설정

   0

   DB2 CLI/ODBC 설정 탭

   이 키워드는 CLI/ODBC 설정 노트북을 사용하여 설정할 수 없습니다. 이 키워드를 사용하려면 db2cli.ini 파일을 직접 수정해야 합니다.

   사용법 주의사항:

   이 키워드는 ConnectCodepage=1208와 동일하며 편리성을 위해 추가하였습니다. OS/390 버전 7 또는 그 이상의 DB2에 연결하는 경우, 이 키워드를 사용하여 여분의 연결 오버헤드를 피할 수 있습니다. 여분의 처리가 필요하지 않으므로, 이 키워드를 Windows의 DB2, Unix의 DB2 또는 OS/2 데이터베이스의 DB2에 사용할 필요는 없습니다.

40.6.3 트랜잭션 모니터로써의 MTS(Microsoft Transaction Server) 사용

다음은 "설치 및 구성" 서브섹션의 DISABLEMULTITHREAD 구성 키워드 기본값을 정정합니다.

• DISABLEMULTITHREAD 키워드(기본값 0)

40.6.4 화면 이동 커서

다음 정보는 "화면 이동 커서" 섹션에 추가되어야 합니다.

40.6.4.1 OS/390용 서버측 화면 이동 커서 지원

Unix, Windows 및 OS/2 플랫폼용 UDB 클라이언트는 OS/390 버전 7 데이터베이스에 대해 수행할 때 갱신가능한 서버측 화면 이동 커서를 지원합니다. 3층(three-tier) 환경에서 OS/390 화면 이동 커서를 액세스하려면, 클라이언트 및 게이트웨이가 DB2 UDB 버전 7.1, FixPak 3 이상을 실행 중이어야 합니다.

화면 이동 커서를 액세스할 수 있는 2개의 응용프로그램 사용 인터페이스(ODBC 및 JDBC)가 있습니다. JDBC 인터페이스는 정적 화면 이동 커서만을 액세스할 수 있지만, ODBC 인터페이스는 정적 및 keyset 위주(keyset-driven) 서버측 화면 이동 커서를 액세스할 수 있습니다.

커서 속성

아래 테이블은 ODBC에서 OS/390 버전 7 커서에 대한 기본 속성을 나열합니다.

표 11. ODBC에서 OS/390 커서에 대한 기본 속성

지원되는 페치 방향

모든 ODBC 페치 방향은 SQLFetchScroll 또는 SQLExtendedFetch 인터페이스를 통해 지원됩니다.

keyset 위주(keyset-driven) 커서 갱신

keyset 위주(keyset-driven) 커서는 갱신가능한 커서입니다. CLI 드라이버는 조회가 SELECT ... FOR READ ONLY 조회로서 발행되거나 FOR UPDATE 절이 이미 존재하는 경우를 제외하고 FOR UPDATE 절을 조회에 추가합니다. OS/390용 DB2에서 구현되는 keyset 위주(keyset-driven) 커서는 값 동시성 커서입니다. 값 동시성 커서는 최적 잠금의 결과를 가져오며, 여기서, 값은 갱신이나 삭제가 시도될 때까지 보유되지 않습니다. 갱신 또는 삭제가 시도되면, 데이터베이스 서버는 응용프로그램이 검색한 이전 값과 주요 테이블의 현재 값을 비교합니다. 값이 일치하는 경우, 갱신 또는 삭제가 성공합니다. 값이 일치하지 않는 경우, 조작이 실패합니다. 실패한 경우, 응용프로그램은 다시 값을 조회하고 여전히 적용가능하다면 갱신 또는 삭제를 다시 발행해야 합니다.

응용프로그램은 두가지 방식으로 keyset 위주(keyset-driven) 커서를 갱신할 수 있습니다.

• SQLExecute() 또는 SQLExecDirect()가 있는 SQLPrepare()를 사용하여 UPDATE WHERE CURRENT OF "<cursor name>" 또는 DELETE WHERE CURRENT OF "<cursor name>"을 발행하십시오.
• SQLSetPos() 또는 SQLBulkOperations()를 사용하여 결과세트에 행을 추가, 갱신 또는 삭제하십시오.

  주:

  SQLSetPos() 또는 SQLBulkOperations()를 통해 결과 세트에 추가된 행은 서버에서 테이블로 삽입되지만, 서버의 결과 세트에 추가되지는 않습니다. 그러므로, 이러한 행은 갱신가능하지 않으며 다른 트랜잭션이 작성한 변경사항에 민감하지도 않습니다. 그러나, 삽입된 행은 클라이언트에 캐쉬되므로 결과 세트의 일부로 나타납니다. 삽입된 행에 적용되는 모든 트리거는 적용되지 않았던 것처럼 응용프로그램에 나타납니다. 삽입된 행을 갱신가능하고, 민감하게 하고, 적용가능한 트리거의 결과를 보려면, 응용프로그램이 조회를 다시 발행하여 결과 세트를 재생성해야 합니다.

화면 이동 커서 지원 이전에 작성된 응용프로그램의 문제점 해결

화면 이동 커서 지원은 새로운 기능이므로, OS/390용 UDB 또는 Unix, Windows 및 OS/2용 UDB는 행동 또는 성능 변경이 발생할 수 있습니다. 화면 이동 커서가 지원되기 전에는, 화면 이동 커서를 요청한 응용프로그램이 포워드 전용 커서를 받기 때문에 이런 경우가 발생합니다. 화면 이동 커서 지원하기 전의 응용프로그램의 이전 활동을 복원하려면, 다음과 같은 구성 키워드를 db2cli.ini 파일에 설정하십시오.

표 12. 화면 이동 커서가 지원하기 전에 응용프로그램 활동을 복원하는 구성 키워드 값

40.6.5 복합 SQL 사용

다음의 주의사항이 책에서 누락되었습니다.

   Any SQL statement that can be prepared dynamically, other than a query,
   can be executed as a statement inside a compound statement.
 
 
   Note: Inside Atomic Compound SQL, savepoint, release savepoint, and
   rollback to savepoint SQL statements are also disallowed. Conversely,
   Atomic Compound SQL is disallowed in savepoint.

40.6.6 저장 프로시듀어 사용

40.6.6.1 SQL 및 Java 저장 프로시듀어 빌드 및 디버그를 위한 특권

SQL 저장 프로시듀어를 빌드, 디버그, 실행하려는 사용자에게 다음 특권을 부여해야 합니다.

• db2 grant CONNECT on database to userid
• db2 grant IMPLICIT_SCHEMA on database to userid
• db2 grant BINDADD on database to userid
• db2 grant SELECT on SYSIBM.SYSDUMMY1 to userid
• db2 grant SELECT on SYSCAT.PROCEDURES to userid
• db2 grant UPDATE on DB2DBG.ROUTINE_DEBUG to userid

Java 저장 프로시듀어를 빌드, 디버그, 실행하려는 사용자에게 다음 특권을 부여해야 합니다.

• db2 grant CONNECT on database to userid
• db2 grant IMPLICIT_SCHEMA on database to userid
• db2 grant BINDADD on database to userid(SQLJ를 사용하여 정적 SQL로 Java 저장 프로시저를 빌드하는 경우에만 필요함)
• db2 grant SELECT on SYSIBM.SYSDUMMY1 to userid
• db2 grant SELECT on SYSCAT.PROCEDURES to userid
• db2 grant UPDATE on DB2DBG.ROUTINE_DEBUG to userid

DB2DBG.ROUTINE_DEBUG 테이블을 작성하려면 다음 명령을 실행하십시오.

db2 -tf sqllib/misc/db2debug.ddl

Java 저장 프로시저 디버그에 대한 자세한 정보는 응용프로그램 개발 안내서를 참조하십시오.

40.6.6.2 CLI로 저장 프로시듀어 작성

다음은 CLI 저장 프로시듀어에 대해 문서화되지 않은 제한사항입니다.

   If you are making calls to multiple CLI stored procedures,
   the application must close the open cursors from one stored procedure
   before calling the next stored procedure. More specifically, the first
   set of open cursors must be closed before the next stored procedure
   tries to open a cursor.

40.6.6.3 CLI 저장 프로시듀어 및 자동 바인드

다음은 이 책의 정보를 보충하는 내용입니다.

CLI/ODBC 드라이버는 사용자가 적합한 특권 또는 권한을 갖고 있는 경우, 보통 CLI/ODBC 응용프로그램이 데이터베이스에 대해 SQL을 처음 실행할 때 CLI 패키지를 자동으로 바인드합니다. CLI 패키지의 자동 바인드는 저장 프로시듀어내에서 수행될 수 없으므로, 응용프로그램이 수행하는 제일 처음 동작이 CLI 저장 프로시듀어를 호출하는 것인 경우 발생하지 않습니다. 그러므로, 새 데이터베이스에 대해 CLI 저장 프로시듀어를 호출하는 CLI 응용프로그램을 실행하기 전에, 이 명령으로 CLI 패키지를 한번 바인드해야 합니다.

UNIX

db2 bind <BNDPATH>/@db2cli.lst blocking all

Windows 및 OS/2

db2bind "%DB2PATH%\bnd\@db2cli.lst" blocking

권장하는 접근 방법은 런타임시 자동 바인드를 예방하기 위해 데이터베이스 작성시 이들 패키지를 항상 바인드하는 것입니다. 사용자에게 특권이 없거나 다른 응용프로그램이 동시에 자동 바인드를 시도하는 경우 자동 바인드가 실패할 수 있습니다.