728x90

$ db2 select current timestamp from sysibm.sysdummy1


1

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

2011-04-21-11.57.52.025165


  1 record(s) selected.



$ db2 values current time


1

--------

15:05:45


  1 record(s) selected.


$ db2 values current date


1

----------

10/22/2011


  1 record(s) selected.


$ db2 values current timestamp

1
--------------------------
2011-10-22-15.06.48.413881

  1 record(s) selected.

728x90
728x90

The DB2_COMPATIBILITY_VECTOR registry variable is used to enable one or more DB2® compatibility features introduced since DB2 Version 9.5.

These features ease the task of migrating applications written for other relational database vendors to DB2 Version 9.5 or later.

Important: Enable these features only if they are required for a specific compatibility purpose. If DB2 compatibility features are enabled, some SQL behavior is changed from what is documented in the SQL reference information. To determine the potential impacts on your SQL applications, see the documentation that is associated with each compatibility setting.
This DB2 registry variable is represented as a hexadecimal value, and each bit in the variable enables one of the DB2 compatibility features.
  • Operating systems: All
  • Default: NULL; Values: NULL or 00 to FFFF. To take full advantage of these DB2 compatibility features, set the value to ORA for Oracle applications and SYB for Sybase applications. These are the recommended settings.

Registry variable settings

Table 1. DB2_COMPATIBILITY_VECTOR values
Bit positionCompatibility featureDescription
1 (0x01)ROWNUMEnables the use of ROWNUM as a synonym for ROW_NUMBER() OVER(), and permits ROWNUM to appear in the WHERE clause of SQL statements.
2 (0x02)DUALResolves unqualified table references to 'DUAL' as SYSIBM.DUAL.
3 (0x04)Outer join operatorEnables support for the outer join operator (+).
4 (0x08)Hierarchical queriesEnables support for hierarchical queries using the CONNECT BY clause.
5 (0x10)NUMBER data type 1Enables the NUMBER data type and associated numeric processing.
6 (0x20)VARCHAR2 data type 1Enables the VARCHAR2 and NVARCHAR2 data types and associated character string processing.
7 (0x40)DATE data type 1Enables use of the DATE data type as TIMESTAMP(0), a combined date and time value.
8 (0x80)TRUNCATE TABLEEnables alternate semantics for the TRUNCATE statement, under which IMMEDIATE is an optional keyword that is assumed to be the default if not specified. An implicit commit operation is performed before the TRUNCATE statement executes if the TRUNCATE statement is not the first statement in the logical unit of work.
9 (0x100)Character literalsEnables the assignment of the CHAR or GRAPHIC data type (instead of the VARCHAR or VARGRAPHIC data type) to character and graphic string constants whose byte length is less than or equal to 254.
10 (0x200)Collection methodsEnables the use of methods to perform operations on arrays, such as first, last, next, and previous. Also enables the use of parentheses in place of square brackets in references to specific elements in an array; for example, array1(i) refers to elementi of array1.
11 (0x400)Data dictionary-compatible views 1Enables the creation of data dictionary-compatible views.
12 (0x800)PL/SQL compilation 2Enables the compilation and execution of PL/SQL statements and language elements.
13 (0x1000)Insensitive cursorEnables cursors defined WITH RETURN to be insensitive if the select-statement does not explicitly specify FOR UPDATE
14 (0x2000)INOUT parameterEnables the specification of DEFAULT for INOUT parameter declarations
17 (0x10000)SQL data access level enforcementEnables run-time routine SQL data access level enforcement
  1. Applicable only during database creation. Enabling or disabling this feature only affects subsequently created databases.
  2. See "Restrictions on PL/SQL support".

Usage

The DB2_COMPATIBILITY_VECTOR registry variable is set and updated using the db2set command. Set theDB2_COMPATIBILITY_VECTOR before creating your database:
  • To enable all of the supported Oracle compatibility features, set the registry variable to the value ORA (equivalent to the hexadecimal value 10FFF).
  • To enable all of the supported Sybase compatibility features, set the registry variable to the value SYB (equivalent to the hexadecimal value 3004).
When the DB2_COMPATIBILITY_VECTOR registry variable is set, all databases created should be created as UNICODE databases.

A new setting for the registry variable does not take effect until after the instance has been stopped and then restarted. Existing DB2 packages must be rebound for the change to take effect; packages that are not rebound explicitly will pick up the change on the next implicit rebind.

Example 1

This example sets the registry variable to enable all of the supported Oracle compatibility features:
db2set DB2_COMPATIBILITY_VECTOR=ORA
db2stop
db2start

Example 2

This example shows how to disable all compatibility features by resetting the DB2_COMPATIBILITY_VECTOR registry variable:
db2set DB2_COMPATIBILITY_VECTOR=
db2stop
db2start
Note that if a database has been created with the NUMBER data type or the VARCHAR2 data type enabled, use of the DATE data type as TIMESTAMP(0) enabled, or the creation of Oracle data dictionary-compatible views enabled, the database will still be enabled for these features after this db2set command executes.

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.apdv.porting.doc/doc/r0052867.html

728x90
728x90

view에서 참조하는 테이블이 없어도 뷰를 생성할 수 있다.


SQL> create or replace FORCE view <뷰이름> as select * from <테이블이름>;

Warning: View created with compilation errors.


SQL> select view_name from user_views where view_name='TEST';


VIEW_NAME

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

TEST


에러는 발생하지만 뷰는 생성되었다.


SQL> create table test123(a int);

Table created.


SQL> select * from test;


         A

----------

         1


테이블을 이후에 생성해도 뷰를 이용하여 데이터를 조회할 수 있다.


http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_8004.htm

728x90

'Oracle > oracle' 카테고리의 다른 글

Windows Vista, Server 2008에 10g 클라이언트 설치  (0) 2011.05.14
Static vs. Dynamic SQL  (0) 2011.04.21
Optimizing GROUP and ORDER BY  (0) 2011.04.13
오라클 캐릭터셋 확인  (0) 2011.03.08
SQL SERVER HSODBC 설정 방법  (0) 2010.06.29
728x90

이번에는 DB2의 고가용성 재해복구에 대해서 알아보도록 하겠습니다. 


DB2의 HADR은 로그 기반으로 동작하고, DB2 ESE 버전에서 단일 노드에 대해서만 동작합니다.

DB2 HADR을 구성하고 테스트하기 위하여 Linux머신 2대를 아래와 같이 HADR로 구성하였습니다.

서버 구성 

Blue01을 Primary로 구성하였고, Blue02를 Standby로 구성하였습니다. 

그리고 두서버에 모두 상대서버를 Alertnate Server로 구성하여 클라이언트가 접속이 끊겼을때 상대 서버를 찾을 

수 있도록 구성하였습니다. 

- Primary 서버 (Blue01)
 
 [db2hard@Blue01 ~]$ db2 list db directory

  System Database Directory
 
  Number of entries in the directory = 1
 
 Database 1 entry:
 
  Database alias                       = SAMPLE
  Database name                        = SAMPLE
  Local database directory             = /home/db2hard
  Database release level               = a.00
  Comment                              =
  Directory entry type                 = Indirect
  Catalog database partition number    = 0
  Alternate server hostname            = Blue02
  Alternate server port number         = 51000

 
 [db2hard@Blue01 ~]$ db2 get db cfg for sample |grep HADR
  HADR database role                                      = PRIMARY
  HADR local host name                  (HADR_LOCAL_HOST) = Blue01
  HADR local service name                (HADR_LOCAL_SVC) = hard_services
  HADR remote host name                (HADR_REMOTE_HOST) = Blue02
  HADR remote service name              (HADR_REMOTE_SVC) = hard_services
  HADR instance name of remote server  (HADR_REMOTE_INST) = db2hard
  HADR timeout value                       (HADR_TIMEOUT) = 120
  HADR log write synchronization mode     (HADR_SYNCMODE) = SYNC
 
 
 - Standby 서버 (Blue02)
 
 [db2hard@Blue02 ~]$ db2 list db directory

  System Database Directory
 
  Number of entries in the directory = 1
 
 Database 1 entry:
 
  Database alias                       = SAMPLE
  Database name                        = SAMPLE
  Local database directory             = /home/db2hard
  Database release level               = a.00
  Comment                              =
  Directory entry type                 = Indirect
  Catalog database partition number    = 0
  Alternate server hostname            = Blue01
  Alternate server port number         = 51000

 
 [db2hard@Blue02 ~]$ db2 get db cfg for sample |grep HADR
  HADR database role                                      = STANDBY
  HADR local host name                  (HADR_LOCAL_HOST) = Blue02
  HADR local service name                (HADR_LOCAL_SVC) = hard_services
  HADR remote host name                (HADR_REMOTE_HOST) = Blue01
  HADR remote service name              (HADR_REMOTE_SVC) = hard_services
  HADR instance name of remote server  (HADR_REMOTE_INST) = db2hard
  HADR timeout value                       (HADR_TIMEOUT) = 120
  HADR log write synchronization mode     (HADR_SYNCMODE) = SYNC

 위의 설정정보에서 확인한것 같이 Blue01과 Blue02가 Peer상태로 정상 동작하고 있는 것을 확인할 수 있습니다. 

클라이언트 연결 및 Query 실행 

클라이언트는 테스트의 편의를 위하여 CLP를 사용하였습니다. 
 
C:\Program Files\IBM\SQLLIB\BIN>db2 connect to hadr_sam user db2hard
db2hard의 현재 암호를 입력하십시오.
 
  데이터베이스 연결 정보
 
  데이터베이스 서버                        = DB2/LINUX 8.2.7
  SQL 권한 부여 ID                         = DB2HARD
  로컬 데이터베이스 별명                   = HADR_SAM
 
 
 C:\Program Files\IBM\SQLLIB\BIN>db2 "select * from employee fetch first 1 rows o
 nly"
 
 EMPNO  FIRSTNME     MIDINIT LASTNAME        WORKDEPT PHONENO HIREDATE   JOB
  EDLEVEL SEX BIRTHDATE  SALARY      BONUS       COMM
 ------ ------------ ------- --------------- -------- ------- ---------- --------
  ------- --- ---------- ----------- ----------- -----------
 000010 CHRISTINE    I       HAAS            A00      3978    1965-01-01 PRES
       18 F   1933-08-24    52750.00     1000.00     4220.00
 
   1 레코드가 선택됨.
   
   정상적으로 Primary서버(Blue01)에 정사적으로 로그인 되고, Query가 정상 수행 되었습니다. 

Primary서버(Blue01) 이상발생 

Primary서버(Blue01)에 이상을 발생시키기 위해 db2sysc 프로세스를 강제 종료합니다. 
 
 [db2hard@Blue01 ~]$ ps -ef |grep db2sysc
 db2hard  19260 19259  0 01:34 ?        00:00:00 db2sysc 0                                      
 db2hard   2574  1166  0 11:24 pts/0    00:00:00 grep db2sysc
 [db2hard@Blue01 ~]$ kill -9 19260
 
 Primary서버(Blue01) 이상 발생 클라이언트 동일 Query 실행시 계속 대기합니다. 
 
 C:\Program Files\IBM\SQLLIB\BIN>db2 "select * from employee fetch first 1 rows o
 nly"
 
 클라이언트 대기 상태 
 
Standby서버(Blue02) 상태 확인 및  인계작업 수행 

Standby서버(Blue02) 인계작업 수행전에 우선 Standby서버의 HADR상태를 확인합니다. 
 
 HADR Status
   Role                   = Standby
   State                  = Remote catchup pending
   Synchronization mode   = Sync
   Connection status      = Disconnected, 03/03/2007 11:25:40.214866
   Heartbeats missed      = 0
   Local host             = Blue02
   Local service          = hard_services
   Remote host            = Blue01
   Remote service         = hard_services
   Remote instance        = db2hard
   timeout(seconds)       = 120
   Primary log position(file, page, LSN) = S0000002.LOG, 37, 00000000017959D5
   Standby log position(file, page, LSN) = S0000002.LOG, 37, 00000000017959D5
   Log gap running average(bytes) = 0
   
  Standby서버(Blue02)의 상태는 현재 Primary서버(Blue01)과 연결이 끊어져서 현재 Remote catchup Pending 상태입니다. 
  
  
  Primary서버와 Standby서버가 연결이 종료되었을 경우는 TAKEOVER작업에 BY FORCE 옵션을 사용하여 인계작업을 수행합니다. 
  
 [db2hard@Blue02 ~]$ 
db2 "TAKEOVER HADR on DATABASE SAMPLE BY FORCE"
 DB20000I  The TAKEOVER HADR on DATABASE command completed successfully.
 
 정상적으로 TAKEOVER작업이 수행된 후에 클라이언트 Query 결과가 아래와 같이 출력됩니다. 
 
 C:\Program Files\IBM\SQLLIB\BIN>db2 "select * from employee fetch first 1 rows o
 nly"
 SQL30108N  연결이 실패했으나 다시 연결되었습니다. 호스트 이름 또는 IP 주소는
 "Blue02"이고 서비스 이름 또는 포트 번호는 "51000"입니다. 특수 레지스터는 다시
 시도되거나 시도되지 않을 수 있습니다(이유 코드 = "1").  SQLSTATE=08506

 
 위와 같이 결과가 출력되면 다시 동일 Query 수행시 Blue02서버로 접속이 연결되어 정상적으로 Query가 실행됩니다. 
 
 C:\Program Files\IBM\SQLLIB\BIN>db2 "select * from employee fetch first 1 rows o
 nly"
 
 EMPNO  FIRSTNME     MIDINIT LASTNAME        WORKDEPT PHONENO HIREDATE   JOB
  EDLEVEL SEX BIRTHDATE  SALARY      BONUS       COMM
 ------ ------------ ------- --------------- -------- ------- ---------- --------
  ------- --- ---------- ----------- ----------- -----------
 000010 CHRISTINE    I       HAAS            A00      3978    1965-01-01 PRES
       18 F   1933-08-24    52750.00     1000.00     4220.00
 
   1 레코드가 선택됨.
   
 그리고 Standby서버 역확을 수행했던 Blue02 서버에서 클라이언트의 연결을 확인할 수 있습니다. 
 
 [db2hard@Blue02 ~]$ db2 list applications

 Auth Id  Application    Appl.      Application Id                 DB       # of
          Name           Handle                                    Name    Agents
 -------- -------------- ---------- ------------------------------ -------- -----
 DB2HARD  db2bp.exe      844        C0A8018F.H60E.00BE83021856     SAMPLE   1   

마지막으로 Blue02서버의 HADR의 상태 변경을 확인하면 됩니다.

HADR Status
   Role                   = Primary
   State                  = Disconnected

   Synchronization mode   = Sync
   Connection status      = Disconnected, 03/03/2007 11:25:40.214866
   Heartbeats missed      = 0
   Local host             = Blue02
   Local service          = hard_services
   Remote host            = Blue01
   Remote service         = hard_services
   Remote instance        = db2hard
   timeout(seconds)       = 120
   Primary log position(file, page, LSN) = S0000002.LOG, 38, 0000000001796057
   Standby log position(file, page, LSN) = S0000000.LOG, 0, 0000000000000000
   Log gap running average(bytes) = 0
   
 Standby역활로 실행되었던 Blue02서버가 현재 Primary서버의 이상으로 인계작업을 수행하여 
 Primary역활로 변경된 것을 확인할 수 있으며 상태는 Disconnected입니다. 
 
 
     - 현재상태로 계속해서 시스템의 운영이 가능합니다.
       아래에 나오는 작업을 복구를 위한 작업입니다.
 
 
 
인계작업 완료후 복구 작업
 
 Blue01 서버에서 DB2 Instance를 다시 시작하고 HADR을 Standby로 시작합니다. 
 
 [db2hard@Blue01 ~]$ db2start
 03/03/2007 11:43:32     0   0   SQL1063N  DB2START processing was successful.
 SQL1063N  DB2START processing was successful.
 [db2hard@Blue01 ~]$ 
db2 "START HADR on DATABASE SAMPLE AS STANDBY"
 SQL1766W  The command completed successfully. However, LOGINDEXBUILD was not 
 enabled before HADR was started.  SQLSTATE=00000


 Primary 서버(Blue02) 상태 확인 
 
 HADR Status
   Role                   = Primary
   State                  = Peer

   Synchronization mode   = Sync
   Connection status      = Connected, 03/03/2007 11:45:02.582553
   Heartbeats missed      = 0
   Local host             = Blue02
   Local service          = hard_services
   Remote host            = Blue01
   Remote service         = hard_services
   Remote instance        = db2hard
   timeout(seconds)       = 120
   Primary log position(file, page, LSN) = S0000002.LOG, 38, 0000000001796057
   Standby log position(file, page, LSN) = S0000002.LOG, 38, 0000000001796057
   Log gap running average(bytes) = 51912
 
 Standby 서버(Blue01) 상태 확인 
 
 HADR Status
   Role                   = Standby
   State                  = Peer

   Synchronization mode   = Sync
   Connection status      = Connected, 03/03/2007 11:43:53.856276
   Heartbeats missed      = 0
   Local host             = Blue01
   Local service          = hard_services
   Remote host            = Blue02
   Remote service         = hard_services
   Remote instance        = db2hard
   timeout(seconds)       = 120
   Primary log position(file, page, LSN) = S0000002.LOG, 38, 0000000001796057
   Standby log position(file, page, LSN) = S0000002.LOG, 38, 0000000001796057
   Log gap running average(bytes) = 33156
   
   
 최초에 역활과 반대로 지금은 Blue02서버가 Primary 역활을 수행하고 있으며, Blue01서버가 Standby역확을 수행하고 있습니다. 그리고 상태도 Peer상태로 정상적으로 운영되고 있습니다. 
 
 
 현재 상태로 운여하다가 다시 Standby 서버(Blue01)에서 TAKEOVER 작업을 수행하여 원래의 구성으로 돌아갈 수 있습니다.

TAKEOVER 작업을 통한 역활 변경

 [db2hard@Blue01 ~]$ db2 "TAKEOVER HADR on DATABASE SAMPLE"
 DB20000I  The TAKEOVER HADR on DATABASE command completed successfully.
 
 
 Primary 서버(Blue01) 상태 확인 
 
 HADR Status
   Role                   = Primary
   State                  = Peer

   Synchronization mode   = Sync
   Connection status      = Connected, 03/03/2007 11:43:53.856276
   Heartbeats missed      = 0
  Local host             = Blue01
   Local service          = hard_services
   Remote host            = Blue02
   Remote service         = hard_services
   Remote instance        = db2hard
   timeout(seconds)       = 120
   Primary log position(file, page, LSN) = S0000002.LOG, 38, 00000000017966C9
   Standby log position(file, page, LSN) = S0000002.LOG, 38, 00000000017966C9
   Log gap running average(bytes) = 872

 Standby 서버(Blue02) 상태 확인 
 
 HADR Status
   Role                   = Standby
   State                  = Peer

   Synchronization mode   = Sync
   Connection status      = Connected, 03/03/2007 11:45:02.582553
   Heartbeats missed      = 0
   Local host             = Blue02
   Local service          = hard_services
   Remote host            = Blue01
   Remote service         = hard_services
   Remote instance        = db2hard
   timeout(seconds)       = 120
   Primary log position(file, page, LSN) = S0000002.LOG, 38, 00000000017966C9
   Standby log position(file, page, LSN) = S0000002.LOG, 38, 00000000017966C9
   Log gap running average(bytes) = 820
   
 처음 Test를 시작할 때의 상태로 복원 되었습니다. 
  
Client 연결확인 

 
[db2hard@Blue01 ~]$ db2 list applications

 Auth Id  Application    Appl.      Application Id                 DB       # of
          Name           Handle                                    Name    Agents
 -------- -------------- ---------- ------------------------------ -------- -----
 DB2HARD  db2bp.exe      19         C0A8018F.HC0E.00BE83023817     SAMPLE   1  

클라이언트 연결도 Blue01서버로 다시 연결된것을 확인할 수 있습니다. 

이상과 같이 DB2 HADR의 Primary서버의 문제발생시 Standby서버로의 인계작업 수행 및 복원 과정 그리고 

클라이언트의 연결 변경과정을 확인하여 보았습니다.

그래도 문제가 있죠.. ㅋㅋㅋ 자동으로 인계작업을 발생했으면 좋으련만 Standby서버는 Rollforward 상태로 

남아 있기 때문에 항상 TAKEOVER 작업을 수행해야만 접속이 가능하다는 문제가 있네요.

[db2hard@Blue02 ~]$ db2 get snapshot for database on sample

              Database Snapshot

Database name                              = SAMPLE
Database path                              = /home/db2hard/db2hard/NODE0000/SQL00001/
Input database alias                       = SAMPLE
Database status                            = Rollforward


그래도 문제 발생시 시스템 전체를 다시 시작하거나 또는 DB2 Instance 다시 시작등과 같이 오랜시간 동안의 작업을 대신하여 빠른 시간에 TAKEOVER작업을 수행할 수 있다는 장점과 Client연결을 Alertnate Server기능을 사용하여 유지하고클라이언트 사용자의 접속을 유지할 수 있다는 장점은 좋은것 같습니다.



http://halfork.tistory.com/entry/DB2-HADR-%EA%B3%A0%EA%B0%80%EC%9A%A9%EC%84%B1-%EC%9E%AC%ED%95%B4%EB%B3%B5%EA%B5%AC

728x90

'Db2 > Db2 reference' 카테고리의 다른 글

오늘 날짜 조회하기  (0) 2011.04.21
DB2_COMPATIBILITY_VECTOR registry variable  (0) 2011.04.21
파티션된 데이터베이스(DPF) 환경에서 데이터 로드  (0) 2011.04.16
db2 link  (0) 2011.04.07
[교육정리] transaction log  (0) 2011.03.17
728x90

IDS 11.7에 있는 Floating User 라이센스에 대한 설명 입니다


정확한 명칭은 Floating User Single Session Single Install (FUSSSI) 라이센스 입니다설치된 인포믹스 DB intall에 대한 최대 session수 만큼 구매해야하는 user 라이센스 입니다기존 concurrent session 라이센스와 크게 다르지 않은 것으로 판단 됩니다.

Rational Floating 
라이센스처럼 라이센스 센터에서 물리적으로 실시간 확인을 하는 것으로 보이지는 않습니다.

아래 링크는 Floating User Single Session Single Intall Concurrent Session 라이센스에 대한 원문 설명서 입니다.


1. Informix Dynamic Server 11.7 License Program (Floating User Single Session Single Install license
에 대한 설명)
http://www-03.ibm.com/software/sla/sladb.nsf/lilookup/1A073E1463FE4E82852577B9007601C1?opendocument&li_select=1EB66FFD8BB5E510852577B9007601AF


2. Informix Dynamic Server 11.5 License Program (Concurrent Session license
에 대한 설명)
http://www-03.ibm.com/software/sla/sladb.nsf/lilookup/439E79422D3677EF85257679004476D7?opendocument&li_select=F9B7C5C38363423C85257679004476B8


3. 
아울러 IDS 11.7 제품 비교가 되어 있는 페이지도 링크 보내 드립니다.
http://www.ibm.com/developerworks/data/library/techarticle/dm-0801doe/
728x90
728x90

다중 데이터베이스 파티션을 스캔하는 테이블을 걸쳐 컬럼 식별자 없는 ASCII(ASC) 및 컬럼 식별자가 있는 ASCII(DEL) 파일만을 파티션할 수 있습니다. PC/IXF 파일은 분배할 수 없습니다. PC/IXF 파일을 다중 데이터베이스 파티션에 걸쳐 있는 테이블로 로드하기 위해 먼저 DB2_PARTITIONEDLOAD_DEFAULT=NO 환경 변수를 설정한 후 LOAD_ONLY_VERIFY_PART 모드를 사용하여 단일 데이터베이스 파티션에 있는 테이블로 파일을 로드할 수 있습니다. 그런 다음, CURSOR 파일 유형을 사용하여 로드 조작을 수행하여 데이터를 다중 데이터베이스 파티션을 통해 분산된 테이블로 이동할 수 있습니다. 또한 LOAD_ONLY_VERIFY_PART 모드에서 로드 조작을 사용하여 다중 데이터베이스 파티션을 통해 분산된 테이블로 PC/IXF 파일을 로드할 수도 있습니다.


http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r0004613.htm

728x90

'Db2 > Db2 reference' 카테고리의 다른 글

DB2_COMPATIBILITY_VECTOR registry variable  (0) 2011.04.21
HADR - 고가용성 재해복구  (0) 2011.04.18
db2 link  (0) 2011.04.07
[교육정리] transaction log  (0) 2011.03.17
[교육정리] 데이터 이관  (0) 2011.03.17
728x90

 

오라클 10.2를 시작할때, Group by와 Order by를 동일한 칼럼에 결합하여 사용할때, 성능과 관련하여 괄목할 만한 성능 절감을 발견하게 될 것이다. 

오라클 10.2에서는 Hash 기반의 Group By에 대해서 소개했다. 이전 Group by를 수행하면 연관된 칼럼의 소팅을 포함해서 처리했었고, 이러한 수행결과를 모아서 결과로 반환했다. Hash Group By 메소드는 소팅 없이 이러한 결과를 생성한다. 즉, 이 처리방식은 Sort-Based Group by보다 항상 나은 성능을 발휘한다. 불행하게도 Order By 절을 동일 칼럼에 Group By절과 함께 사용한다면 Sort-Based Group by로 변경하며, 응답속도는 떨어질 것이다. 그러나 요청한 순서대로 데이터를 획득하고 싶다면 Hash-Based Group by를 이용하면 조금 더 이점은 있다.

 

예를 들어 다음 단순한 샘플 구문을 확인해보자.

 



10.2 이전에서는 SORT GROUP BY 오퍼레이션을 이용하여 수행하게 된다.

 

 

 

10.2 버젼 이후부터는 HASH GROUP BY를 수행하는것을 확인할 수 있다.

 



Alex Gorbachev  noted에 의하면 새로운 GROUP BY 는 이전 버젼과 같이 수행할 수 있도록(11.1.0.7 혹은 10.2.0.4 버젼 이전 오라클을 말한다.) 수정할 수있음을 가르쳐 준다. 다음 파라미터인 _GBY_HASH_AGGREGATION_ENABLED 를 FALSE로 바꾸도록 설정하면 된다. 아래 예와 같이 OPT_PARAM 힌트를 이용하여 개별 SQL의 설정을 바꿔 보자. 혹은 ALTER SESSION이나 ALTER SYSTEM을 변경하여 세션이나 인스턴스 레벨로 동작하게 할 수 있다.
 

 

기억해야할 것은 GROUP BY의 결과가 정렬되어 나온다고 생각하면 안된다는 것이다. 10.2 버젼의 GROUP BY는 보통 정렬된 GROUP BY를 이용했고, 필수적으로 함께 ORDER BY 절이 추가 되었었다. 10.2에서는 쿼리의 결과가 갑자기 랜덤한 순서로 나타나는것을 보고 아마 깜짝 놀랐을 수 있다. Tom Kyte는 다음과 같이 이야기 하고 있다. : "기본 원칙은 결코 부분적인 정렬에 대한 다른 영향은 없을 것이다. 만약 정렬된 group 결과를 획득하고 싶다면 ORDER BY절을 항상 사용해야 한다."

 

일반적으로 말해서 새로운 HASH GROUP BY는 과거의 소트 방법보다 훨씬 향상된 결과를 가져온다. 아래에서 보는것과 같이 GROUP BY 알고리즘을 2백 50만건 로가 있는 샘플 데이터를 그룹바이 하여 20만 로의 통합된 로가 나온다면 수행결과 차이는 다음 그림과 같이 나타난다.



물론 결과가 다르게 나올수 있지만 HASH GROUP BY의 선능이 SORT GROUP BY 보다 우수하다는 것을 보게 될 것이다.

 

불행하게도 오라클은 몇몇 환경에서 HASH GROUP BY를 사용하지 않을 것이다. 공평하게 동일한 칼럼에 GROUP BY와 ORDER BY를 동시에 사용한경우에 그렇게 동작하며, 임의의 순서로 통합된 결과가 보이지 않을 것이다. 

 

오라클은 SORT GROUP BY를 이용할때, 그룹핑된 결과에 사이트 이펙트로 소트를 수행한다. 그래서 아래 예와 같이 SORT가 오직 한번만 일어나며, 결과적으로 GROUP BY와 ORDER BY를 모두 동시에 사용한 결과가 나타나게 된다. (주의할 것은 여기서는 HASH GROUP BY를 OPT_PARAM 힌트를 이용하여 기능을 꺼둔상태라는 것이다.)

 

 

상단의 플랜은 10.2 이전에서 주로 보이는 결과이며, HASH GROUP BY가 릴리즈되기 이전에 사용된 것이다.

 

그러나 11g나 10.2에서는 오라클은 여전히 SORT GROUP BY를 선택할 것이라는 것을 알 수 있다.

 

 

 

여기에 중요한 포인트가 있다.

 

만약 GROUP BY와 ORDER BY를 동일한 칼럼에 혼합해서 사용할경우,
오라클은 HASH GROUP BY옵션을 사용하지 않을것이다.

 

추측건데 옵티마이저의 생각은 그룹을 수행하는 동안 SORT GROUP BY를 수행하는 것이다. GROUP BY와 마찬가지로 ORDER BY 요청을 수행할때 SORT GROUP BY는 가장 좋은 방법인 것이다. 그러나 로직에는 중요한 하자가 있다. 보통 ORDER BY를 위한 입력은 GROUP BY의 입력보다 작은 로가 입력이 된다. 상단의 예에서도 GROUP BY는 ORDER BY가 20만건을 처리하는 동안, 2백 50만건이 처리되고 있다. 이것은 비싼 GROUP BY를 수행하여 상대적으로 싼 ORDER BY에 입력으로 이용하는것은 의미상 문제가 있는 반 옵디마이징이다.

 

그래서 오라클에서 ORDER BY를 해야하는 상황에서 강제적으로 HASH GROUP BY를 수행하도록 하면 어떨까? 하는것이 핵심이다. 그래서 오라클이 HASH GROUP BY를 수행할 수 있도록 서브쿼리에 GROUP BY를 수행하도록 만들었다. 그리고 외부 쿼리에서 ORDER BY를 수행할때 NO_MERGE 힌트를 지정하여, 외부 쿼리가 내부 서브쿼리에 통합되지 않도록 지정했다.
결과적으로 플랜을 보면, HASH GROUP BY를 수행하고, 그 결과를 SORT ORDER BY를 타도록 재설정 되었다.

 

 

 

생각하는것과 같이 상단의 내용은 HASH GROUP BY와 SORT ORDER BY를 함께 사용하여 SORT GROUP BY보다 훨씬 나은 수행을 하도록 하고 있다. 그러나 기억해야할 것은 SORT ORDER BY는 그룹된 결과를 소트한다는 것을 꼭 확인해야한다는 것이다. 즉 예제에서는 20만개의 로를 소트하는 것이고, 이것은 2백 50만개의 HASH GROUP BY를 수행한 결과로 처리한다는 것이다. 그래서 GROUP BY의 최적화는 중요함이 작은 두번째 소트처리를 피하는것 보다 더 중요한 사항이 되기도 한다.

 

 


이것은 2개의 성능을 비교한 결과를 보여준다.
응답 시간이 2/3으로 획기적으로 줄어든 것을 확인할 수 있다.

 

결론

GROUP BY를 ORDER BY와 동일한 칼럼에 결합해서 적용할때에는 오라클 옵티마이저는 더 효과적인 HASH GROUP BY를 사용하지 않고, SORT GROUP BY를 수행한다. SORT ORDER BY 계획을 피하기 위해서 SORT GROUP BY를 수행한 것이다. 그러나 성능은 형편 없다는것을 확인 할 수 있다.

 

더 나은 결과를 위해서 GROUP BY를 인라인 뷰에 작성하고, 외부 쿼리에서 ORDER BY를 수행하도록 하자.
여기서 두개의 쿼리가 머지되어 작동하지 않도록 NO_MERGE 힌트를 부여하는것에 주목하자.

728x90

'Oracle > oracle' 카테고리의 다른 글

Static vs. Dynamic SQL  (0) 2011.04.21
베이스 테이블 없이 VIEW 강제로 생성하기  (0) 2011.04.21
오라클 캐릭터셋 확인  (0) 2011.03.08
SQL SERVER HSODBC 설정 방법  (0) 2010.06.29
Oracle 11g - ADRCI : IPS  (0) 2010.05.20
728x90

DB2 Fix Packs by version for DB2 for Linux, UNIX and Windows

https://www-304.ibm.com/support/docview.wss?uid=swg27007053


Chat with the Lab

http://www.ibm.com/developerworks/wikis/display/DB2/Chat+with+the+Lab


Collecting data: Read first for DB2 for Linux, UNIX, and Windows products


DB2 FAQ - Frequently Asked Questions about DB2 LUW

http://www-01.ibm.com/support/docview.wss?uid=swg21298716


DB2 FAQ: Frequently Asked Questions about Application Development with DB2 LUW

http://www-01.ibm.com/support/docview.wss?uid=swg21497134


Featured documents for DB2 for Linux, UNIX and Windows

http://www-01.ibm.com/support/docview.wss?uid=swg27006816


DB2 JDBC Driver Versions

http://www-01.ibm.com/support/docview.wss?uid=swg21363866&myns=swgimgmt&mynp=OCSSSNY3&mynp=OCSSEPGG&mynp=OCSSEPDU&mync=R


Download Fix Packs by version for IBM Data Server Client Packages

http://www-01.ibm.com/support/docview.wss?uid=swg27016878


개인 블로그

http://in0de.tistory.com/

http://blog.naver.com/nzisu

http://hermestop.tistory.com


News and information from the DB2 LUW Technical support team

https://www.ibm.com/developerworks/mydeveloperworks/blogs/db2luwtechsupport/tags/mustgather?lang=ko

728x90
728x90

Integrated Data Management 정보 센터

http://publib.boulder.ibm.com/infocenter/idm/docv3/index.jsp?topic=/com.ibm.datatools.perfmgmt.overview.doc/topics/helpindex_opm.html


IBM Optim High Performance Unload for DB2 for Linux , UNIX , and Windows V4.2 provides a high speed way to unload data from DB2

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&supplier=897&letternum=ENUS210-354


Collecting data for IBM® Optim™ solution

https://www-304.ibm.com/support/docview.wss?uid=swg21409349

728x90
728x90

11.50.xC6 버전에서 추가된 기능


테이블 분할 변경 시 트랜잭션 강제 아웃 >> 일정 시간 지난 후, 자동으로 Exclusive Lock 획득

로깅 데이터베이스에서 ALTER FRAGMENT on TABLE 조작을 실행할 때 서버가 테이블에서 로크를 보유하거나 열려 있는 트랜잭션을 강제 아웃시킬 수 있도록 설정할 수 있습니다. 하루 24시간 실행되는 사용 중인 시스템에서 이를 실행할 수 있으며, 분할을 변경하기 전에 세션이 닫힐 때까지 기다리지 않아도 됩니다. 

서버가 트랜잭션을 강제 아웃시킬 수 있도록 설정하면 이 서버는 다른 사용자의 트랜잭션을 롤백합니다. 또한 ALTER FRAGMENT on TABLE 조작을 수행하는 세션이 롤백하는 동안 유지 커서를 닫습니다.

전제조건:

  • informix 사용자이거나 데이터베이스에서 DBA 권한이 있어야 합니다.
  • 테이블이 로깅 데이터베이스에 있어야 합니다.

테이블 분할을 변경할 때 트랜잭션을 강제 아웃시키는 방법:

  1. SET ENVIRONMENT문의 FORCE_DDL_EXEC 환경 옵션을 다음 값 중 하나로 설정하십시오.
    • ALTER FRAGMENT on TABLE문이 발행되는 경우 'on''on'또는 '1'을 사용하여 서버가 테이블에서 로크 및 배타적 액세스를 확보할 때까지 해당 테이블에서 로크를 보유하거나 열려 있는 트랜잭션을 강제 아웃시킬 수 있습니다.
    • 양수는 시간(초)을 나타냅니다. 숫자 값을 사용하여 서버는 테이블에서 배타적 액세스 및 배타적 로크를 확보할 때까지 또는 지정된 시간 제한이 발생할 때까지 트랜잭션을 강제 아웃시킬 수 있습니다. 서버가 지정된 시간에 따라 트랜잭션을 강제 아웃시킬 수 없는 경우, 서버는 트랜잭션 강제 아웃을 중지합니다.
    예를 들어, ALTER FRAGMENT on TABLE문이 발행될 때 FORCE_DDL_EXEC 환경 옵션이 100초동안 작동되도록 설정하려면 다음을 지정하십시오.
    SET ENVIRONMENT FORCE_DDL_EXEC '100';
  2. 트랜잭션을 강제 아웃시키기 전에 서버가 지정된 시간동안 기다리도록 하려면 로크 모드를 대기로 설정하십시오.
    예를 들어, 20초동안 대기하도록 로크 모드를 설정하려면 다음을 지정하십시오.
    SET LOCK MODE TO WAIT 20;

    자세한 정보는 로크 모드를 대기로 설정의 내용을 참조하십시오.

  3. 예를 들어, 분할을 첨부, 분리, 수정, 추가 또는 삭제하려면 ALTER FRAGMENT on TABLE문을 실행하십시오.

FORCE_DDL_EXEC 환경 옵션을 사용하여 ALTER FRAGMENT on TABLE 조작을 완료한 후 FORCE_DDL_EXEC 환경 옵션을 설정 해제할 수 있습니다. 예를 들어, 다음을 지정합니다.

SET ENVIRONMENT FORCE_DDL_EXEC 'OFF'

자세한 정보는 IBM Informix SQL 안내: 구문에서 FORCE_DDL_EXEC 환경 옵션에 대한 주제를 참조하십시오.


http://publib.boulder.ibm.com/infocenter/idshelp/v117/index.jsp?topic=/com.ibm.perf.doc/ids_prf_760.htm

http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.gsg.doc/ids_rel_241.htm&resultof=%22force_ddl_exec%22%20

http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.sqls.doc/ids_sqs_2072.htm&resultof=%22force_ddl_exec%22%20


728x90

+ Recent posts