-
Embedded SQL정리필요2 2007. 11. 24. 01:23
Embedded SQL
- SQL 구문을 사용해서 DB 어플리케이션을 작성할 때, 어플리케이션 내에 SQL 구문이 정의 되는 방식의 SQL API를 Embedded SQL이라 하며, 정의 형식에 따라 Static Embedded SQL과 Dynamic Embedded SQL로 구분이 된다. (1) Static Embedded SQL 정의: 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 과정이 필요하다.(2) Dynamic Embedded SQL 정의: 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 생성 시점 및 관리 여부의 차이가 된다.(3) Embedded SQL 어플리케이션 작성 Process 
그림. Embedded SQL 어플리케이션 작성 Process 설명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 구문을 처리한다.(4) DB2 Package 정의: DB2의 Package는 최적화된 SQL 구문을 담고 있는 DB object이다. 하나의 프로그램 source는 하나의 Package에 대응되고, Program Source내의 SQL 구문은 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를 생성한다.
그림 . 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 구문을 수행하는 것과 같은 동일한 효과를 가진다.Host Language
(Programming Language)Precompiler File 확장자
(input - Source)File 확장자
(input - Source)C prep OR precompile .sqc .c C++
(AIX - case sensitive)prep OR precompile .sqC .c C++
(Windows-case insensitive)prep OR precompile .sqx .cxx Java sqlj* .sqlj .java AND .ser 표. Precompiler와 Precompile File의 확장자 참고) 1. sqlj는 translator로 bindfile 생성을 하지 않으며, bind file은 .ser file을 이용한 db2profc
(DB2 Profile Customizer)의 precompile option을 통해 생성된다.
2. 각 Precompiler는 DB2 SDK (Software Development Kit)에 포함되어 있다.(4) Application Bind 정의 : 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" 특권이 있어야 한다. 따라서 이러한 권한을 가진 Group의 사용자로 어플리케이션 개발자 권한을 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을 지정하여 수행하면 된다.