|
BIND,PLAN,컴파일이 모지?,,,,
원본출처 : http://my.dreamwiz.com/ibkcis/
http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/DSNAP0F5/4.1?ACTION=MATCHES&REQUEST=precompile&TYPE=FUZZY&SHELF=DSNSH0F5&searchTopic=TOPIC
다음은 컴파일과 bind에 관한 내용들입니다.
참고하세요.
DB2 for OS/390 버전5 기준입니다.
1. PRECOMPIL시 하는일
① SQL Statement의 검사(Syntax 검사)
② Library에서 Module을 삽입시킨다.(DCLGEN output,SQLCA 등)
③ SQL Statement를 골라서 DBRM을 작성한다.
④ Source Program의 SQL Statement를 CALL Statemen나 Command로 바꿔서
변경된 Source Program을 작성한다.
2. BIND시 하는일
①Table이나 View의 정의와 SQL Statement의 정합성의 검사
②User(BIND 한사람)의 Access 권한검사
③Access Path의 선택(INDEX 사용유무 결정)
④적용업무 Plan의 작성과 저장
* package인경우에는 bind package 작업시 상기내용을 check 하고
bind plan pklist 작업시에는 각각의 package를 묶어주는 역활만 한답니다.
3. 그럼 왜 precompile과정이 필요한가?
사전컴파일이라고 명명한 이유는
일반프로그램언어의 컴파일과정보다 먼저수행되기 때문에 붙여진것 같아요.
일반 프로그램언의 컴파일러는 sql문을 인식할수 없기 때문에
사전에 일반언어와 sql 문장을 구분하여 일반언어는 컴파일,링커에디터과정을
거쳐서 실행모쥴이 만들어지고,
sql 문장은 DBRM(Data Base Request Module) 라이브리에 보관 되었다가
bind작업시 input으로 사용되어 실행가능한 기계어로 변환됩니다.
그러니까 bind작업은 일반프로그램언어의 컴파일작업과 비슷한개념이라고도
볼수 있습니다.
bind의 결과는 아시는데로 plan이 만들어집니다.
plan의 각종정보는 db2 catalog table에 등록되고,
수행가능한 형태로 디렉토리db에 보관됩니다.
load모쥴에 등록되어 있는 일반프로그램언어의 실행모쥴이 수행되다가
call문장을 만나면 db2 카달로그 테이블에서 관련정보를 참조하고
디렉토리db에서 해당 plan의 실행문장을 가져와 함께 수행됩니다.
님이 질문하신 call문장은 precompil과정에서 만들어지고요
이상입니다.
어떻게 도움이 되셨는지요?
그럼...
다음은 보충질문에 대한 답변입니다.
- sql 문장을 call로 바꿔서 ...DBRM으로 만들어논다는 말인가요..?
<제의견>사전컴파일단계가 지나면 sql문장과 일반프로그램언어는 별도의 단계
를 거친답니다. call문등을 포함한 기왕의 프로그램언어source는
컴파일,링커에디터의 단계를 거쳐 실행모쥴로 만들어지고,
sql문장이있는 dbrm부분은 bind절차를 거쳐 plan으로 만들어집니다.
- MODIFED SOURCE, LINK EDIT 부분은 SQL문장이 들어가있는
전체소스들인가요..?
<제의견>sql문장 자체는 포함하고 있지 않답니다.
- 프리 컴파일 후에 둘로 나눠서 하는일이 분리된다는 말인가요..?
<제의견>그렇습니다.
- 그리고 2번 BIND의 마지막 답변에서 PLAN일경우는 각각의 package를
묶어주는 역활만 한다고 했는데 무슨얘기인지 모르겠어요...
<제의견>프로그램을 수행할려먼 package 자체로는 수행할수가 없답니다.
반드시 plan형태로 만들어져야 수행할 수 있답니다.
각각의 package는 bind plan pklist라는 작업을 거쳐 plan으로 만든후에
실제 수행할수 있답니다. db2프로그램의 기본수행단위가 plan이거던요.
===================================
다음글은 nicecom 에서 가져온 글이라고 합니다.
Host Language로 작성된 Program을 Compile하기 전에, 반드시 Program에 들어 있는 SQL을 Prepare해야만 한다.
CICS Command를 가지고 있는 Application은 Compile하기 전에 Program을 Translate 해야 한다.
Precompile을 실행하면 Modify된 Host Language Program과 SQL의 Selection인 DBRM 으로 나누어 진다.
Modify된 Program을 Compile하고 Link/Edit하여 Load Module을 생성한다.
Application Program과 DB2의 Interface를 가능하게 하려면 Language Interface Module을 포함시켜야 한다.
Subsystem Language Interface Module
TSO / Batch - DSNELI (DB2 TSO Attachment Facility LIM)
- DSNALI (DB2 Call Attachment Facility LIM)
IMS - DFSLI000 (DB2 IMS LIM)
CICS - DSNCLI (DB2 CICS LIM)
< Precompile Step >
//PC EXEC PGM=DSNHPC,REGION=4M,PARM=(HOST(IBMCOB))
//STEPLIB DD DSN=DBN510.SDSNEXIT,DISP=SHR
// DD DSN=DBN510.SDSNLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD DSN=NICE.MAINT.DB2(&PGMNAME),DISP=SHR
//SYSLIB DD DSN=DSN510.SRCLIB.DATA,DISP=SHR
// DD DSN=DSN510.SDSNSAMP,DISP=SHR
//DBRMLIB DD DSN=DSN510.DBRMLIB.DATA(&PGMNAME),DISP=SHR
//SYSCIN DD DSN=&&DSNHOUT,DISP=(NEW,PASS,DELETE),UNIT=SYSDA,
// SPACE=(800,(500,500))
//SYSUT1 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA
//SYSUT2 DD SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA
DBRMLIB : Precompile 후 SQL Statement의 Selection
SYSCIN : Precompile 후 Modify된 Program Source
< Translate Step >
//TRANS EXEC PGM=DFHECP1$,PARM='COBOL2,CICS,DBCS,SP',REGION=4M,
// COND=(5,LT,PC)
//STEPLIB DD DSN=CICSTS12.CICS.SDFHLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSIN DD DSN=&&DSNHOUT,DISP=(OLD,DELETE)
//SYSLIB DD DSN=DSN510.SRCLIB.DATA,DISP=SHR
// DD DSN=DSN510.SDSNSAMP,DISP=SHR
// DD DSN=CICSTS12.CICS.SDFHMAC,DISP=SHR
//SYSPUNCH DD DSN=&&DSNHOU1,DISP=(NEW,PASS),UNIT=SYSDA,
// SPACE=(400,(200,200),,,ROUND),DCB=BLKSIZE=400
< Compile Step >
//COBPILE EXEC PGM=IGYCRCTL,REGION=4M,
// PARM='RENT,NODYNAM,LIB,OBJECT,APOST,LANGUAGE(UE)'
//STEPLIB DD DSN=IGY.V2R1M0.SIGYCOMP,DISP=SHR
// DD DSN=SYS1.SORTLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DSN=CEE.SCEECICS,DISP=SHR
// DD DSN=CEE.SCEELKED,DISP=SHR
// DD DSN=CICSTS12.CICS.SDFHCOB,DISP=SHR
// DD DSN=DSN510.SRCLIB.DATA,DISP=SHR
// DD DSN=DSN510.SDSNSAMP,DISP=SHR
//SYSIN DD DSN=&&DSNHOU1,DISP=(OLD,DELETE)
//SYSLIN DD DSN=&&LOADSET,DISP=(NEW,PASS),UNIT=SYSDA,SPACE=(800,(500,100))
//SYSUT1 DD SPACE=(800,(500,100),,,ROUND),UNIT=SYSDA
//SYSUT2 DD . . . . . . . . . .
//SYSUT7 DD SPACE=(800,(500,100),,,ROUND),UNIT=SYSDA
//*
< Link/Edit Step >
//LKED EXEC PGM=IEWL,REGION=0M,COND=((4,LT,COBPILE)),
// PARM='RENT,LIST,XREF,AMODE=31,RMODE=ANY'
//SYSLIB DD DSN=CEE.SCEECICS,DISP=SHR
// DD DSN=CEE.SCEELKED,DISP=SHR
// DD DSN=DSN510.SDSNLOAD,DISP=SHR
// DD DSN=CICSTS12.CICS.SDFHLOAD,DISP=SHR
//DB2LIB DD DSN=DSN510.SDSNLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD SPACE=(1024,(200,200)),UNIT=SYSDA
//SYSLIN DD DSN=CICSTS12.CICS.SDFHCOB(DFHEILIC),DISP=SHR
// DD DSN=&&LOADSET,DISP=(OLD,DELETE)
// DD DDNAME=SYSIN
//SYSLMOD DD DSN=USER.LOADLIB(&PGMNAME),DISP=SHR
2.3.2 Bind Procedure
DB2 Data를 Access하기 위해서 SQL Statement는 Access Path가 필요하다.
종 류 설 명
Dynamic SQL - SQL이 실행될 때 Access Path가 결정된다.
- 반복적으로 자주 사용하지 않는 Application에 사용한다.
Static SQL - Access Path가 Bind, Rebind시에 결정된다.
- 반복적으로 자주 사용하는 Application에 사용한다.
DBRM을 Bind할 때 Package로 Bind할 수도 있고, Plan으로 Bind할 수도 있다.
모든 DBRM을 하나의 Plan으로 Bind할 수 있다.
하나의 Plan은 다수의 DBRM, 하나의 Package List를 포함할 수 있다.
하나의 Package는 하나의 DBRM만을 가질 수 있다.
Plan은 Package가 Remote에서 Bind되었을 지라도 Local에서 Bind되어야 한다.
Remote에서 Run되는 Package는 Remote에서 Bind되어야 한다.
Package의 장점
-. 하나의 SQL이 변경되었을 때, 전체를 Rebind할 필요가 없고, 해당 Package만
Rebind해 주면 된다.
-. 기존에 만들어져 있는 Collection에 Package를 추가하고 싶은 경우에, 전체 Plan
을 Bind할 필요 없이 해당 Application을 Bind하고 Plan(Package List)을 Bind
-. 하나의 Plan에 대하여 여러 개의 Version을 관리할 수 있다.
-. Package단위로 Option을 다르게 적용할 수 있다.
-. SQL Statement내에 Qualified되지 않은 이름의 Object를 사용하였을 경우 Bind
시에 Qualified Name을 부여할 수 있다.
Package를 사용하면 Dynamic Plan Selection과 그것과 관련되는 Exit Routine이 필요
하지 않다. Plan에 들어있는 Package List는 실행될 때까지 Access되지 않는다.
그러나 Dynamic Plan Selection과 Package를 함께 사용할 수 있고 그렇게
함으로써 Plan의 수를 줄일 수 있다.
Package를 Bind할 경우 Collection을 지정해주고 Collection은 Physical한 단위가
아니고 생성되는 것도 아니며 단지 Package를 Grouping하기 위하여 사용된다.
Parameter Option 설 명
Action Replace - 새로운 Object를 Bind할 때 사용한다.
Acquire Use - Table이나 Table Space의 Lock Term을 정해준다.
Allocate - 일반적인 경우에는 Use/Deallocate가 효과적이다.
Release Commit - Concurrency가 중요한 Transaction은 Use/Commit이
Deallocate 좋고 Allocate/Deallocate는 Deadlock을 피할 수 있
으며 Batch Job에 효율적이다.
Isolation RR - Page Lock의 Term을 지정하는 Parameter로
Concurency
CS 를 위하여 CS를 사용하는 경우가 대부분이지만
Application이 변경된 Data를 Program의 종료시점
까지 유지해야 할 경우 RR이 효과적이다.
UR - Lock이 거의 없고, Access가 빠르고 Contention이
적지만, Un-commited Data Un-consistency가 있다.
Validate Run - Program내에 있는 Table과 Column의 Validate를
BIND Check하는 시점을 지정하며 Run을 사용할 경우 Bind
시에 Error가 발생하더라도 Bypass한다. 이 경우
Transaction의 실행되는 순간 Error가 발생할 수 있
기 때문에 Bind를 지정하는 것이 좋다.
변 경 Bind Action
Table, Index나 다른 Object를 Drop할 때 다음에 수행할 때 Automatic Rebind
Object가 Recreation할 때 가 수행된다.
Object의 사용 권한을 Revoke할 때
Catalog Statistics를 Update하기 위한 Access Path를 변경하도록 Rebind를
RUNSTATS를 실행할 때 해준다.
Table에 Index를 Add할 때 Index를 사용할 수 있도록 Rebind를
해준다.
Bind Option을 변경할 때 Rebind를 해주며, 만약 Rebind후에도
Option이 적용되지 않으면 Option
ACTION(REPLACE)로 Bind한다.
Host Language와 SQL Statement를 Pre-compile, Compile, Link/Edit과
변경할 때 ACTION(REPLACE)로 Bind한다.
2.3.3 Bind Samp
//XXXXXXX JOB . . . . . . . . . . . .
//DSNTIAS EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN DD *
< 1 DBRM을 1 Plan으로 Bind >
DSN SYSTEM(subsystem-id)
BIND PLAN(plan-name) MEM(prog-a) ACT(REP) ISOLATION(CS) -
LIB('DSN510.DBRMLIB.DATA')
END
< 다수의 DBRM들을 하나의 Plan으로 Bind >
하나의 Plan에 여러 개의 DBRM을 포함시킬 수 있지만 DBRM이 많아질수록
Maintenance가 어려워 진다.
DSN SYSTEM(subsystem-id)
BIND PLAN(plan-name) MEM(prog-a,prog-b,prog-c) ACT(REP) ISOLATION(CS) -
LIB('DSN510.DBRMLIB.DATA')
END
< DBRM을 Package List에 Bind >
DSN SYSTEM(subsystem-id)
BIND PACKAGE PKLIST(group.*) MEM(prog-a,prog-b) -
LIB('DSN510.DBRMLIB.DATA')
END
|
