정의: Program내에 Embed 된SQL 구문 및 SQL 구문내의 DB Object (컬럼 이름 등)가 어플리케이

        션 실행전인 개발시에 미리 정의된 형태의 SQL 구문 형식

	

        SQL 구문에 의해서 수행되는 작업 (조회 및 수정)시 필요한 data 값 (host variable)

        만이 어플리 케이션 개발시가 아닌 실행시에 지정되어 그 값에 따라 SQL 구문이

        수행된다.





  특징 

   1. 어플리케이션의 precompile, bind 과정이 필요하다. 

      bind 과정중에 DB object에 대한 type, syntax, previlege checking이 이루어지므로, SQL

      구문에 정의된 DB Object는 어플리케이션 bind시에 반드시 DB내에 존재하여야 한다.





   2. Package를 미리 생성하며, 이는 DB2에 의해서 저장되고 관리된다.

      어플리케이션 bind후 DB내에 Package가 생성되며, 어플리케이션 실행시, 앞서 bind 과정에

      서 생성된 Package의 접근 경로 (access plan 또는 access path)을 이용하여 해당 SQL의 

      최적화된 수행이 이루어진다.

          

      Dynamic Embedded SQL 어플리케이션이 매번 실행시마다 Package를 작성해서 SQL구문을 처

      리하는 것에 비해 미리 bind 과정에서 작성된 Package를 바로 사용함으로써, Package 작성

      에 필요한 overhead를 덜수 있다.

	

   3. Bind 과정은 최초 한번만 필요하나, 상황에 따라 정기적으로 rebind를 수행할 수 있다.

   4. 반복적이고 정형화된 업무 (예약, 잔액 조회등)와 같은 사전에 정의된 (pre-defined) 트랜

      잭션 형태의 어플리케이션 구현에 적합하다.





   장점

   1. 사전에 Package를 작성해서 사용하므로, 실행 속도가 빠르다.

   2. 어플리케이션 실행시가 아닌, 개발시에 DB object에 대한 사전 검사가 가능하다.





  단점

   1. 개발시에 SQL 구문이 정의되어 있어야 한다.

   2. Precompile, bind 과정이 필요하다.

 정의: Program내에 Embed 된 SQL 구문이 어플리케이션 개발시가 아닌, 실행시에 정의되어

         (완성되어) 처리되는 SQL 구문 형식





   특징

   1. Bind 과정이 필요없다. 

      Static Embedded SQL의 경우처럼 미리 bind 과정을 거쳐 미리 Package를 생성하는 것이 

      아니라, 어플리케이션 실행시에 SQL 구문이 완성되어 DB내에 Package를 만들어, 이 

      Package내의 access plan을 이용한다.

   2. 어플리케이션 실행 시점의 (current) DB2의 통계 정보를 기초로한 Package가 작성되므로, 

      매번 실행시마다 최적화된 access plan이 제공된다.

	

      Static SQL의 경우, bind 과정에서 미리 생성된 Package는 bind time시의 DB2 통계정보를

      근거로 작성되므로 실제 어플리케이션 실행 시점의 통계정보와 차이가 날 수 있다.

      따라서, 이러한 상황을 방지하기 위해 주기적으로 DB2 통계정보 갱신을 위한 RUNSTAT 작업

      및 어플리케이션 Rebind를 수행한다. (5.3 Application Rebind 참조)



   3. 실행시 생성된 Package는 DB2에 의해서 관리되지 않는다. (dummy Package)

   4. Embedded SQL이므로 precompile 과정이 필요하다.





   장점

   1. 어플리케이션 내 각 SQL 구문에 대해 가장 최근 시점의 통계정보를 근거로한 access plan

      을 가질 수 있다.

   2. SQL 구문은 개발시가 아닌, 실행시에 확정되므로, 보다 다양하고 유연한 어플리케이션 개

      발이 가능하다.





   단점

   1. 실행시마다 Package를 작성해야 하는 overhead로 Static에 비해 처리 속도가 느리다.

   2. 실행전에 SQL 구문의 type, syntax, previlege checking 이 불가능하다.





   참고) DB2의 Package는 해당 SQL을 DB2의 해당 DB내에서 처리하기 위한 최적의 방법인 access

         plan을 가진다. 이 access plan은 DB2의 System catalog 정보를 근거로한 DB2 통계정보

         를 근거로 DB2 Optimzier에 의해서 생성된다. Static 및 Dynamic SQL의 가장 큰 차이점

         은 이 Package 생성 시점 및 관리 여부의 차이가 된다. 

설명

    1. Embedded SQL 구문이 포함된 프로그램의 Source File을 작성한다.

    2. DB에 connect 하여, 각 Source File을 precompile한다.

       precompiler는 embedded SQL 구문을 여라 다양한 API request로 바꿔주는 역할을 하며,

       precompile 과정을 통해 bind file을 생성하거나, 직접 DB에 Package를 생성할 수 있다.

    3. 변경된 Source File을, 작성한 language compiler를 이용하여 compile한다.

    4. Object File을 DB2 및 language Library에 link하여 실행 프로그램을 생성한다.

    5. DB에 connect한 후, 2의 과정에서 생성된 bindfile을 DB에 bind 시킨다.

       이는 DB에 Package를 생성하기 위해서이며, 2 과정의 precompile 옵션을 이용해 직접

       Package를 생성하였으면 수행할 필요가 없다. 그러나 다른 DB에 같은 내용의 Package를 

       생성하고자 할 때, 같은 bindfile을 이용한다.

    6. 생성된 어플리케이션을 실행한다.

       이 어플리케이션은 앞서 생성된 DB의 Package를 사용하여 SQL 구문을 처리한다.

정의: DB2의 Package는 최적화된 SQL 구문을 담고 있는 DB object이다. 하나의 프로그램

          source는 하나Package내의

          Section에 대응된다.

  

    특징

    1. 구조: Static Embedded SQL Program은 default로 precompile 과정을 통해서 연결된 DB내

             에 Package를 생성한다. Section은 compile된 형태의 SQL 구문이며, Package 내에

             는 각 Embedded SQL 구문에 대응되는 여러 Section을 가진다. 각 Section 내에는

             하나의 SQL 구문에 대응되어, SQL 구문과 이 SQL 구문에 대한 최적화된 access 

             plan이 section 내에 저장된다. 이렇게 생성된 Package는 직접 DB에 저장되거나,

             또는 Package 생성 모듈이 bindfile내에 저장되어, 별도의 bind 과정을 거쳐서 DB

             에 Package를 생성한다.

  2. Dynamic Embedded SQL 어플리케이션의 Package

        Dynamic Embedded SQL 구문의 경우, 마찬가지로 precompile - bind 과정을 거쳐서

        Package를 생성하나, Section내에 access plan이 없는것이 Static과의 차이점이다.



     3. Package 실행 특권

        생성된 Package내의 SQL 구문을 실행하기 위해서는 사용자가 Package에 대해 Execute

        특권이 있어야 한다. 이는 SQL 구문내의 DB object에 대한 직접적인 권한 없이도 직접

        SQL 구문을 수행하는 것과 같은 동일한 효과를 가진다.

정의 : Bindfile은 Static Embedded SQL 구문에 대한 Package 생성 정보를 담은 file이며, 

       bindfile을 이용하여 DB에 Package를 생성하는 과정

	

특징 

1. DB2 Package 생성은 precompile 과정에서 직접 DB에 생성되거나 (bindfile option), 

   bindfile을 만들어 나중에 bind 과정을 거쳐서 DB에 생성할 수 있다. 이를 "deferred 

   binding"이라 한다.



2. Static Embedded SQL 어플리케이션에만 적용되는 과정이다.

   어플리케이션이 접속되는 DB에 한번만 bind하면 되며, 추후의 bind 작업은 "Application

   Rebind" 과정을 통해 마찬가지로 bind 한다.



3. Package 및 Bindfile과 SQL 어플리케이션 실행 File은 같은 내용의 Consistency Token 

   (Timestamp 정보)를 가진다.



   Bindfile에 의해서 Package 생성시, 생성시점(timestamp)에 대한 정보(consistency token)

   가 Package내에 저장된다. 이와 똑같은 내용의 consistenty token이 DB의 system catalog 및

   어플리케이션 실행 모듈에 저장되어, SQL 어플리케이션이 SQL 구문을 수행할 때, 그에 맞는

   Package내의 access plan을 이용할 수 있도록 한다.



4. Bind시 필요한 권한 및 특권

   Bind 작업을 수행하는 사용자는 최소한 "BINDADD" 권한이 있어야 하며, IMPLICIT_SCHEMA,

   CREATEIN" 특권이 있어야 한어플리케이션

   개발자 권한을 grouping한다. 또한 static SQL이 reference하는 모든 DB object에 대한 적절

   한 특권이 있는 사용자여야 하므로, 이러한 DB object에 대한 특권은 명시적으로 사용자에게

   grant 되거나 PUBLIC으로 선언되어야 한다. 

   (group에만 grant 되었을 경우 bind시 fail이 난다.)



5. Blocking Factor

정의: Record Blocking은 대용량의 데이타를 처리하는 어플리케이션의 네트웍을 통한 데이타 접

      근 속도를 향상시켜주기 위한 데이타의 네트웍 이동에서의 DB2 데이타처리 방식이며, 이러

      한 Record Blocking은 어플리케이션 bind시 Blocking Factor (bind option)에 의해서 지정

      된다.



특징: Record Blocking은 Cursor type 및 Record Blocking을 수행할 DB2 Server의 storage 량에

      따라 결정된다.



      multiple Row로 구성된 Result Set의 처리는 Cursor를 통해 이루어진다. Cursor type에 대

      한 Blocking Factor는 UNAMBIG, ALL, NO 가 있다.

			

      UNAMBIG : FOR UPDATE cursor를 제외한 모든 cursor는 blocking된다.

      ALL     : 모든 cursor가 blocking된다.

      NO      : 어떠한 cursor도 blocking 처리되지 않는다.	



      DBM cfg의 ASLHEAPSZ 파라미터로 multiple data record를 요청하는 어플리케이션에 대해

      DB2 Server에서의 data buffer에 사용되는 memory 할당량을 지정한다.      

      (DB Server의 memory 할당) 또한, 원격 SQL 어플리케이션에서의 memory 할당은 DBM cfg의

      RQRIOBLK값으로 지정한다.

		

 참고) CLI 어플리케이션 및 DB2 CLP (Command Line Processor)의 Blocking Factor의 default 

       값은 UMAMBIG이며, 이를 변경하고자 할 경우에는 각각의 bindfile (db2cli.bnd,

       db2clp.bnd)를 bind 할 때, bind option을 지정하여 수행하면 된다.

정의: DB2CLI는 C 및 C++ 언어를 이용한 DB2 Programming Interface의 하나이다.



특징

1. DB2CLI는 Microsoft의 ODBC 및 X/Open, ISO Call Level Interface Standard를 기초로 구성되었

   다. 

   따라서, DB Vendor와 상관없이 ODBC 및 X/Open의 CLI를 지원하는 DBMS 모두에서 사용할 수 있는

   portable 어플리케이션 개발이 가능하다. 



 

   참고) DB2 ODBC Driver는 MS의 ODBC 2.0의 Level 2 및 ODBC 3.0의 Level 1의 모든 spec, Level

         2의 대부분의 spec에 따라 개발되었다.

 

         DB2CLI는 ODBC를 기초로하므로,  상호 호환적인 관계에 있다. 따라서 C나 C++ 언어 

         (MS Visual C++)를 이용한 CLI 어플리케이션 또는 MS Visual Basic 및 PHP, Python, Perl

         과 같은 script Language를 이용한 ODBC 어플리케이션 개발 및 실행은 각각 DB2 CLI

         ODBC Driver에 의해서 처리되며, 각 Driver의 내용 및 Driver 및 DB2 기능은 거의 비슷하

         다.





2. DB2CLI는 Dynamic 어플리케이션 개발 방식이다. (bind 및 Package 생성 불필요)

   따라서, Dynamic Embedded Application과 마찬가지로 별도의 bind 과정이 필요없으며, Packagae

   생성은 어플리케이션 실행시에 이루어진다. CLI 어플리케이션은 DB2에 의해서 제공되는 공통적

   인 access package를 이용하여 실행되므로 개별 어플리케이션의 bind 과정은 필요없는 대신에

   공통적으로 DB2CLI package를 해당 DB에 한번 bind하여 DB2CLI 또는 ODBC 어플리케이션이 이를

   사용할 수 있도록 한다.





   CLI 어플리케이션의 (Embedded) Dynamic SQL 어플리케이션과의 차이점



   ■ Precompile 과정이 없다. (따라서 bind 및 Package 생성이 없다)

      어플리케이션 level의 Package가 없는 대신, 모든 CLI 어플리케이션이 공통적으로 이용하는

      CLI Package들을 해당 DB에 한번만 bind한다.

   ■ 명시적인 cursor 정의가 없다.

   ■ Commit/rollback 구문대신 SQLEndTran() Fuction을 사용한다.

   ■ SQLCA / SQLDA 와 같은 DB에서의 특정 error 처리 API가 없다.

   ■ Host variable 대신에 parameter marker를 사용한다. 또한, 다음의 제약 사항을 가진다.

   ■ multiple Row 처리를 한번에 수행할 수 없다. (array fetch/ insert)

   ■ scrollabel cursor가 지원되지 않는다.

	

3. CLI 및 ODBC의 Dynamic SQL 구문은 Program에 embedded 되지 않고, DB2에 의해서 제공되는

   C/C++ API를 이용하여 function argument의 형식으로 DB2에 전달된다 

   (direct API call). 따라서, Program precompile 과정이 불필요하다.



4. Embedded SQL 구문에서 SQL 수행 성공 여부를 검사하는데 사용하는 SQLDA 및 SQLCA를 사용하지

   않으므로 어플리케이션 작성이 쉽다.



장점

1. Precompile, bind 과정이 필요없다. 

2. 어플리케이션 실행시에 DB2의 통계정보를 기초로한 access plan을 이용할 수 있다.

3. 다른 DB platform에 쉽게 이식할 수 있다.



단점

Static Embedded SQL과 비교하여 어플리케이션 실행 속도가 느리다.

(Dynamic Embedded SQL과 공통)



   ODBC와 CLI의 비교

   ■ Commit CLI 어플리케이션은 아키텍쳐상 ODBC Driver Manager없이 어플리케이션이 직접 CLI

      Driver와 통신한다.

   ■ DB2 ODBC Driver 및 DB2 Data Source는 반드시 ODBC Driver Manager에 등록되어야 하나,

      CLI Driver는 DB2 Client만 설치되면, 별도의 등록 과정이 필요없다.

   ■ ODBC는 Windows 및 Linux 환경에서만 사용할 수 있으나, CLI는 UNIX를 포함한 보다 다양한

      환경 및 C/C++, Java와 같은 강력한 프로그래밍 언어를 지원한다.

1. DB2 SDK를 설치하고, DB2 CLI Library를 확인한다. 

   Windows 환경 : sqllib \ lib \ db2cli.lib

   UNIX 환경 : sqllib / lib / libdb2.a 또는 libdb2.so

2. 접속하고자 하는 DB가 원격일 경우, 어플리케이션 client에 Node 및 DB cataloging을 한다.

3. DB2 CLI bindfile들을 접속할 DB에 bind한다.

   다음의 디렉토리에서 접속하고자 하는 DB2 서버의 종류에 따라 다음의 file들을 bind한다.

참고) .lst File은 bindfile들을 모아놓은 list file이며 list file의 bind는 다음의 예와 같

        이 file 앞에 "@"문자li.lst blocking all isolation cs grant public messages db2cli.msg"

      "db2 bind @ddcsmvs.lst blocking all sqlerror continue grant public"



4. 필요에 따라, db2cli.ini File의 내용을 편집하여 CLI 환경 구성을 수정한다. 

   가장 많이 사용되는 option은 다음과 같다.

   1. DB2 Client를 설치하고, 접속하고자 하는 DB가 원격일 경우, Node 및 DB cataloging 작업

      을 수행한다.

   2. ODBC Driver Manager가 설치되었는지 제어판에서 확인하고, DB2 Data Source를 System

      DSN 또는 사용자 DSN으로 등록한다.



      참고) DB2 ODBC Driver ("IBM DB2 ODBC Driver")는 DB2 Server 또는 client 설치시에 자동

            으로 설치 및 등록된다.



   3. ODBC 환경 설정은 DB2 CLI와 마찬가지로 db2cli.ini File을 편집하여 적절할 환경 구성을

      설정한다.



CLI 및 ODBC에 대한 보다 자세한 내용은 DB2 Manual인 "DB2 CLI Gude and Reference" 및 "ODBC 

Guide & Reference"를 참조한다.

정의: JDBC 및 SQLJ 는 DB2에서 Dynamic SQL 및 Static SQL을 처리하QL interface이다.

2. JDBC는 DB2CLI의 경우처럼, API Call로써 SQL 구문이 처리하며, Dynamic SQL 처리 방식의 특성

   을 가진다. SQLJ는 SQL 구문이 프로그램상에 Embedded되어, Static SQL의 방식을 따른다.



3. JDBC 와 SQLJ의 비교

DB2 UDB는 2가지 형태의 JDBC Driver를 제공한다. (sqllib/java/db2java.zip)

  App Driver: COM.ibm.db2.jdbc.app.DB2Driver - DB2 Client가 어플리케이션 클라이언트에 설치

              되어 있을 경우 사용한다. (Java Application)

  Net Driver: COM.ibm.db2.jdbc.net.DB2Driver - DB2 Client가 없을 경우 사용한다.

              (Java Applet)

  참고) Java Servlet의 경우도 DB2 Client 설치 여부에 따라 Driver를 선택하여 사용한다.

sqlj (SQLJ Translator): precompiler와 마찬가지로 Java Source code에서 Static Embedded SQL

구문을 precompile하여 수정된 java file (.java)과 Serialized profile (.ser) 을 생성한다.





javac (Java Compiler): 수정된 java source code를 compile하여 실행 class와 ProfileKey class

를 생성한다.





db2profc (DB2 Profile Customizer): SQLJ Translator에 의해서 생성된 Serialiezed Profile을

customzation하여 DB에 직접 Package를 만들거나 또는 bindfile을 생성한다.





SJProfileKeys.class File: 실행 java class와 DB2 DB내의 Package를 연동시켜주는 역할 

(consistency token)을 수행한다.





참고) 1. SQLJ 어플리케이션은 DB2의 일반적         가진다.

      2. SQLJ Translator (sqlj.zip)은 DB2 SDK에 포함되며, SQLJ 어플리케이션 개발시에만 필

         요하다. 작성된 SQLJ 어플리케이션 (Java Application, Applet, Servlet)의 실행환경

         에서는 필요없으며, 대신 db2java.zip (DB2 JDBC Driver File) 및 runtime.zip (SQLJ

         어플리케이션 실행 환경 File)만이 사용자 profile의 classpath에 등록되어 있으면 된

         다.

1. 적절한 JDK를 시스템에 설치하고 이의 관련 class를 사용자의 profile에 등록한다.

2. sqllib / java 디렉토리의 db2java.zip, sqlj.zip, runtime.zip file을 사용자 profile의 classpath에 등

    록한다.

3. 다음 예처럼 사용자의 profile내 또는 db2profile에 sqllib / lib directory를 LD_LIBRARY_PATH로 등

    록한다. (UNIX 환경 only) 예) LD_LIBRARY_PATH=$HOME/sqllib/lib

4. Java Stored Procedure 또는 UDF (User Defined Function)을 사용할 때는 DBM cfg의 JDK11_PAT

    H의 값을 사용하고자하는 java class file이 있는 directory로 설정한다.

- lsolation Level은 어플리케이션이 DB내의 특정 Table을 Access하는 동안 다같은 Table을

  access하는 다른 어플리케이션으로부터 참조되는 동일한 data를 어떻게 Locking할 것인가를

  결정한다.



- Application에 대한 lsolation Level은 Precompile 또는 Bind시 해당 option으로 지정된다.

- Isolation Level은 Data 조회 트랜잭션 (Select SQL)에만 적용된다. 즉, 한 어플리케이션에서 해당

  data의 조회 및 변경 트랜잭션 (update, insert, delete SQL)이 발생할 때, 다른 어플리케이션에서

  어떠한 방식으로 동일한 data를 조회할 것인가를 결정한다.

가. Cursor Stability(CS)

(가) Cursor가 Positioned되고 있는 Row에만 Lock상태(S Lock - Share Lock)를 유지하며, Row

       가 update되지 않고 fetch 되면서 cursor가 다음 row로 move될 때 lock 상태를 해제한다.

       

참고) Row가 update될 경우에는 transaction commit 또는 rollback, connect시 open된 cursor가

         close하면서Lock을 해제한다.



(나) CS로 binding한 어플리케이션은 다른 어플리케이션에 의한 uncommited changes는 참조할

       수 없다.

나. Repeatable Stability (RS)

(가) 한 UOW 내에서 어플리케이션에 의해 retrive되는 Row에 대해 Lock상태를 유지한다. 즉, 조

      회 조건에 해당되는 row에 대해서만 S Lock이 걸린다.



(나) 한 UOW 내에서 동일 조회 조건에 맞는 data가 insert된 후, 같은 조회가 반복되면 Phantom

       Row가서 이전 조회의 결과보다 많은 조회

       결과가 나타날 수 있다. 이 트랜잭션이 commit 되거나 rollback 되면 phantom Row는 사라

       지게 된다.



(다) 조회 조건-LEFT: 25px">다. Repeatable Read (RR)

(가) 한 UOW 내에서 어플리케이션에 의해 참조되는 모든 Row에 대해 Lock 상태를 유지 한다.



(나) 즉, 조회 조건에 대한 결과 Row 뿐만 아니라 (RS), 결과 Row를 도출하기 위해 조회 조건에

       의해 참조되는 모든 Row에 S Lock이 걸린다. 따라서 RS의 경우처럼, 동일 UOW 내에서 조

       회 조건에 맞는 data에 대한 변경 트랜잭션 (insert, update, delete)은 해당 Row에 S Lock이

       걸려있으므로 발생하지 않는다. 따라서 Phantom Row 또한 발생할 수 없다.



(다) 조회 조건에 대한 결과 Rows로부터 하나씩 fetch해오면서 결과 Row 및 이에 대해 참조되는

       Row의 Lock을 하나씩 해제한다.

라. Uncommited Read(UR)

(가) 다른 어플리케이션의 변경 트랜잭션에 의한 uncommited changes data에 대해 어플리 케이

       션이 access하는 것을 허용한다.



(나) 해당 Row에 Lock을 걸지 않는 것이며, 이를 `dirty read'라고도 한다. 

가. Runstats(통계 정보 재구성 작업)을 실행했을 경우, 모든 Embedded SQL 어플리케이션이 이의

     적용을 받도록 "db2rbind" 명령을 수행한다.



나. index를 새롭게 생성하거나, 재구성하였을 경우, 이를 이용하는 어플리케이션에 대해서 rebind

     를 수행한다.



다. DataBase Configuration 내용중 다음의 내용이 변경되었을 경우

     (가) Buffpage

     (나) Sortheap

     (다) Locklist

     (라) Maxlocks

     (마) Avg_appls

     (바) Seqdetect



다. Bind를 해야할 경우

     (가) 프로그램내의 SQL문이 수정되었을 경우

     (나) Bind Option을 변경하고자 할 경우

     (다) DB에 Package가 존재하지 않을 경우 

가. db2rbind Command : Rebind all packages in a database

     ☞ db2rbind databse -L logfile -U userid -P password

     ☞ sysadm 또는 dbadm권한이 있어야 함



나. Rebind Command : Bind file의 필요없이 DB안에 내장된 package를 다시 작성

     ☞ rebind package package-name

     ☞ sysadm 또는 dbadm권한 또는 package에 대한 Bind 권한이 있어야 함. 

1. Stored Procedure Builder의 작성 언어

    SQL/PL (Procedural Language) : DB2 UDB V7이후부터 가능

    Java : DB2 UDB V6이후부터 가능



2. 그외 일반 프로그래밍 언어 (C/C++, COBOL)로 Stored Procedure를 작성할 경우, 직접 프로그래밍

    을 해야하나 번거롭고 복잡하므로, Stored Procedure Builder 사용을 권장한다.



3. Stored Procedure Builder를 이용한 Stored Procedure 작성은

    www.kr.ibm.com/software/data/db2/techinfo/index.html 기술 정보의 "DB2 UDB Stored

     Procedure Builder Guide" 또는 부록B 를 참조한다.