> 자료실 > News Letter
 
Download
News Letter
Site Link
XpertMon 뉴스레터 59호 - DB2 V9.7 이해하기
2010/01/28 14:37 15123

DB2 V9.7 이해하기

 

DB2 V8.2 2009430일부로 EOS(End Of Service)가 되었고, 현재 안정적으로 사용되고 있는 DB2 V9.1Fix Pack No.8까지 출시된 상태입니다. DB2 Engine 방식이 Process에서 Thread로 변경된 DB2 V9.5 20071214 GA된 이후 기능이 급격히 향상되고 있습니다.

 

현재는 DB2 V9.7 2009824일에 GA되었고, DB2 pureScale 20091211일에 GA되었습니다.

 

<그림1 : 현재까지의 DB2 Version GA EOS>



 

이번 호에서는 DB2 V9.7의 특징을 전반적으로 이해하고자 합니다.

 

대표적인 특징은 아래와 같습니다.

  1. Partitioned indexes (Global Indexes à Local Indexes)
  2. Read Only Standby for HADR (Standby Only à Read Only)
  3. Oracle PL/SQL compatibility
  4. Enhanced compression
  5. Statement Concentrator (New : Using Parameter Marker)
  6. Online Table Move (New)
  7. Scan Sharing (New)

 

이제, 하나하나의 특징을 간략하게 살펴보도록 하겠습니다.

 

1. Partitioned indexes

DB2 V9.5에서는 Global Index만을 지원하여 detach/attach Index-Rebuild에 많은 Cost가 발생하였습니다. 그러나, DB2 V9.7에서는 Local Index를 지원하게 되어 보다 빠른 데이터 Roll In & Roll Out, 필요한 PartitionReorg 가능 및 불필요한 Partition을 신속히 Detach 할 수 있게 되었습니다

 


<그림2 : V9.5 V9.7 Index 구성비교>


 

 

2. Read Only Standby for HADR (High Availability and Disaster Recovery)

 V9.5까지의 HADR 구조는 Primary – Standby 의 구조였다고 보면, V9.7 Fix Pack No.1이 적용되면서 Standby Server에 대한 Read-Only가 가능하게 되었습니다.

물론, 몇 가지 Parameter setting 은 필요합니다.

아래의 db2 registry variable setting 한 이후에야 Standby Server “Read-Only” 를 확인할 수 있습니다.

 

  


<그림3 : HARD with Reads on Standby>



 

만약, Primary Server에서 아래의 작업이 발생될 경우에는 Standby Server의 모든 Application 이 끊어지게 되어 있으므로 Standby Server를 원활히 사용하고자 한다면 해당 사항을 유념하여야 합니다.

 

  


3. Oracle PL/SQL compatibility

V9.7의 가장 큰 특징 중의 하나로 Oracle Migration시 특히 많이 사용되는 OracleROWNUM, DUAL, TRUNCATE, CONNECT BY 등의 Conversion이 완전히 구현되었다고 할 수 있습니다.

단순히 내부 DB2 Function 들을 조합한 형태라면 Conversion으로 인한 Cost가 높아지겠지만, 아래의 그림처럼 “PL/SQL Native Compiler” “Source Level에서의 Debugging”이 가능함으로 인해 Cost Performance에 대한 Issue를 없앨 수 있습니다. 실제 고객사이트에서는 96%이상의 PL/SQL을 그대로 사용하게 되었다고 합니다.

 

<그림4 : DB2 Engine 내에서 PL/SQL 처리흐름


만약, 해당 기능을 사용하기 위해서는 아래의 DB2 Registry Variable Setting이 완료된 이후에 가능합니다. 특정 Oracle의 기능만을 사용하고자 한다면 아래의 ‘ORA’ 대신 기능에 따른 ‘Bit Position’ 값을 넣어주면 가능합니다.

 

 

 

Bit Position

기능

Bit Position

기능

1 (0x01)

ROWNUM

7 (0x40)

DATE data type 1

2 (0x02)

DUAL

8 (0x80)

TRUNCATE TABLE

3 (0x04)

Outer join operator (+)

9 (0x100)

Character literals

4 (0x08)

CONNECT BY

10 (0x200)

Collection methods

5 (0x10)

NUMBER data type 1

11 (0x400)

Data dictionary-compatible views 1

6 (0x20)

VARCHAR2 data type 1

12 (0x800)

PL/SQL compilation 2

http://publib.boulder.ibm.com/infocenter/db2luw
/v9r7/topic/com.ibm.db2.luw.apdv.porting.doc/doc/
r0052867.html?resultof=%22%52%4f%57%4e%55%
4d%22%20%22%72%6f%77%6e%75%6d%22%20

 

 

4. Enhanced compression

기존 V8, V9.1, V9.5 DB2 System default 값만을 Compress하던 때보다 현저하게 향상되었습니다. V9.7의 경우, 이전에 제공되지 않던 INDEX, Temporary Table, LOB Compression이 현저히 좋아지므로 인해 Storage 절감에 많은 기여를 할 수 있게 되었습니다.

IBM의 비교자료에 따르면 Oracle Database보다 50% 빨라지고, SQL Server 보다 5배 빠르며 이에 트랜잭션용 시스템의 서버 비용 절감을 가져 왔다고 합니다.

 

<그림5 : Compress 기능개선과 Performance>


 

 

5. Statement Concentrator

아래의 그림처럼, Where절의 조건이 literal로 되어 있을 경우, DB2는 각각의 SQL compiling 하는 단계를 걸친 이후에야 실행이 가능합니다. 그러나, V9.7에서는 이런 LiteralParameter Marker로 처리하여 Compile 수를 줄여 실행하게끔 “Statement Concentrator”를 지원합니다.

<그림5 :  V9.7 Statement Concentrator>



 

위의 기능을 사용하기 위해서는 DB CFGSTMT_CONC를 아래와 같이 변경한 후 사용하여야 합니다. 해당 configuration variableOFF/LITERALS 두 가지의 값으로 update 가능합니다.


 


6. Online Table Move

V9.7에서는 손쉽게 Table online move 할 수 있는 기능이 추가되었습니다. “Online Table Move”Source table Target table move 시키는 동안 발생하는 transaction Staging Table 에 적재 후, Target Table에 적용한 후 자동 삭제되는 Flow을 가지고 있습니다.

 

 


만약, Online Table Move Fail이 날 경우는 아래의 Step을 진행해줘야 합니다.

l       실패 시 SYSTOOLS.ADMIN_MOVE_TABLE protocol table 에서 해당 table 상태를 확인한 적절한 Step을 진행해야 합니다.

      If the status of the procedure is INIT, use the INIT option.

      If the status of the procedure is COPY, use the COPY option.

      If the status of the procedure is REPLAY, use the REPLAY or SWAP option.

      If the status of the procedure is CLEANUP, use the CLEANUP option.

 

 

7. Scan Sharing

 이 기능은 Large table MDC Block Index Scan이나, Table Scan 등의 Cost가 높을 수 밖에 없는 작업에 대해 보완된 Feature로써, 아래와 같은 장점을 들 수 있습니다.

-        개선된 Concurrency

-        보다 빨라진 Query Response Time

-        증가된 Throughput

 

, 해당 기능은 Isolation Level RR이나 RS보다는 CS UR application에 적용할 것을 권장하고 있습니다.

 

 

 

<그림6 :  V9.7 Scan Sharing>



 

성능적인 측면에서, IBM의 보고내용에 따르면 MDC Block Index Scan Sharing의 경우는 평균 47% query 성능개선이 있었으며, 그 중 실행시간이 56%까지 좋아진 query도 있었다고 합니다.

 

 

 

 

 

 

이번 호에서는 간단히 V9.7에 대표적인 기능만을 언급하였습니다. 차후 기능들에 대한 내용이 추가되는 대로 자세한 내용으로 한번 더 찾아 뵙도록 하겠습니다.

목록 글쓰기 수정