DB2 UDB  설계 및 구축 실무 2 2003. 10. 27. Business IT  전문대학원 Data&Knowledge Engineering  안병철
목  차 6. Index  설계 7. Partition Table 8. DB2 Locking 9.  채번  Table 10.  기타
6.  인덱스 설계 <ul><li>INDEX  역할 </li></ul><ul><li>데이터의 검색 성능을 향상한다 . </li></ul><ul><li>ROW 의 유일성을 보장한다 . </li></ul><ul><li>IN...
<ul><li>INDEX  개수 가이드 라인 </li></ul>6.  인덱스 설계 청구원장 ,  입금원장 ,  매출원장 등과 같이 대용량의 중요 데이터  Table 은  Index  개수를  1 개 이상 만들지 않도록 ...
7.  파티션 테이블 <ul><li>파티션 테이블 개요 </li></ul><ul><li>Primary Key  를 기준으로 한 테이블을 여러 개의 물리적  Device 에 분산하여  I/O  부하 감소 </li></ul...
<ul><li>파티션  Key  구성 </li></ul>7.  파티션 테이블 <ul><li>History  성 파티션  Key   -  데이터의 추가가 마지막 파티션에 집중되는 경우 ( 보통 일자가  Key 로 됨 ) ...
8. DB2 Locking <ul><li>Locking  개요 </li></ul><ul><li>SIZE : Lock 이 걸리는 데이터 단위   - ROW, PAGE, TABLE, TABLESPACE </li></ul><...
<ul><li>Lock Duration(ISOLATION Level) </li></ul><ul><li>보통  BIND  시  ISOLATION 을  CS(CURSOR Stability) 로 준다 . </li></ul><...
9.  채번 테이블 <ul><li>MAX  값을 이용한 채번 </li></ul><ul><li>Key 에 종속되어 있는  SEQUENCE 를 채번 할 경우 사용함 ( MAX + 1) </li></ul><ul><li>동시에...
9.  채번 테이블 <ul><li>One Fetch Index Scan </li></ul>SELECT  MAX(MGT_N_B11)  INTO  :W-B990-SEQ  FROM  LCSD2B99.TB990  WHERE  ...
10.  기타 <ul><li>컬럼 분리 </li></ul><ul><li>컬럼값이 여러  Filed 의 조합으로 구성되어 있는 경우 조회에 필요한  Field  값은 컬럼으로 분리하여 관리한다 .   -  SQL  사용 ...
<ul><li>Scroll Logic  처리 방법 </li></ul><ul><li>CURSOR 를  OPEN 하는 시점에 데이터를 가져오는 경우   -  적절한  Index  가 구성이 되어 있지 않아  Cursor O...
<ul><li>화면과  Index  관계 </li></ul><ul><li>화면 설계 시 주의 사항   -  검색 조건은  Index 에 해당하는 컬럼만 선택하도록 함 .   -  한 테이블에 여러 개의 검색 조건을 하기...
Upcoming SlideShare
Loading in …5
×

[2]

653 views
544 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
653
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

[2]

  1. 1. DB2 UDB 설계 및 구축 실무 2 2003. 10. 27. Business IT 전문대학원 Data&Knowledge Engineering 안병철
  2. 2. 목 차 6. Index 설계 7. Partition Table 8. DB2 Locking 9. 채번 Table 10. 기타
  3. 3. 6. 인덱스 설계 <ul><li>INDEX 역할 </li></ul><ul><li>데이터의 검색 성능을 향상한다 . </li></ul><ul><li>ROW 의 유일성을 보장한다 . </li></ul><ul><li>INDEX 고려 사항 </li></ul><ul><li>PRIMARY KEY 는 Unique Index 가 필요하다 . </li></ul><ul><li>UNIQUE 성을 필요로 하는 컬럼에 대해 만든다 . </li></ul><ul><li>Foreign Key 는 Index 생성하는 것이 좋다 . </li></ul><ul><li>SQL 의 WHERE 절에서 자주 사용되는 컬럼을 INDEX 로 생성한다 . </li></ul><ul><li>ORDER BY, GROUP BY, DISTINCT 가 사용되는 컬럼에 인덱스 추가 </li></ul><ul><li>데이터 검색 패턴을 고려하여 CLUSTERING INDEX 를 선정한다 . </li></ul><ul><li>인덱스 Column 의 순서에 주의한다 . </li></ul><ul><li>주의 사항 - INSERT, DELETE, UPDATE 의 부하가 발생하므로 변경 사항이 많은 테이블에는 최소한의 인덱스만 추가 - DEADLOCK 의 발생 빈도가 증가할 수 있음 - LOAD, REORG, RECOVERY 등 Utility 소요시간 증가 </li></ul>
  4. 4. <ul><li>INDEX 개수 가이드 라인 </li></ul>6. 인덱스 설계 청구원장 , 입금원장 , 매출원장 등과 같이 대용량의 중요 데이터 Table 은 Index 개수를 1 개 이상 만들지 않도록 한다 . 1 개 원장성 Partition Table(5 억건 이상 ) <=2 Partition Table(1 억건 이상 ) NPI(Primary Key 이외의 Index) 가 있을 경우 Utility 수행이나 Batch 작업 병렬 처리에 제약 사항이 발생할 수 있으므로 최소한의 Index 만 추가한다 . <= 3 Partition Table(1 억건 미만 ) Index 개수가 많을수록 성능 저하 <= 3 Insert,Update 가 빈번한 Table 필요한 만큼의 Index 추가 7 개 이상일 경우는 모델 검토 후 Table 분리하는 것을 권장함 <= 7 개 조회성 Table 비 고 Index 개수 Table 유형
  5. 5. 7. 파티션 테이블 <ul><li>파티션 테이블 개요 </li></ul><ul><li>Primary Key 를 기준으로 한 테이블을 여러 개의 물리적 Device 에 분산하여 I/O 부하 감소 </li></ul><ul><li>대량 데이터의 저장과 프로세스를 위해 적용함 ( 병렬처리 가능 ) </li></ul><ul><li>파티션 별로 Utility(UNLOAD, LOAD 등 ) 수행이 가능함 </li></ul><ul><li>파티션 개수 Limit: 1 ~ 254 개 (1 partition :64Gbyte) </li></ul><ul><li>테이블 분할을 하지 못할 경우 파티션 테이블을 사용한다 . </li></ul>파티션 테이블스페이스 파티션 인덱스 PART 1 PART 2 PART 3 PART 12 PART 1 VALUES PART 2 VALUES PART 3 VALUES PART 12 VALUES DASD VOLUME 1 DASD VOLUME 2 DASD VOLUME 3 DASD VOLUME 12 DASD VOLUME 13 DASD VOLUME 14 DASD VOLUME 15 DASD VOLUME 24 00100 ~ 00500 01000 ~ 01999 02000 ~ 02999 09000 ~ 09999 파티션 테이블
  6. 6. <ul><li>파티션 Key 구성 </li></ul>7. 파티션 테이블 <ul><li>History 성 파티션 Key - 데이터의 추가가 마지막 파티션에 집중되는 경우 ( 보통 일자가 Key 로 됨 ) - 파티션 Key 를 날짜로 구성하고 특정한 보존 기한이 지날 경우 이전 데이터를 삭제해야 할 경우 유용함 . - 일자로 파티션이 구성될 경우 Parallel Processing 에 제약이 발생한다 . - 병행 처리를 위한 파티션이라기 보다 대용량 데이터 처리를 위한 방안으로 고려 . </li></ul><ul><li>병행 처리를 위한 파티션 Key - 보통 회원 번호 , 주민 번호 , 카드 번호를 기준으로 파티션을 함 . - 병행 처리를 위해서는 데이터 처리가 각 파티션에서 균등하게 발생할 수 있도록 Key 를 구성한다 . </li></ul>
  7. 7. 8. DB2 Locking <ul><li>Locking 개요 </li></ul><ul><li>SIZE : Lock 이 걸리는 데이터 단위 - ROW, PAGE, TABLE, TABLESPACE </li></ul><ul><li>MODE : LOCK 의 종류 - X, S, U, IX, IS 등 </li></ul><ul><li>DURATION : Lock 이 걸리는 기간 </li></ul><ul><li>Lock MODE Compatibility </li></ul>PAGE / ROW LOCK <ul><li>S (SHARE) : Read Only , 다른 Process 에서 Read 가능 </li></ul><ul><li>X (Exclusive) : Update 성 , 다른 Process 가 Read 및 Update 못함 </li></ul><ul><li>U (Update) : Update 를 전제로 읽는 경우 , 다른 Process 에서 Read 는 가능하지 만 Update 를 전제로 한 READ (U-Lock) 은 불가능함 CURSOR 선언 시 ‘ FOR UPDATE OF’ 사용 </li></ul>X X X X X X O U X O O S X U S
  8. 8. <ul><li>Lock Duration(ISOLATION Level) </li></ul><ul><li>보통 BIND 시 ISOLATION 을 CS(CURSOR Stability) 로 준다 . </li></ul><ul><li>X- Lock 은 Commit 시에만 Release 된다 . </li></ul>8. DB2 Locking Cursor Stability Repeatable Read X Page5 COMMIT S FETCH(Page8) UPATE(Page5) S FETCH(Page2) S FETCH(Page1) Page8 Page4 Page1
  9. 9. 9. 채번 테이블 <ul><li>MAX 값을 이용한 채번 </li></ul><ul><li>Key 에 종속되어 있는 SEQUENCE 를 채번 할 경우 사용함 ( MAX + 1) </li></ul><ul><li>동시에 여러 개의 프로세스에서 같은 Key 에 대한 채번이 필요할 경우는 Lock 에 대한 고려가 필요함 . - SELECT 문은 공유 가능하므로 마지막 MAX 값을 동시에 채번할 수 있으므로 Dup 에 대한 Retry Logic 이 필요할 수 있음 - SELECT MAX(SEQ) FROM tbl WHERE ~ </li></ul><ul><li>Key 에 종속된 SEQUENCE 가 적을 경우 사용하도록 한다 . ( < 100 개 ) </li></ul><ul><li>Key 에 종속된 SEQUENCE 가 많을 경우 MAX 값을 찾기 위한 Overhead 가 발생한다 . </li></ul><ul><li>예 ) 회원 번호 + 결제일 + 상품코드 + SEQ </li></ul><ul><li>V7 의 One Fetch Index Scan 을 이용할 경우 좋은 성능을 얻을 수 있다 . </li></ul><ul><li>채번 테이블 사용 </li></ul><ul><li>One Fetch Index Scan 을 이용할 수 없고 Key 에 종속되어 있는 Key 값이 너무 많을 경우 KEY 값과 SEQ 만으로 되어 있는 채번 테이블을 생성한다 . </li></ul><ul><li>예 ) 지점별 입금 SEQUENCE 를 구할 경우 </li></ul><ul><li>“ 지점코드 + SEQ” 로 구성된 채번 테이블을 생성한다 . </li></ul><ul><li>BASE Table 에 Lock 문제가 많이 발생하여 MAX 값을 사용하는 것이 문제가 될 경우 생성한다 . </li></ul>
  10. 10. 9. 채번 테이블 <ul><li>One Fetch Index Scan </li></ul>SELECT MAX(MGT_N_B11) INTO :W-B990-SEQ FROM LCSD2B99.TB990 WHERE CUST_N_H11 = :TB990-CUST-N-H11 AND ACT_N_H17 = :TB990-ACT-N-H17 AND PMT_DUE_D_B11 = :TB990-PMT-DUE-D-B11 AND CHGT_CV_G32 = :TB990-CHGT-CV-G32 <ul><li>V5 까지는 상기와 같은 SQL 을 위해 CUST_N_H11, ACT_N, PMT_DUE_D_B11, CHGT_CV_G32, MGT_N_B11 DESC 로 Index 를 만들어야 만 Index One Fetch 로 Max 값을 가져올 수 있음 . </li></ul><ul><li>V7 부터는 Index 가 ASCENDING 으로 구성 되어 있어도 MAX 값을 Index One Fetch 로 가져 올 수 있음 . </li></ul><ul><li>Access Path 중 가장 성능이 좋음 </li></ul>Index Key .............. MGT_N_B11 CHGT_CV_G32 PMT_DUE_D_B11 ACT_N_H17 CUST_N_H11
  11. 11. 10. 기타 <ul><li>컬럼 분리 </li></ul><ul><li>컬럼값이 여러 Filed 의 조합으로 구성되어 있는 경우 조회에 필요한 Field 값은 컬럼으로 분리하여 관리한다 . - SQL 사용 시 Like 문 사용을 줄여 Index 사용의 효율성을 높인다 . </li></ul><ul><li>예 ) 상품코드 = 상품분류 + 세부상품코드 ( 11, 21, 31....) 조회 조건에 사용되는 상품코드는 주로 상품분류 ( 일시불 , 할부 , 현금서비스 ) 별로 조회하는 경우가 대부분임 . 이럴 경우 상품코드와 상품분류를 다른 컬럼으로 분리한다 . </li></ul><ul><li>보통 조회 시 SELECT ~ WHERE 회원번호 =: 회원번호 AND 상품코드 LIKE ‘1%’ 와 같이 사용함 </li></ul><ul><li>Scroll 을 위한 Index 순서 </li></ul><ul><li>SCROLL LOGIC 이란 화면에서 NEXT PAGE 를 Click 했을 경우 다음 화면의 처음 값을 가지고 다시 조회하는 Logic 을 말함 </li></ul><ul><li>멀티라인 조회를 위한 온라인 프로그램의 성능은 대부분 SCROLL LOGIC 의 구사에 좌우됨 </li></ul><ul><li>Scroll logic SQL </li></ul><ul><li>SELECT ~ FROM tbl WHERE ( A > :a) or ( A = :a AND B > :b) or ( A = :a AND B = :b AND C > :c) ORDER BY A, B, C OPTIMIZE FOR 1 ROW; </li></ul><ul><li>상기와 같은 SQL 문을 구사해야 될 경우가 많으면 ‘ A, B, C’ 의 Composite Index 를 구성한다 . </li></ul>
  12. 12. <ul><li>Scroll Logic 처리 방법 </li></ul><ul><li>CURSOR 를 OPEN 하는 시점에 데이터를 가져오는 경우 - 적절한 Index 가 구성이 되어 있지 않아 Cursor Open 시점에 WHERE PREDICATE 에 해당하는 모든 데이터를 Retrieve 하여 Temp Table 에 담아둠 - ORDER BY 의 순서가 INDEX 에 정의 되어 있는 것과 다른 경우 </li></ul><ul><li>CURSOR FETCH 시점에 데이터를 가져오는 경우 - Cursor 의 “ Order by” 에 해당하는 컬럼으로 Index 가 구성이 되어 있는 경우 - OPEN 시점에는 Cursor 를 Positioning 하는 일만하고 실제 Fetch 시 화면상에 보여줄 Record 만 Retrieve 함 - 온라인 상에서는 가능한 FETCH 시점에 데이터를 가져오게 적절한 Index 를 구성한다 . </li></ul>10. 기타
  13. 13. <ul><li>화면과 Index 관계 </li></ul><ul><li>화면 설계 시 주의 사항 - 검색 조건은 Index 에 해당하는 컬럼만 선택하도록 함 . - 한 테이블에 여러 개의 검색 조건을 하기 위해서는 여러 개의 Index 가 필요하므로 검색 조건은 최대한 Simple 하고 그룹별로 통일하는 것이 성능 문제와 사용자의 혼동을 막을 수 있다 . </li></ul><ul><li>주요 원장 테이블에 여러 검색 조건을 추가 해야 할 경우 - 원장성 파티션 테이블에 NPI(Non Partition Index) 가 Define 될 경우 Locking 문제와 성능에 악 영향을 줄 수 있다 . - 이러한 경우 원장성 파티션 테이블을 검색하기 위한 Index Table 을 만드는 것도 고려한다 . </li></ul>Table tbla( 원장성 파티션 테이블 ) / INDEX: A + B + C => 검색 조건이 A + B + C 이외에 F, A, B 로 검색이 필요할 경우 Table tblb => F + A + B 로 된 Index 를 tbla 에 추가하여도 되지만 tblb 라는 인덱스용 테이블을 생성할 수도 있다 . 10. 기타 F E D C B A C B A F

×