database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
ㆍDB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
DB2 Tutorials 432 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 432
PREFORMAT!... 그것이 알고싶다!!!
작성자
정재익(advance)
작성일
2002-10-17 20:04
조회수
8,647

PREFORMAT

 

원본출처 : http://my.dreamwiz.com/ibkcis/

 

LOAD 및 REORG 작업시 PREFORMAT 이란 Option을 사용하면 실제 사용량(데이터량)과 관계 없이 TABLESPACE 및 INDEXSPACE(VSAM,LDS)의 포맷작업을 미리 할 수 있는 기능으로 INSERT 작업의 속도향상을 기대할 수 있음.

 

- 사용형식

REORG TABLESPACE DB 명.TS 명 PREFORMAT...

 

- 사용 가능한 DB2 버전은?

DB2 for OS/390 Version 5(?) 부터...

 

- 한번 포맷은 영원한 포맷?

한번 포맷 후 PREFORMAT OPTION 없이 LOAD(REPLACE) 나 REORG를 다시하면 어떻게 될까... (포멧정보가 없어진다)

 

- PREFORMAT을 하면 얼마나 Performance 가 좋아질까?

(좋아지긴하는데 얼마나 좋아질지는...)

 

- PREFORMAT은 무조건 좋다?

사용 데이터없이 빈 공간이 많은 TABLESPACE의 경우 TABLESPACE SCAN 방식으로 읽는 경우 등 오히려 나쁜영향을 주지는 않을까...

(그럴까?...)

 

- INDEX의 경우에는 언제 포맷될까?

LAOD, REORG 작업을 하면서 PREFORMAT OPTION를 주고 작업을 하면 해당 인덱스는 자동으로 포맷이 될까?

 

세그먼트 테이블의 경우 테이블별로 이행하면 해당 테이블에 속한 인덱스만 된다? (된다?)

 

파티션TS의 경우 파트번호 없이 전체를 이행이나 재편성 할 경우 - 전체 다? (다?)

 

특정 파트별도 이행이나 재편성 작업시 Partition Index 및 Non-Partition Index 는 각각 언제 포맷될까... (파티션은 이행 및 재편성시 포멧됨

그럼 NPI는?..NPI만 별도로 REORG시 된다?...)

 

- D/S별 실제 사용량을 파악(계산)을 어떻게 해야 하나?

 

VSAM LISTCAT상에는 HI-A-RBA 값과 HI-U-RBA값이 동일하고 SYSIBM.SYSTABLEPART 및 SYSIBM.SYSTABLESPACE의 [SPACE]라는 컬럼은 해당 파트 및 TS의 전체의 실제 DEFINE 정보만을 보여주고 SYSIBM.SYSTABLESPACE의 [NACTIVE] 컬럼은 실제 ACTIVE PAGE 갯수를 보여 주지만 포맷을 한 후에는 전체 페이지를 사용한것으로 나오고 SYSIBM.SYSTABLEPART 의 PERCACTIVE 경우에 포맷 후에도 실제 사용량의 Percentage를 보여주지만 최신(실제) 정보를 보려면 RUNSTATS 작업을 해야하고...

 

인덱스의 경우 카탈로그 정보를 통해 실제 사용량을 파악하는 방법이 잘 안보이고...

 

계정업무등 OLTP성 업무를 DB2시스템으로 구현 하다보면 조금이라도 응답속도 개선을 위한것을 찾게 됩니다. 비록 전체 응답속도에서 차지하는 비중은 적더라고 시스템적으로 구현할 수 있는 기능이 있다면 알뜰하게 활용하는 것이 우리의 의무(?) 아닐까...^^* PREFORMAT 이 경우에 해당하는것 같아 한번 정리해 보았습니다

 

문제는...

당행의 경우에는 LISTCAT 정보를 이용하여 각 D/S별로 실제 사용량을 파악하고 이 정보를 DB 화 시키고, 이 정보를 이용하여 D/S별 사용의 적정성여부나 테이터의 증감 예측,IMAGE COPY한 테이프별 사용량의 적정성여부 REORG. COPY(DISK에)시 사용되는JCL 상의 각 DD문의 D/S의 크기를 지정하는 기준으로 활용하고 있습니다.(프로그램으로개발) 고로 당행의 경우 PREFORMAT 옵션을 사용 할 경우 각 D/S별 실제사용량을 파악하는데 어려움이 있을것 같습니다.

 

여러분의 지혜를 구합니다.

그럼...

 

===========================================================

 

다음은 김희숙님이 답변한 내용입니다.

자세한 답변에 감사드립니다.

 

-------------------------------------------------------------

 

일단 질문하신 내용에 답변을 하도록 하게습니다. 관련 자료는 다시 정리하여 Know-Hows Utility-LOAD section에 다시 정리하도록 하겠습니다.

 

- 한번 포맷은 영원한 포맷? 한번 포맷 후 PREFORMAT OPTION 없이 LOAD(REPLACE) 나 REORG를 다시하면 어떻게 될까... (포멧정보가 없어진다)

 

- 그렇습니다. LOAD/REORG할때 마다 지정한 option에 따라 그때 그때 영향을 받습니다. 즉 영원한 preformat은 아니지요.

 

Preformat의 시점

 

- Preformat은 Tablespace의 경우 data가 reload phase의 맨 끝 부분에 일어나며 index의 경우 build phase의 끝 부분에 일어난다.

 

- 즉 load된 data 및 index 영역 이후부터 할당된 space의 잔여 부분을 preformat하게 된다.

 

Preformat의 범위

 

- user-defined dataset인 경우 (USING VCAT 사용)

 

- utility 처리시 DB2가 delete/define을 하지 않음 그러므로 extention이 일어난 경우 reorg를 해도 줄어들지 않고 같거나 늘어 나게됨. 그러므로 preformat을 하게 되면 HURBA (high_used)와 HARBA(high_allocated) 사이의 모든 page가 preformat 되므로 secondary allocation 부분까지 preformat 된다..

 

- storage group을 사용한 dataset인 경우(USING STOGROUP)

 

- LOAD REPLACE를 하거나 REORG를 하는 경우 DB2가 VSAM dataset을 delete / define 하게 되므로 그때 마다 PRIQTY에 지정한 원래 space만큼 할당이 된다. 그러므로 preformat은 일단 primary 영역까지 일어나게 된다

 

- 두 경우 모두

 

- utility 수행 중에 extention이 일어 나게되는 경우는 그 부분에 대해서도 preformat이 일어남. 즉 extention 부분의 HARBA까지.

 

- 그러나 utility 수행 이후에 INSERT에 의해 extention이 일어난 경우는 일상적인 preformat logic에 의해 처리된다. (DB2 내부적인 block 단위)

 

 

- PREFORMAT을 하면 얼마나 Performance 가 좋아질까? (글쎄...)

 

- PREFORMAT은 무조건 좋다? : 사용 데이터없이 빈 공간이 많은 TABLESPACE의 경우 TABLESPACE SCAN 방식으로 읽는 경우 등 오히려 나쁜영향을 주지는 않을까... (그럴까?...)

 

Preformat의 Performance 고려 사항

 

- preformat option은 주로 새로운 tablespace에 insert가 일어 날때 필요한 dynamic format에 소요되는 지연시간을 줄일 수 있는 장점이 있다.

 

- 대신 LOAD 와 REORG 시에는 preformat 에 소요되는 시간에 의한 증가가 초래된다.

 

- 감소 혹은 증가되는 시간은 연속적인 INSERT의 빈도나 preformat 해야 할 space 크기에 따라 다를것임.

 

- 아직 발표된 data는 없고 각 자 환경에서 test 해 보는것이 바람직함.

 

- Insert가 아닌 query의 경우, 그리고 access path가 Tablespace scan인 경우는 모든 preformat 된, 사실은 empty page를 read하게 되어 performance가 저해되어 response time이 길어질 수 있다.

 

- preformat option은 query보다는 대량 Insert가 예상되는 Table에 사용하는 것이 좋다.

 

- 전형적인 임시 Table : 매일 아침 empty 상태로 되었다가 하루 종일 Insert가 일어나고 야간에 batch로 별도 처리를 거쳐 다른Table에 이행 되는 그리고 다시 empty로 되는 Table.

 

 

- INDEX의 경우에는 언제 포맷될까? LAOD, REORG 작업을 하면서 PREFORMAT OPTION를 주고 작업을 하면 해당 인덱스는 자동으로 포맷이 될까?

 

- 그렇습니다. LOAD / REORG 시에 지정을 하고 그때 Index는 자동으로 build되므로 Tablespace와 Index는 같은 방식으로 preformat 여부가 결정됩니다.

 

- 세그먼트 테이블의 경우 테이블별로 이행하면 해당 테이블에 속한 인덱스만 된다? (된다?)

 

-파티션TS의 경우 파트번호 없이 전체를 이행이나 재편성 할 경우 - 전체 다? (다?)

 

-특정 파트별도 이행이나 재편성 작업시 Partition Index 및 Non-Partition Index 는 각각 언제 포맷될까... (파티션은 이행 및 재편성시 포멧 그럼 NPI는?...)

 

- Tablespace 전체를 LOAD/REORG하는 경우는 당연히 해당 Tablespace와 관련된 모든 Index가 모두 preformat 됩니다.

 

LOAD PREFORMAT REPLACE INTO TABLE ....

 

REORG TABLESPACE DB.TS LOG NO PREFORMAT

 

 

 

- Partition 별로 LOAD /REORG할 격우는 해당 partition별로 preformat option을 지정할 수 있으므로 partition 별로 다르게 됩니다. 이때 NPI는 변동이 없습니다. 왜냐하면 partition별 LOAD/REORG시 NPI는 build 개념이 아니라 update/insert 개념으로 maint 되기 때문입니다.

 

LOAD REPLACE INTO TABLE .... PART 3 PREFORMAT

 

REORG TABLESPACE DB.TS PART 3 PREFORMAT

 

 

 

- Segmeted Tablespace의 경우 Table별로 load 하더라도 Tablespace 차원에서 RESUME/REPLACE option을 지정해야 하는 것처럼 REPLACE option으로 LOAD할때 preformat option을 주게 되면 그때 preformat이 일어나게 됩니다. 그러므로 두번째 Table의 경우는 LOAD RESUME YES로 load 해야 하므로 preformat option이 의미가 없을것 같슴니다. (이것은 그냥 제 생각입니다. 문서를 찾아봐도 이에 대한 정확한 언급은 찾지 못했습니다.)

 

 

- D/S별 실제 사용량을 파악(계산)을 어떻게 해야 하나? VSAM LISTCAT상에는 HI-A-RBA 값과 HI-U-RBA값이 동일하고 SYSIBM.SYSTABLEPART 및 SYSIBM.SYSTABLESPACE의 [SPACE]라는 컬럼은 해당 파트 및 TS의 전체의 실제 DEFINE 정보만을 보여주고 SYSIBM.SYSTABLESPACE의 [NACTIVE] 컬럼은 실제 ACTIVE PAGE 갯수를 보여 주지만 포맷을 한 후에는 전체 페이지를 사용한것으로 나오고 SYSIBM.SYSTABLEPART 의 PERCACTIVE 경우에 포맷 후에도 실제 사용량의 Percentage를 보여주지만 최신(실제) 정보를 보려면 RUNSTATS 작업을 해야하고... 인덱스의 경우 카탈로그 정보를 통해 실제 사용량을 파악하는 방법이 잘 안보이고...

 

맞습니다. Preformat을 할 경우 제일 불편한점을 지적해 주셨습니다.

 

언급하신 catalog Table 정보에 추가적으로 SYSTABLE.NPAGES에는 실제 row가 하나라도 있는 page 수를 나타내 주고 있지만 이 역시 RUNSTATS를 수행해야 얻을 수 있습니다.

 

이런류의 문제는 실제 사이트에서 DBA들이 겪는 volume 및 space 관리 절차의 고민중의 하나입니다. 한번에 해결해 주는 tool은 아직 없는것 같고 과장님이 하시는것처럼 일부 tool을 사용하여 나온 자료들을 자체 프로그램으로 report를 산출하여 관리하는 방법으로 하고 있는것 같슴니다.

 

결론적으로 preformat을 전체적으로 적용하는 것은 바람직하지 않고 insert가 대량으로 발생되는 table에 대해 performance를 검토한 후 많은 개선이 확신되는 경우 적용하는 것이 좋으리라 생각됩니다

[Top]
No.
제목
작성자
작성일
조회
435DB2 를 이용한 ASP/JSP 설치 가이드
정재익
2002-10-17
9146
434DB2 Limits
정재익
2002-10-17
9788
433BIND,PLAN,컴파일이 모지?,,,,
정재익
2002-10-17
9911
432PREFORMAT!... 그것이 알고싶다!!!
정재익
2002-10-17
8647
431DB2프로그램코딩예제
정재익
2002-10-17
16211
430PIECESIZE 란?
정재익
2002-10-17
7864
429파티션! 그것이 알고 싶다?
정재익
2002-10-17
8090
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.049초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다