'DB2'에 해당되는 글 4건

  1. 2008.12.09 DB2에서 com.ibm.db2.jcc.b.oh: [ibm][db2][jcc][102][10040] 발생한 경우 by 지영아빠
  2. 2008.10.27 DB2 UDB의 Locking 매커니즘과 동시성 제어 by 지영아빠
  3. 2008.10.21 DB2 setObject 문제 by 지영아빠
  4. 2007.08.01 적응 by 지영아빠

DB2에서 jdbc를 이용해서 batch를 이용하다 보면, 다음과 같은 에러가 발생할 경우가 있습니다. 이때에는 코드상에 getNextException을 전부 찍어줘야 문제의 원인을 찾을 수 있습니다.


-------------------------    다      음 ------------------

com.ibm.db2.jcc.b.oh: [ibm][db2][jcc][102][10040] atomic 일괄처리에 실패했습니다일괄처리가 제출되었지만 각 일괄처리 구성원에서 최소 한 개의 예외가 발생했습니다.

getNextException()을 사용하여 특정 일괄처리 요소에 대한 예외를 검색하십시오.

           at com.ibm.db2.jcc.b.p.a(p.java:411)

           at com.ibm.db2.jcc.b.jg.c(jg.java:2736)

           at com.ibm.db2.jcc.b.jg.b(jg.java:2567)

           at com.ibm.db2.jcc.b.jg.executeBatch(jg.java:1450)

           at com.xxx.common.db.util.DBBatchUtils.process(DBBatchUtils.java:42)

           at com.xxx.common.db.data.mapper.DBDirectAccessMapperImpl.insert(DBDirectAccessMapperImpl.java:270)

           at com.xxx.common.db.data.mapper.DBFailOverMapperImpl.insert(DBFailOverMapperImpl.java:148)

           at com.xxx.common.db.data.mapper.AbstractMapper.insert(AbstractMapper.java:384)

           ... 61 more

 

Exception 한글 번역 :

atomic 일괄처리에 실패했습니다일괄처리가 제출되었지만 각 일괄처리 구성원에서 최소 한 개의 예외가 발생했습니다.

getNextException()을 사용하여 특정 일괄처리 요소에 대한 예외를 검색하십시오.

 

Exception 영문 원본 :

Non-atomic batch failure. The batch was submitted, but at least one exception occurred on an individual member of the batch.
Use getNextException() to retrieve the exceptions for specific batched elements.

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


이런 경우에는 getNextException()을 통해서 sqlexception을 처리해 줘야 정확한 원인을 알 수 있습니다. 

아래와 같이 작성하면 해결할 수 있습니다.

try  {
   conn.executeBatch ();

} catch (SQLException e) {

       while (e != null) {

             e.printStackTrace();

             e = e.getNextException();

       }

}

프로그래밍에 조금이나마 도움이 되기를..


저작자 표시
신고
Posted by 지영아빠
출처: KDUG- DB2 UDB의 Locking 매커니즘과 동시성 제어: Part 1 – Lock escalation
KDUG- DB2 UDB의 Locking 매커니즘과 동시성 제어: Part 2 – Lock Mode와 Lock 호환성 테스트
KDUG- DB2 UDB의 Locking 매커니즘과 동시성 제어: Part 3 – 레지스트리 변수 및 Case별 테스트

대규모
동시 트랜잭션이 일반적인 IT 환경에서, DBMS Locking 메커니즘과 동시성 제어는 데이터베이스의 성능과 직결되어있다고 해도 과언이 아닐 것이다. 기사에서는 DB2 UDB Locking 메커니즘과 동시성 제어 방식을 테스트를 통해 살펴봄으로써, DB2 UDB 발생 원인 분석의 효율성과 동시성 향상을 도모하고자 한다.

 

기사의 내용은 DB2 UDB 8.2.3 이용하여 테스트한 결과를 기반으로 작성하였으며, 다음과 같은 순서로 DB2 UDB 내부 동작원리를 파악해볼 것이다.

1. DB2 지원하는 Isolation level

2. DB2 UDB에서는 SELECT 시에도 대기가 발생할까?

3. Lock escalation이란?

4. DB2 UDB Lock Mode 이해

5. 동시성 향상을 위한 DB2 레지스트리 변수 Case 테스트

 

1. DB2 UDB 지원하는 Isolation level

DB2 UDB에서는 ANSI SQL 표준으로 정의된 4가지 Isolation level 모두 지원한다. ANSI SQL 표준의 4가지 Isolation level Read Uncommitted, Read Committed, Repeatable Read, Serializable이며, DB2 UDB에서는 각각의 Isolation level UR (Uncommitted Read), CS (Cursor Stability), RS (Read Stability), RR (Repeatable Read) 지원하고 있다(4개의 Isolation level 대한 설명은 [ 1.1] 기술하였다). DB2 UDB 이러한 4개의 Isolation level 제공하는 목적은, 특정 트랜잭션 별로 자신에게 필요한 수준의 Isolation level 선택적으로 사용하게 함으로써, 트랜잭션의 동시성을 높이는 것이다. [ 1.2]에서는 DB2 UDB에서 제공하는 Isolation level Isolation level에서 허용하는 이상현상을 보여준다.

[ 1.1] DB2 UDB에서 제공하는 Isolation level

DB2 UDB Isolation level

UR (Uncommitted Read)

Uncommitted Read “Dirty Read” 라고도 불리며, DB2 UDB 에서 제공하는 가장 낮은 Isolation level이다. 이름에서도 있듯이, 현재 레코드가 변경 (, COMMIT 또는 ROLLBACK으로 트랜잭션이 종료되지 않은 상태)이라도, 해당 레코드가 조건에 만족하면 리턴 한다. Uncommitted Read 다른 트랜잭션의 락을 릴리즈 때까지 대기하지 않으므로, 가장 높은 동시성을 제공하지만, 가장 낮은 데이터 일관성을 제공하므로, 일반적으로 READ ONLY 테이블을 조회할 사용한다.

CS (Cursor Stability)

Cursor Stability DB2 UDB 기본설정 값이며, 현재 커서가 위치한 레코드에 대해서 락을 건다. 해당 레코드에 대한 락은 다음 레코드를 페치(fetch) 하기 , 또는 UOW 종료될 때까지 유지된다. UOW COMMIT 또는 ROLLBACK명령문을 수행하면 종료된다. Cursor Stability 항상 커밋된 레코드만을 읽으며, 만일 커서가 가리키는 레코드에 락이 걸려있다면, 해당 쿼리는 대기 상태에 빠진다. 또한, 현재 커서가 위치한 레코드에는 락이 걸려있으므로, 다른 트랜잭션에서 해당 레코드에 대한 변경작업을 수행할 없게 된다. 커밋된 레코드만을 읽으면서, 동시성을 극대화시키려면, CS Isolation level 사용하여야 한다.

RS (Read Stability)

Read Stability UOW 단위 안에서, result set 해당되는 모든 레코드에 대해 락을 획득한다. 예를 들어 EMP 테이블에서 DEPTNO=10 조건을 만족하는 레코드가 3건이라면, 3건의 레코드에 대해 락을 획득하게 된다. Result set 해당되는 레코드에 대해 락을 획득하므로, 다른 트랜잭션에서 EMP 테이블에 DEPTNO=10 레코드를 입력하는 것이 가능하다(, phantom reads 발생이 가능하다). Read Stability 역시 항상 커밋된 레코드만을 읽게 되며, 다른 트랜잭션에서 해당 result set 대한 변경작업을 수행할 없다. 

RR (Repeatable Read)

Repeatable Read DB2 UDB에서 제공하는 가장 높은 Isolation level이다. Repeatable Read UOW 단위 안에서, 커서에서 참조하는 모든 레코드에 대해 락을 획득한다. , Read Stability 예에서는 다른 트랜잭션에서 DEPTNO=10 레코드를 입력하는 것이 가능했지만, Repeatable Read에서는 불가능하다(, phantom reads 발생을 막을 있다). 이러한 이유로 Repeatable Read 설정할 경우에 쿼리 옵티마이저는 LOCKLIST MAXLOCKS 같은 파라미터 설정을 고려하여, 레코드 단위가 아닌 테이블 레벨에 락을 획득하는 방식을 사용하기도 한다. Repeatable Read 역시 항상 커밋된 레코드만을 읽게 되며, 다른 트랜잭션에서 해당 커서에서 참조하는 레코드들에 대한 변경작업을 수행할 없다.

[ 1.2] DB2 UDB에서 제공하는 Isolation level Isolation level에서 허용하는 이상현상

DB2 UDB Isolation level

Lost Updates

Dirty Reads

Non-Repeatable Reads

Phantom Reads

UR (Uncommitted Read)

N

Y

Y

Y

CS (Cursor Stability)

N

N

Y

Y

RS (Read Stability)

N

N

N

Y

RR (Repeatable Read)

N

N

N

N

Isolation level 따라 발생할 있는 이상현상은 Lost Updates, Dirty Reads, Non-Repeatable Reads, Phantom Reads이다. File System 달리, 모든 사용 DBMS에서는 Dirty Write 허용되지 않으므로, Lost Updates 현상은 발생하지 않는다. 또한 Dirty Reads 그대로 언커밋된 레코드를 읽는 것을 의미한다. 따라서, 조금 생소한 Non-Repeatable Reads Phantom Reads 예를 들어 설명하기로 한다.

) EMP 테이블에는 다음과 같은 레코드가 저장되어있다.

EMPNO

DEPTNO

SAL

1

10

100

2

10

100

3

10

100

 

1. Non-Repeatable Reads

Transaction 1

Transaction 2

SELECT SAL FROM EMP WHERE EMPNO=1

Result: 100

 

 

UPDATE EMP SET SAL=200 WHERE EMPNO=1;

COMMIT;

SELECT SAL FROM EMP WHERE EMPNO=1

Result: 200

 

Non-Repeatable Reads 위의 예처럼, 하나의 UOW 안에서 동일한 레코드를 2 이상 조회하는 경우에, 다른 트랜잭션에서 해당 레코드를 변경함으로 인해, 조회 시마다 결과가 다르게 나타나는 현상이다. 이러한 이상현상을 해결하기 위해서는 쿼리의 result set 해당되는 레코드에 로우 레벨의 락을 설정하는 RS (Read Stability) Isolation level 사용하면 된다.

 

2. Phantom reads

Transaction 1

Transaction 2

SELECT SUM(SAL) FROM EMP WHERE DEPTNO=10

Result: 300

 

 

INSERT INTO EMP VALUES (4,10,200);

COMMIT;

SELECT SUM(SAL) FROM EMP WHERE DEPTNO=10

Result: 500

 

Phantom Reads 기존 수행한 쿼리에 해당되는 레코드들에 대한 변경이 아닌, 신규로 삽입된 레코드에 의해 쿼리 결과가 다르게 나타나는 현상을 의미한다. 이러한 이상 현상을 해결하기 위해서는, 커서가 참조하는 모든 레코드에 대해 락을 설정하는 RR (Repeatable Read) Isolation level 사용하면 된다.

 

2. DB2 UDB에서는 SELECT 시에도 대기가 발생할까?

DB2 UDB CS (Cursor Stability) Isolation level부터는, 현재 변경이 진행중인 레코드를 페치(fetch) 경우에 대기 현상이 발생한다. 또한 현재 커서가 위치한 레코드에 대해서, 다른 트랜잭션에서 변경을 시도할 경우에도 대기가 발생하게 된다. 다시 말하면 WRITE READ 블로킹하고, READ WRITE 블로킹하게 된다. 오라클에 익숙한 사용자라면, 이러한 현상에 대해서, 의아하게 생각할 것이다. 하지만, ANSI-SQL 표준에 의하면, 이러한 현상은 당연한 것이라 있다. 왜냐면, CS (Cursor Stability) Isolation level부터는 SELECT 시에도 레코드에 로우 레벨 락을 설정함으로써, Isolation 보장하기 때문이다. 다만, 오라클에서는 언두 세그먼트(Undo Segment) 이용한 MVCC (Multi-Version Concurrency Control) 기법을 이용하여, WRITE READ간의 블로킹 현상을 방지한 것이다. 현재 MVCC 지원하는 상용 DBMS ORACLE, MS-SQL 2005, ALTIBASE 정도이다. MVCC 지원한다는 것이 트랜잭션의 동시성을 높일 있다는 장점은 있으나, 언두 블록 I/O, CR Copy 오퍼레이션, CR 블록 관리와 같은 부가적인 작업이 필요하다는 것도 간과해서는 안될 부분이다.

 

3. Lock escalation이란?

Lock escalation이란 로우 레벨 락이 테이블 락으로 전이되는 현상을 의미한다. Lock escalation DB2 UDB 같이 정보를 메모리상에서 관리하는 DBMS에서는 공통적으로 발생할 있는 현상이다. , 한정된 메모리 공간에서 정보를 관리함에 따라, 정보를 관리하는 메모리 공간이 부족할 경우, 필연적으로 Lock escalation 발생하게 되는 것이다. 일반적으로 Lock escalation 발생할 경우, 트랜잭션의 동시성은 급격히 감소하여, 전반적인 성능 문제를 유발하게 된다. 따라서 DB2 UDB에서 Lock escalation 발생하는 경우와 Lock escalation 발생 여부를 감지하는 방법에 대해서 설명하고자 한다. DB2 UDB에서 Lock escalation 관련된 DB Configuration 파라미터는 LOCKLIST MAXLOCKS 이다 

LOCKLIST

정보를 관리하는 메모리 공간의 크기를 지정하는 파라미터이다. LOCKLIST 크기를 증가하는 것은 동적으로 가능하지만, LOCKLIST 크기를 감소시키려면 DB 재기동해야 한다. 해당 파라미터의 단위는 4KB이다.

MAXLOCKS

하나의 응용프로그램에서 획득할 있는 정보의 최대 크기를, LOCKLIST 대한 백분율로 나타내는 파라미터이다. 기본설정 값은 10% 이다. 말은 LOCKLIST 10% 공간까지 하나의 응용프로그램에서 사용이 가능하며, 비율을 넘기는 시점에 로우 레벨 락이 테이블 레벨 락으로 Lock escalation 발생하게 된다.

 

DB2 UDB에서 Lock escalation 발생하는 경우는 크게 2가지로 구분할 있다.

1. 하나의 응용프로그램이 MAXLOCKS 비율이상으로 락을 획득한 경우

2. LOCKLIST 정의된 메모리 공간에 이상의 정보를 저장할 없을 경우이다.

중에서 1번에 대해서 테스트를 통해 Lock escalation 동작원리를 살펴보도록 하자.

 

테스트1:

하나의 응용프로그램이 MAXLOCKS 비율이상으로 락을 획득한 경우.

테스트 환경: AIX 5.3 64 Bit, DB2 UDB 8.2.3

 

-------- 테스트 시작 -------

--현재의 LOCKLIST 설정 값을 확인한다.

$ db2 get db cfg | grep LOCKLIST

Max storage for lock list (4KB)              (LOCKLIST) = 100

 

--테스트의 편의성을 위해 LOCKLIST 최소값으로 설정한 DB 기동한다.

$ db2 update db cfg using LOCKLIST 4

$ db2 terminate

$ db2 force application all

$ db2 deactivate db sample

$ db2 activate db sample

$ db2 connect to sample

$ db2 get db cfg | grep LOCKLIST

Max storage for lock list (4KB)              (LOCKLIST) = 4

*) DB 기동 후에 LOCKLIST 4 변경되었음을 있다. , LOCKLIST 지정된 메모리 공간은 16KB(4*4KB)이고, MAXLOCKS 10% 이므로, 하나의 응용프로그램은 1.6KB(1638 Bytes) 만큼의 메모리 공간을 사용하는 것이 가능하다.

 

--테스트를 위한 테이블을 생성하고 1건을 입력한다.

$ db2 “create table lock_escals_test (id integer, name char(10))”

$ db2 +c   -- 테스트를 위해 auto commit mode 해제한다.

db2 => insert into lock_escals_test values (1,’1’)

 

-- 다른 터미널에서 정보를 조회한다.

$ db2 –tf lock_info.sql

AGENT_ID LOCK_MODE                  LOCK_OBJECT_TYPE      TABLE_NAME

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

1031     Exclusive Lock             table row lock type   LOCK_ESCALS_TEST

1031     Intention Exclusive Lock   table lock type       LOCK_ESCALS_TEST

*) LOCK_ESCALS_TEST 테이블에, IX(Intention Exclusive) 모드로 1개의 테이블 락을 획득하였고, X(Exclusive) 모드로 1개의 로우 락을 획득한 것을 있다.

-- 추가로 1건을 입력한 후에 정보를 조회해보자.

$ db2 –tf lock_info.sql

AGENT_ID LOCK_MODE                  LOCK_OBJECT_TYPE      TABLE_NAME     

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

1031     Exclusive Lock             table row lock type   LOCK_ESCALS_TEST

1031     Exclusive Lock             table row lock type   LOCK_ESCALS_TEST

1031     Intention Exclusive Lock   table lock type       LOCK_ESCALS_TEST

*) 조회 결과, DB2 UDB에서는 로우 단위의 락이 메모리에서 관리됨을 명확히 확인할 있다. 이러한 방식으로 MAXLOCKS 도달할 때까지 메모리상에 로우 정보가 저장될 것이다.

 

-- LOCK_ESCALS_TEST 45건을 입력한 시점의 정보는 다음과 같다.

AGENT_ID LOCK_MODE                  LOCK_OBJECT_TYPE      TABLE_NAME     

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

1031     Exclusive Lock             table row lock type   LOCK_ESCALS_TEST

1031     Exclusive Lock             table row lock type   LOCK_ESCALS_TEST

....                                                     

1031     Exclusive Lock             table row lock type   LOCK_ESCALS_TEST

1031     Intention Exclusive Lock   table lock type       LOCK_ESCALS_TEST                                                                                      

46 record(s) selected.

*) LOCK_ESCALS_TEST 테이블에, IX(Intention Exclusive) 모드로 1개의 테이블 락을 획득하였고, X(Exclusive) 모드로 45개의 로우 락을 획득한 것을 있다.

 

-- 추가로 1건을 입력한 후에 정보를 조회해보자.

AGENT_ID LOCK_MODE                 LOCK_OBJECT_TYPE      TABLE_NAME     

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

1031     Exclusive Lock            table lock type       LOCK_ESCALS_TEST

 

*) LOCK_ESCALS_TEST 테이블에, IX(Intent Exclusive) 모드로 획득한 테이블 락이 X(Exclusive) 모드의 락으로 변경되었고, 기존에 획득한 로우 락이 모두 사라졌음을 있다. , Lock escalation 발생한 것이다. 테이블 락을 X(Exclusive) 모드로 획득하였으므로, 다른 응용프로그램에서는 LOCK_ESCALS_TEST 테이블에 대한 SELECT DML 수행이 불가능하다. 이유는 모드간의 호환성이 없기 때문인데, 모드간의 호환성에 대해서는 “4. DB2 UDB Lock Mode 이해에서 설명하기로 한다. Lock escalation 발생 여부를 확인하는 방법은 가지가 있지만, 가장 인지 하기 쉬운 방법은 db2diag.log 확인하는 것이다. Lock escalation 대한 상세 정보를 db2diag.log에서 확인하기 위해서는 DBM Configuration 파라미터인 NOTIFYLEVEL 3 또는 4이어야 한다(기본설정 값은 3). 아래는 Lock escalation 발생한 경우에 db2diag.log 출력되는 내용이다.

2007-04-24-11.04.15.430688+540 E3616C468          LEVEL: Warning

PID     : 1634496              TID  : 1           PROC : db2agent (SAMPLE) 0

INSTANCE: db2inst1             NODE : 000         DB   : SAMPLE

APPHDL  : 0-1031               APPID: *LOCAL.db2inst1.070424014503

FUNCTION: DB2 UDB, data management, sqldEscalateLocks, probe:3

MESSAGE : ADM5502W  The escalation of "46" locks on table

          "DB2INST1.LOCK_ESCALS_TEST" to lock intent "X" was successful.

*) DB2INST1.LOCK_ESCALS_TEST 테이블에 대해 46개의 락이 X 모드의 테이블 락으로 escalation 되었다는 정보를 확인할 있다. , 현재의 LOCKLIST, MAXLOCKS 설정으로, 하나의 응용프로그램은 하나의 테이블에 대해서 46개의 정보를 메모리 공간에 저장할 있다.

-------- 테스트 종료 -------

 

지금까지의 테스트 내용은 하나의 응용 프로그램에서 하나의 테이블에 대해 MAXLOCKS 지정된 비율 이상으로 락을 획득한 경우의 Lock escalation 발생 현상을 살펴보았다. 그렇다면, 하나의 응용 프로그램에서 2 이상의 테이블에 대한 락을 획득하였고, 특정 1개의 테이블에 대한 과도한 로우 획득으로 인해 MAXLOCKS 비율 이상으로 락을 획득한 경우를 살펴보도록 하자. Lock escalation 어떻게 발생할 것인가? 모든 테이블에 대해서 Lock escalation 발생할 것인가? 아니면 가장 많은 로우 락이 설정된 테이블에 대해서만 Lock escalation 발생할 것인가? 상식적으로 생각해도, 후자가 맞을 것이다. 테스트를 통해서 확인해 보도록 하자.

 

-------- 테스트 시작 -------

-- LOCK_ESCALS_TEST2 테이블 생성 1 입력

$ db2 “create table lock_escals_test2 (id integer, name char(10))”

$ db2 +c   -- 테스트를 위해 auto commit mode 해제한다.

db2 => insert into lock_escals_test2 values (1,’1’)

-- LOCK_ESCALS_TEST 테이블에 38 입력 후에 정보 확인

$ db2 –tf lock_info.sql

AGENT_ID LOCK_MODE                 LOCK_OBJECT_TYPE      TABLE_NAME

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

1162     Exclusive Lock            table row lock type   LOCK_ESCALS_TEST

....                               

1162     Exclusive Lock            table row lock type   LOCK_ESCALS_TEST

1162     Exclusive Lock            table row lock type   LOCK_ESCALS_TEST2

1162     Intention Exclusive Lock  table lock type       LOCK_ESCALS_TEST

1162     Intention Exclusive Lock  table lock type       LOCK_ESCALS_TEST2

41 record(s) selected.

*) LOCK_ESCALS_TEST2 테이블에 IX 모드의 테이블 1, X 모드의 로우 1, LOCK_ESCALS_TEST 테이블에 IX 모드의 테이블 1, X 모드의 로우 38개를 회득하였다. , 현재까지 41개의 락이 하나의 응용프로그램에서 획득한 상태이다.

경우에 로우 락을 적게 설정한 LOCK_ESCALS_TEST2 테이블에 추가로 3건을 입력한 후에 정보와 db2diag.log 내용을 확인해 보자.

$ db2 –tf lock_info.sql

AGENT_ID LOCK_MODE                 LOCK_OBJECT_TYPE        TABLE_NAME

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

1162     Exclusive Lock            table row lock type     LOCK_ESCALS_TEST2

1162     Exclusive Lock            table row lock type     LOCK_ESCALS_TEST2

1162     Exclusive Lock            table row lock type     LOCK_ESCALS_TEST2

1162     Exclusive Lock            table row lock type     LOCK_ESCALS_TEST2

1162     Exclusive Lock            table lock type         LOCK_ESCALS_TEST

1162     Intention Exclusive Lock  table lock type         LOCK_ESCALS_TEST2

 6 record(s) selected.

시점에서의 db2diag.log 내용은 아래와 같다.

2007-04-24-11.52.22.987478+540 E5023C468          LEVEL: Warning

PID     : 987356               TID  : 1           PROC : db2agent (SAMPLE) 0

INSTANCE: db2inst1             NODE : 000         DB   : SAMPLE

APPHDL  : 0-1162               APPID: *LOCAL.db2inst1.070424024716

FUNCTION: DB2 UDB, data management, sqldEscalateLocks, probe:3

MESSAGE : ADM5502W  The escalation of "38" locks on table

          "DB2INST1.LOCK_ESCALS_TEST" to lock intent "X" was successful.

*) LOCK_ESCALS_TEST 테이블에 대해, 38개의 락이 X 모드의 테이블 락으로 Lock escalation 되었음을 있으며, LOCK_ESCALS_TEST2 테이블에 대해서는 Lock escalation 발생하지 않았다. 테스트를 통해, Lock escalation 가장 많은 락이 설정된 테이블에 대해서 우선적으로 수행됨을 있다. 만일 해당 테이블의 Lock escalation 후에도 MAXLOCKS 지정된 비율보다 높을 경우에는 다음 순위의 테이블에 대해서 Lock escalation 발생할 것이다.

-------- 테스트 완료 -------

 

테스트 결과에서 있듯이, 하나의 테이블에 대해 락을 획득한 경우와, 이상의 테이블에 대해 락을 획득한 경우에, 락을 저장하는 개수가 약간 상이한 것을 있다. 테스트 결과에 의하면 대략 1개의 40 bytes 정도의 메모리 공간을 차지한다는 것을 있다. 일반적으로 Lock escalation 거의 발생하지 않는 것이 정상이지만, 만일 Lock escalation 현상이 발견된다면, 1차적으로는 LOCKLIST DB Configuration 파라미터의 현재설정 값을 확인한 , 해당 수치를 증가시키는 것이다. 2차적으로는 db2diag.log 내용을 참조하여, 해당 어플리케이션에서 필요이상의 락을 장기간 획득해야만 하는지에 대한 타당성 점검을 필요성이 있다


DB2 UDB Lock Mode Lock Compatibility

DB2 UDB 사용 대기 현상이 발생할 경우, 문제 원인 분석을 위해서는 DB2 UDB 에서 사용되는 모드와 호환성에 대한 이해가 선행되어야 한다. DB2 UDB에서는 None 모드를 포함하여 12개의 모드를 사용한다. ORACLE 데이터베이스의 경우, X(Exclusive), SSX(Sub Share Exclusive), SX(Sub Exclusive), S(Shared), SS(Sub Share), N(Null) 같이 6개의 모드를 사용한다. 모드에 대한 정의와 예제는 다음과 같다. 모드에 대한 이해를 높이기 위해, AIX 5.3 64비트, DB2 UDB 8.2.3 환경의 테스트를 통해 설명하였다.

 

<테스트 1>

Lock Mode

IN (Intent None)

Applicable Object

Table space, blocks, table

Description

“Dirty Read” , UR Isolation level 사용하여 데이터를 조회하는 경우에 IN 모드의 테이블 락을 획득해야 한다.

 

IN 모드와 호환성이 없는 Z 모드의 락을 T2 트랜잭션에서 획득한 상태에서 T3 트랜잭션에서 “Dirty Read” 수행한다. IN 모드와 Z 모드간에 호환성이 없으므로, T3 트랜잭션은 대기를 것이다. 또한 Z 모드의 락을 유지하기 위해서, Z 모드와 호환성이 없는 IX 락을 T1 트랜잭션에서 획득한 상태로 테스트를 수행한다.

 

T1 트랜잭션: (Agent ID 1313)

$ db2 +c “insert into lock_test values(3,’3’)

DB20000I  The SQL command completed successfully.

* 데이터 입력 IX 모드의 테이블 락과 X 모드의 로우 락을 획득한다.

 

T2 트랜잭션: (Agent ID 292)

$ db2 “alter table lock_test add juso char(100)”

* IX 모드와 Z 모드간의 호환성이 없으므로 T2 트랜잭션은 락을 대기한다.

 

T3 트랜잭션: (Agent ID 1345)

$db2 “select * from lock_test with ur

* Z 모드와 IN 모드간의 호환성이 없으므로 T3 트랜잭션은 락을 대기한다.

 

-- 현재의 Lock 대기 상태를 확인해보자.

 $ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE TABLE_NAME HOLDER_ID

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

292      IX       Z       table lock        LOCK_TEST 1313

1345     IN       IN      table lock        LOCK_TEST 292

* T3 트랜잭션(Agent ID 1345) IN 모드의 테이블 락을 대기하는 것을 있다. 이를 통해,  “Dirty Read” 시에 IN 모드의 테이블 락을 획득한다는 것을 간접적으로 확인할 있다.

 

<테스트 2>

Lock Mode

IS (Intent Share)

Applicable Object

Table space, blocks, tables

Description

CS 이상의 Isolation level 사용하여 데이터를 조회하는 경우에 IS 모드의 테이블 락을 획득해야 한다.

 

IS 모드와 호환성이 없는 X 모드의 락을 T1 트랜잭션에서 획득한 상태에서 T2 트랜잭션에서 읽기 작업을 수행한다. IS 모드와 X 모드간에 호환성이 없으므로, T23 트랜잭션은 대기를 것이다.

 

T1 트랜잭션: (Agent ID 1313)

$ db2 +c “lock table lock_test in exclusive mode

DB20000I  The SQL command completed successfully.

 

T2 트랜잭션: (Agent ID 292)

$ db2 “select * from lock_test with cs”

*) X 모드와 IS 모드간의 호환성이 없으므로 T2 트랜잭션은 락을 대기한다

 

-- 현재의 Lock 대기 상태를 확인해보자.

$ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE TABLE_NAME HOLDER_ID

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

292      X        IS      table lock       LOCK_TEST  1313

* T2 트랜잭션(Agent ID 292) IS 모드의 테이블 락을 대기하는 것을 있다. 이를 통해, CS 이상의 Isolation level에서 데이터 조회 , IS 모드의 테이블 락을 획득한다는 것을 확인할 있다.

 

<테스트 3>

Lock Mode

NS (Next Key Share)

Applicable Object

Rows

Description

CS 또는 RS Isolation level에서 데이터를 조회하는 경우에 현재 커서가 위치한 레코드에 대해 NS 모드의 로우 락을 획득해야 한다.

 

NS 모드와 호환성이 없는 X 모드의 락을 T1 트랜잭션에서 획득한 상태에서, T2 트랜잭션에서 CS Isolation level 데이터 조회를 수행한다.

 

T1 트랜잭션: (Agent ID 1313)

$ db2 +c “insert into lock_test values(3,’3’)

DB20000I  The SQL command completed successfully.

* 데이터 입력 IX 모드의 테이블 락과 X 모드의 로우 락을 획득한다.

 

T2 트랜잭션: (Agent ID 292)

$ db2 “select * from lock_test with cs”

* X 모드와 NS 모드간의 호환성이 없으므로 T2 트랜잭션은 락을 대기한다.

 

-- 현재의 Lock 대기 상태를 확인해보자.

$ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE     TABLE_NAME HOLDER_ID

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

292      X        NS      table row lock type  LOCK_TEST  1313

* T2 트랜잭션(Agent ID 292) NS 모드의 로우 락을 대기하는 것을 있다.

 

<테스트 4>

Lock Mode

S (Share)

Applicable Object

Rows, blocks, tables

Description

데이터의 변경을 막기 위해서 설정하는 모드이다. 예를 들어, 인덱스 생성 시에는 테이블 데이터의 변경을 막아야 하므로, S 모드의 테이블 락을 획득해야 한다.

 

S 모드와 호환성이 없는 IX 모드의 락을 T1 트랜잭션에서 획득한 상태에서, T2 트랜잭션에서 인덱스 생성을 시도한다.

 

T1 트랜잭션: (Agent ID 1313)

$ db2 +c “insert into lock_test values(3,’3’)

DB20000I  The SQL command completed successfully.

* 데이터 입력 IX 모드의 테이블 락과 X 모드의 로우 락을 획득한다.

 

T2 트랜잭션: (Agent ID 292)

$ db2 “create index lock_test_s01 on lock_test(id)”

* IX 모드와 S 모드간의 호환성이 없으므로 T2 트랜잭션은 락을 대기한다.

 

-- 현재의 Lock 대기 상태를 확인해보자.

$ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE  TABLE_NAME HOLDER_ID

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

292      IX       S       table lock        LOCK_TEST  1313

* T2 트랜잭션(Agent ID 292) S 모드의 테이블 락을 대기하는 것을 있다.

 

<테스트 5>

Lock Mode

IX (Intent Exclusive)

Applicable Object

Table spaces, blocks, tables

Description

테이블내의 레코드에 대한 변경(delete, update) 레코드 입력(insert) 시에 IX 모드의 테이블 락을 획득해야 한다.

 

IX 모드와 호환성이 없는 S 모드의 락을 T1 트랜잭션에서 획득한 상태에서, T2 트랜잭션에서 데이터 삭제를 시도한다.

 

T1 트랜잭션: (Agent ID 1313)

$ db2 +c “lock table lock_test in share mode “ 

DB20000I  The SQL command completed successfully.

 

T2 트랜잭션: (Agent ID 292)

$ db2 “delete from lock_test where id=1”

* S 모드와 IX 모드간의 호환성이 없으므로 T2 트랜잭션은 락을 대기한다.

 

-- 현재의 Lock 대기 상태를 확인해보자.

$ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE  TABLE_NAME HOLDER_ID

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

292      S        IX      table lock        LOCK_TEST  1313

* T2 트랜잭션(Agent ID 292) IX 모드의 테이블 락을 대기하는 것을 있다.

 

<테스트 6>

Lock Mode

SIX (Share with Intent Exclusive)

Applicable Object

Tables, blocks

Description

IX 모드의 테이블 락을 획득한 상태에서 추가로 S 모드의 테이블 락을 획득하거나, 반대의 경우에 SIX 모드의 테이블 락을 획득해야 한다.

 

SIX 모드와 호환성이 없는 S 모드 락을 T1 트랜잭션에서 획득한 상태에서, T2 트랜잭션에서 S 모드 락을 획득한 , 추가로 IX 모드의 락을 획득하려고 시도한다.

 

T1 트랜잭션: (Agent ID 1313)

$ db2 +c “lock table lock_test in share mode “

DB20000I  The SQL command completed successfully.

 

T2 트랜잭션: (Agent ID 292)

$ db2 +c

db2=> lock table lock_test in share mode 

DB20000I  The SQL command completed successfully.

db2=> delete from lock_test where id=1

* S 모드의 테이블 락을 획득한 상태에서, 삭제(delete)작업을 위해 IX 모드의 테이블 락을 추가로 획득하기 위해 SIX 모드로 컨버젼을 시도한다. 하지만, T1 트랜잭션이 획득하고 있는 S 모드와 T2 트랜잭션에서 획득해야 하는 SIX 모드간의 호환성이 없으므로 락을 대기한다.

 

 -- 현재의 Lock 대기 상태를 확인해보자.

$ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE  TABLE_NAME HOLDER_ID

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

292      S        SIX     table lock        LOCK_TEST  1313

* T2 트랜잭션(Agent ID 292) SIX 모드의 테이블 락을 대기하는 것을 있다.

 

<테스트 7>

Lock Mode

U (Update)

Applicable Object

Rows, blocks, tables

Description

SELECT.. FOR UPDATE 시에 U 모드의 로우 락을 획득해야 한다.

 

U 모드와 호환성이 없는 X 모드 락을 T1 트랜잭션에서 획득한 상태에서, T2 트랜잭션에서 SELECT.. FOR UPDATE 시도한다.

 

T1 트랜잭션: (Agent ID 1313)

$ db2 +c “delete from lock_test where id=1 “ 

DB20000I  The SQL command completed successfully.

* 데이터 삭제 IX 모드의 테이블 락과 X 모드의 로우 락을 획득한다.

 

T2 트랜잭션: (Agent ID 292)

$ db2 “select * from lock_test where id=1 for update”

* T1 트랜잭션에 의해 해당 레코드에, X 모드의 로우 락이 획득된 상태이므로, T2 트랜잭션은 락을 대기한다..

 

-- 현재의 Lock 대기 상태를 확인해보자.

$ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE    TABLE_NAME HOLDER_ID

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

292      X        U       table row lock type LOCK_TEST  1313

* T2 트랜잭션(Agent ID 292) U 모드의 로우 락을 대기하는 것을 있다.

 

Lock Mode

X (Exclusive)

Applicable Object

Rows, blocks, tables, buffer pools

Description

테이블 레벨, 로우 레벨에 대한 변경작업을 하려고 X 모드의 락을 획득해야 한다. X 모드는 테스트 없이도 쉽게 이해 가능하므로, 테스트를 생략한다.

 

Lock Mode

Z (Super Exclusive)

Applicable Object

Table spaces, tables

Description

테이블 DROP, ALTER 같은 오퍼레이션 시에 Z 모드의 테이블 락을 획득해야 한다. IN 모드 설명 시에 Z 모드 테스트를 수행하였으므로, 별도의 테스트를 수행하지 않는다.

 

<테스트 8>

Lock Mode

NW (Next Key Weak Exclusive)

Applicable Object

Rows

Description

테이블에 Non unique 인덱스가 생성되어있고, 입력하려고 하는 레코드가, 현재 다른 트랜잭션에서 RR 스캔에 의해 락이 설정된 레코드와 동일한 값일 경우에 NW 모드의 락을 대기하게 된다. NW 모드는 쉽게 이해되지 않는 모드 중의 하나이다. 따라서 부분은 테스트 결과를 통해, 언제 NW 모드가 사용되는지 유추하는 방식을 사용하였다.

 

T1 트랜잭션에서 RR 스캔을 수행하고 있는 상태에서, T2 트랜잭션에서 T1 트랜잭션의 RR 스캔의 레코드에 해당되는 값을 입력한다.

앞선 테스트에서는 LOCK_TEST 테이블에 인덱스가 존재하지 않았으나, NW 모드 테스트를 위해 LOCK_TEST 테이블에 Non Unique 인덱스를 생성한다.

$ db2 “create index lock_test_s01 on lock_test(id)”

 

T1 트랜잭션: (Agent ID 1313)

$ db2 +c “select * from lock_test where id=1 with rr“ 

DB20000I  The SQL command completed successfully.

 

T2 트랜잭션: (Agent ID 292)

$ db2 “insert into lock_test values(1,'10')”

 

-- 현재의 Lock 대기 상태를 확인해보자.

$ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE     TABLE_NAME HOLDER_ID
-------- -------- ------- -------------------  ---------- ---------
292      S        NW      table row lock type  LOCK_TEST  1313

* T1 트랜잭션(Agent ID 292) 인덱스 RR 스캔을 수행한 결과, S 모드의 로우 락을 획득한 상태이고, S 모드와 T2 트랜잭션의 NW 모드는 호환성이 없으므로, T2 트랜잭션은 락을 대기하는 현상을 보인다.

 

<테스트 9>

Lock Mode

W (Weak Exclusive)

Applicable Object

Rows

Description

Unique 인덱스가 생성된 테이블에 대해, 중복 입력이 발생 가능성을 막기 위해 용도로 사용된다.

 

테스트를 위해 LOCK_TEST 테이블에 Non Unique 인덱스를 생성한 것을 DROP하고 Unique 인덱스를 생성한다.

$ db2 “drop index lock_test_s01”

$ db2 “create unique index lock_test_uk on lock_test(id)”

 

T1 트랜잭션: (Agent ID 1313)

$ db2 +c “insert into lock_test values(3,’3’)“ 

DB20000I  The SQL command completed successfully.

 

T2 트랜잭션: (Agent ID 292)

$ db2 “insert into lock_test values(3,’3’)“ 

 

-- 현재의 Lock 대기 상태를 확인해보자.

$ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE     TABLE_NAME HOLDER_ID

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

292      S        W       table row lock type  LOCK_TEST  1313

* Unique 인덱스가 생성되어 있으므로, 중복 입력을 방지하기 위해 T2 트랜잭션은 W 모드의 로우 락을 대기한다. T1 트랜잭션이 커밋을 수행할 경우 T2 트랜잭션은 SQL0803N 에러코드를 발생시키며, 트랜잭션을 롤백하며, T1 트랜잭션이 롤백을 수행할 경우에 T2 트랜잭션은 대기 상태에서 벗어나서, 트랜잭션을 진행하게 된다.

 

[ 4.1] 호환성 테스트 결과 매트릭스

 

None

IN

IS

NS

S

IX

SIX

U

X

Z

NW

W

None

O

O

O

O

O

O

O

O

O

O

O

O

IN

O

O

O

O

O

O

O

O

O

X

O

O

IS

O

O

O

O

O

O

O

O

X

X

X

X

NS

O

O

O

O

O

X

X

O

X

X

O

X

S

O

O

O

O

O

X

X

O

X

X

X

X

IX

O

O

O

X

X

O

X

X

X

X

X

X

SIX

O

O

O

X

X

X

X

X

X

X

X

X

U

O

O

O

O

O

X

X

X

X

X

X

X

X

O

O

X

X

X

X

X

X

X

X

X

X

Z

O

X

X

X

X

X

X

X

X

X

X

X

NW

O

O

X

O

X

X

X

X

X

X

X

O

W

O

O

X

X

X

X

X

X

X

X

O

X

 




DB2 UDB V8부터 동시성 향상을 위해 DB2_EVALUNCOMMITTED, DB2_SKIPDELETED, DB2_SKIPINSERTED 라는 3개의 레지스트리 변수를 제공한다. 이번 섹션에서는 각각의 레지스트리 변수의 의미와 적용 시의 효과를 살펴보기로 한다.

 

DB2_EVALUNCOMMITTED (DB2 UDB V8.1.4부터 지원)

DB2_EVALUNCOMMITTED CS(Cursor Stability) 또는 RS(Read Stability) Isolation 레벨로 테이블 인덱스 스캔시에, 데이터가 검색 조건에 맞는지 먼저 체크한 후에, 조건에 맞는 경우에만 해당 레코드에 락을 거는 방식(defer row locking) 사용한다. 따라서 조건에 맞지 않는 언커밋 상태의 레코드에 대한 스킵이 가능하다. 뿐만 아니라 테이블 스캔의 경우에는 언커밋 상태의 Deleted 로우에 대한 스킵도 가능하다. 하지만 인덱스 스캔의 경우에는 언커밋 상태의 Deleted 로우는 스킵이 불가능하다. 이것을 가능하게 하기 위해서는 뒤에서 설명할 DB2_SKIPDELETE ON으로 설정하여야 한다. 해당 레지스트리 변수의 효과를 테스트를 통해서 확인해보자.

 

테스트 1: DB2_EVALUNCOMMITTED=OFF (기본설정 ) 경우

T1 트랜잭션 (Agent ID 8)

$ db2 +c “insert into lock_test values(9,'9')”

DB20000I  The SQL command completed successfully

 

T2 트랜잭션 (Agent ID 9)

$ db2 “select * from lock_test where id between 1 and 5 with cs”

*) T1 트랜잭션에서 입력한 레코드가 T2 트랜잭션의 쿼리 조건에 해당되지는 않는다. 하지만, 현재 커서가 위치한 다음(Next) 레코드에 NS 모드의 로우 락을 획득한 후에 해당 레코드가 조건에 맞는지 체크하는 방식을 사용하므로, T2 트랜잭션은 락을 대기한다.

-- 현재의 대기상태 확인

$ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE      TABLE_NAME HOLDER_ID

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

9        X        NS      table row lock type   LOCK_TEST  8

 

테스트 2: DB2_EVALUNCOMMITTED=ON으로 변경한 경우

--DB2_EVALUNCOMMITTED ON으로 설정

$ db2set DB2_EVALUNCOMMITTED=ON

--DB 기동한다.

 

T1 트랜잭션 (Agent ID 8)

$ db2 +c “insert into lock_test values(9,'9')”

DB20000I  The SQL command completed successfully

 

T2 트랜잭션 (Agent ID 9)

$ db2 “select * from lock_test where id between 1 and 5 with cs”

ID          NAME

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

          1 1

          2 2

          3 3

          5 5

4 record(s) selected

*) DB2_EVALUNCOMMITTED=ON 효과에 의해, T2 트랜잭션이 대기 없이 수행되었다. , 현재 커서가 위치한 다음(Next) 레코드를 페치(fetch) 후에 해당 레코드가 조건에 만족하는지 체크한 것이다. 만일 조건에 만족하지 않을 경우 해당 레코드에 대한 로우 획득이 필요 없으므로, 대기현상이 발생하지 않게 된다. 이러한 defer row locking 방식에는 여러 가지 제약 사항이 존재하지만, 동시성을 높일 있다는 것은 분명한 사실이다.

 

DB2_SKIPDELETED (DB2 UDB V8.1.4부터 지원)

DB2_SKIPDELETED CS (Cursor Stability) 또는 RS (Read Stability) Isolation 레벨로 테이블 인덱스 스캔 시에, 언커밋 Deleted 로우를 스킵하는 것을 가능하게 한다.

 

테스트 1: DB2_SKIPDELETED=OFF (기본설정 ) 경우

T1 트랜잭션 (Agent ID 7)

$ db2 +c “delete from lock_test where id=3”

DB20000I  The SQL command completed successfully

 

T2 트랜잭션 (Agent ID 8)

-- 테이블 스캔을 수행하여 테스트를 해보자.

$ db2 “select * from lock_test”

ID          NAME

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

          1 1

          2 2

          4 4

         10 10
4 record(s) selected.

*) T1 트랜잭션에 의해 삭제된 레코드가 T2 트랜잭션의 쿼리 조건에 만족하지만, 테이블 스캔을 수행하므로, DB2_EVALUNCOMMITTED ON 시킨 효과에 의해 대기를 하지 않고 결과가 출력된다. , DB2_EVALUNCOMMITTED 테이블 스캔에 대해 언커밋 Deleted 로우를 스킵하는 것을 가능하게 한다.

 

-- 인덱스 스캔을 수행하여 테스트를 해보자.

$ db2 “select * from lock_test where id between 1 and 4”

*) T2 트랜잭션에서 인덱스 스캔을 수행하므로 대기를 하게 된다.
, DB2_EVALUNCOMMITTED 인덱스 스캔에 대한 언커밋 Deleted 로우를 스킵하는 것은 불가능함을 있다.

 

-- 현재의 대기상태 확인

$ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE     TABLE_NAME HOLDER_ID

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

8        X        NS      table row lock type  LOCK_TEST  7

 

테스트 2: DB2_SKIPDELETED=ON으로 변경한 경우

--DB2_SKIPDELETED ON으로 설정

$ db2set DB2_SKIPDELETED=ON

--DB 기동한다.

 

T1 트랜잭션 (Agent ID 7)

$ db2 +c “delete from lock_test where id=3”

DB20000I  The SQL command completed successfully

 

T2 트랜잭션 (Agent ID 8)

$ db2 “select * from lock_test where id between 1 and 4”

ID          NAME

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

          1 1

          2 2

          4 4

  3 record(s) selected

*) DB2_SKIPDELETED ON으로 설정함에 따라, 인덱스 스캔 시에도 언커밋 Deleted 로우를 스킵하는 것이 가능하다.

 

DB2_SKIPINSERTED (DB2 UDB V8.2.2부터 지원)

DB2_SKIPDELETED CS (Cursor Stability) 또는 RS (Read Stability) Isolation 레벨로 테이블 인덱스 스캔 시에, 언커밋 Inserted 로우를 스킵하는 것을 가능하게 한다.

 

테스트 1: DB2_SKIPINSERTED=OFF (기본설정 ) 경우

T1 트랜잭션 (Agent ID 7)

$ db2 +c “insert into lock_test values(5,'5')”

DB20000I  The SQL command completed successfully

 

T2 트랜잭션 (Agent ID 8)

$ db2 “select * from lock_test where id between 1 and 5”

*) T1 트랜잭션에서 입력한 레코드가 언커밋 상태이고, T2 트랜잭션 쿼리의 조건에 만족하므로, T2 트랜잭션은 대기를 하게 된다.

 

-- 현재의 대기상태 확인

$ db2 –tf lock_wait.sql

AGENT_ID LCK_MODE LCK_REQ LOCK_OBJECT_TYPE     TABLE_NAME HOLDER_ID

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

8        X        NS      table row lock type  LOCK_TEST  7

 

테스트 2: DB2_SKIPINSERTED=ON으로 변경한 경우

--DB2_SKIPINSERTED ON으로 설정

$ db2set DB2_SKIPINSERTED=ON

--DB 기동한다.

 

T1 트랜잭션 (Agent ID 7)

$ db2 +c “insert into lock_test values(5,'5')”

DB20000I  The SQL command completed successfully

 

T2 트랜잭션 (Agent ID 8)

$ db2 “select * from lock_test where id between 1 and 5”

ID          NAME

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

          1 1

          2 2

          3 3

          4 4

 4 record(s) selected

*) DB2_SKIPINSERTED ON으로 설정함에 따라, 언커밋 Inserted 로우를 스킵하는 것이 가능하다.

 

글을 마치며

앞선 내용에서 DB2 UDB Isolation level, Lock escalation, Lock Mode 동시성 향상을 위한 DB2 레지스트리 변수를 살펴보았다. DB Configuration 파라미터의 적절한 설정과, 설계된 Application 사용하는 사이트의 경우에는 Lock escalation이나, 대기 현상과 같은 문제가 거의 발생하지 않을 수도 있을 것이다. 하지만 이러한 동작 원리에 대한 이해가 진정한 성능관리 전문가로 거듭나는 시발점이라고 생각하며 기사를 통해 독자들이 궁금했던 부분에 대해 한가지라도 이해하는데 도움이 되었으면 하는 바램을 가지며 글을 마친다.

 

APPENDIX

1. lock_info.sql

SELECT substr(char(agent_id),1,7) agent_id ,

       CASE t4.lock_mode

           WHEN 1

           THEN 'Intention Share Lock'

           WHEN 2

           THEN 'Intention Exclusive Lock'

           WHEN 3

           THEN 'Share Lock'

           WHEN 4

           THEN 'Share with Intention Exclusive Lock'

           WHEN 5

           THEN 'Exclusive Lock'

           WHEN 6

           THEN 'Intent None (For Dirty Read)'

           WHEN 7

           THEN 'Super Exclusive Lock'

           WHEN 8

           THEN 'Update Lock'

           WHEN 9

           THEN 'Next-key Share Lock'

           WHEN 10

           THEN 'Next-key Exclusive Lock'

           WHEN 11

           THEN 'Weak Exclusive Lock'

           WHEN 12

           THEN 'Next-key Weak Exclusive Lock'

       END AS lock_mode,

       CASE t4.lock_object_type

           WHEN 1   THEN 'table lock type'

           WHEN 2   THEN 'table row lock type'

           WHEN 3   THEN 'Internal lock type'

           WHEN 4   THEN 'Tablespace lock type'

           WHEN 5   THEN 'end of table lock'

           WHEN 6   THEN 'key value lock'

           WHEN 7   THEN 'Internal lock on the sysboot table'

           WHEN 8   THEN 'Internal Plan lock'

           WHEN 9   THEN 'Internal Variation lock'

           WHEN 10  THEN 'Internal Sequence lock'

           WHEN 11  THEN 'Bufferpool lock'

           WHEN 12  THEN 'Internal Long/Lob lock'

           WHEN 13  THEN 'Internal Catalog Cache lock'

           WHEN 14  THEN 'Internal Online Backup lock'

           WHEN 15  THEN 'Internal Object Table lock'

           WHEN 16  THEN 'Internal Table Alter lock'

           WHEN 17  THEN 'Internal DMS Sequence lock'

           WHEN 18  THEN 'Inplace reorg lock'

           WHEN 19  THEN 'Block lock type'

           ELSE char(t4.lock_object_type)

END AS lock_object_type,

       substr(t4.table_name,1,18) table_name

FROM   TABLE( snapshot_lock( 'sample' , - 1 ) ) t4

WHERE  table_name LIKE 'LOCK_ESCALS%';

 

2. lock_wait.sql

SELECT substr(char(t1.agent_id),1,8) agent_id,

       CASE t4.lock_mode

           WHEN 1  THEN 'IS'

           WHEN 2  THEN 'IX'

           WHEN 3  THEN 'S'

           WHEN 4  THEN 'SIX'

           WHEN 5  THEN 'X'

           WHEN 6  THEN 'IN'

           WHEN 7  THEN 'Z'

           WHEN 8  THEN 'U'

           WHEN 9  THEN 'NS'

           WHEN 11 THEN 'W'

           WHEN 12 THEN 'NW'

       END AS lck_mode,

       CASE t4.lock_mode_requested

           WHEN 1  THEN 'IS'

           WHEN 2  THEN 'IX'

           WHEN 3  THEN 'S'

           WHEN 4  THEN 'SIX'

           WHEN 5  THEN 'X'

           WHEN 6  THEN 'IN'

           WHEN 7  THEN 'Z'

           WHEN 8  THEN 'U'

           WHEN 9  THEN 'NS'

           WHEN 11 THEN 'W'

           WHEN 12 THEN 'NW'

       END AS lck_req,

       CASE t4.lock_object_type

           WHEN 1   THEN 'table lock'

           WHEN 2   THEN 'table row lock type'

           WHEN 3   THEN 'Internal lock type'

           WHEN 4   THEN 'Tablespace lock type'

           WHEN 5   THEN 'end of table lock'

           WHEN 6   THEN 'key value lock'

           WHEN 7   THEN 'Internal lock on the sysboot table'

           WHEN 8   THEN 'Internal Plan lock'

           WHEN 9   THEN 'Internal Variation lock'

           WHEN 10  THEN 'Internal Sequence lock'

           WHEN 11  THEN 'Bufferpool lock'

           WHEN 12  THEN 'Internal Long/Lob lock'

           WHEN 13  THEN 'Internal Catalog Cache lock'

           WHEN 14  THEN 'Internal Online Backup lock'

           WHEN 15  THEN 'Internal Object Table lock'

           WHEN 16  THEN 'Internal Table Alter lock'

           WHEN 17  THEN 'Internal DMS Sequence lock'

           WHEN 18  THEN 'Inplace reorg lock'

           WHEN 19  THEN 'Block lock type'

           ELSE char(t4.lock_object_type)

       END AS lock_object_type,

       substr(t4.table_name,1,10) table_name,

substr(char(t4.agent_id_holding_lk),1,8) AS holder_id

FROM TABLE( snapshot_appl_info( 'sample' , -1)) t1 ,

       TABLE( snapshot_appl( 'sample' , -1 )) t2,

       TABLE( snapshot_statement( 'sample', -1)) t3,

       TABLE( snapshot_lockwait( 'sample', -1)) t4

WHERE  t1.agent_id=t2.agent_id

AND    t1.agent_id=t3.agent_id

AND    t1.agent_id=t4.agent_id;

 

참고 문헌

DB2 UDB V8.2 Administration Guide :Performance

Lock avoidance in DB2 UDB V8 Improving concurrency with new registry variables

Diagnosing and Resolving Lock Problems with DB2 Universal Database



신고
Posted by 지영아빠

DB2 setObject 문제

언어/Java : 2008.10.21 19:43
이런 Exception이 발생해서 코드를 살펴보니 다음과 같이 되어 있었습니다.

com.ibm.db2.jcc.b.SqlException: [ibm][db2][jcc][10281][10295] JDBC 유형 0이(가) 아직 지원되지 않습니다.
    at com.ibm.db2.jcc.b.t.h(t.java:1053)
    at com.ibm.db2.jcc.b.jg.b(jg.java:491)
    at com.ibm.db2.jcc.b.jg.a(jg.java:1261)
    at com.ibm.db2.jcc.b.jg.setObject(jg.java:1241)


다음의 코드에서 문제가 발생했습니다.

pstmt.setObject(1, null, Types.NULL);

이것을 1이 아닌 2 이상이 되도록 수정하니 Exception이 사라지네요..
Oracle에서는 이런 문제가 발생하지 않았는데, DB2 의 jdbc드라이버에서만 발생하는 것 같습니다.

물론 A와 B는 null이 가능하고, C는 pk라고 할때 다음과 같습니다.

Exception이 발생하는 Query는 다음과 같습니다.
String query = "UPDATE TMP SET A=?,B=? WHERE C=?";
PreparedStatement pstmt = conn.preparedStatement(query);
pstmt.setObject(1, null, Types.NULL);
pstmt.setObject(2, "abc");
pstmt.setObject(3, "123");
pstmt.executeUpdate();

다음과 같이 수정하면 발생하지 않습니다.
String query = "UPDATE TMP SET B=?,A=? WHERE C=?";
PreparedStatement pstmt = conn.preparedStatement(query);
pstmt.setObject(1, "abc");
pstmt.setObject(2, null, Types.NULL);
pstmt.setObject(3, "123");
pstmt.executeUpdate();



신고
Posted by 지영아빠

적응

회사생활 : 2007.08.01 21:51
이제 이곳에 온지도 3주가 흘렀습니다.

제게 도전의 기회가 주어졌을때 저는 과감히 도전을 선택했습니다.
저에게 있어서 큰 변화라면 Client 개발자에서 미들웨어 개발자로의 변신입니다.
언어도 Visual C++에서 Java로 변했습니다.
서버 솔루션 개발은 저에게 새롭고 신기한 경험으로 다가오고 있습니다.

이곳은 아키텍쳐를 매우 중시하는 것을 볼 수 있었습니다.
그도 그럴것이 처음에 아키텍쳐를 단단하게 잡지 못하면 나중에 문제가 되는 사항이 있기에,
이곳에서는 처음부터 아키텍쳐간의 장단점을 비교하면서 의사결정을 합니다.

구성원들 모두가 해당아키텍쳐가 왜 나오게 되었는지 이해하면서 이것이 완료되었을 때,
개발을 진행하게 됩니다. 제가 온 3주동안, 첫주에 잡았던 아키텍쳐 방향이 집중회의에서 전격적으로 뒤바뀌게 되어 그 다음주 부터는 새로운 아키텍쳐에 대해서 토론하는 과정을 거쳐서 거의 마무리 되었습니다.

이제 남은 것은 실제로 테스트 코드를 작성하면서 나머지 설계를 마무리 짓고, 본격적인 코딩에 착수하는 것입니다. Output이 어떻게 나올지 사뭇 기대가 됩니다.

전 회사에서는 시간에 쫓기어 그렇게 하지 못했던 것 같습니다.
이곳의 생활은 제가 이제 껏 경험하지 못한 것을 한꺼번에 경험하게 합니다.

한꺼번에 많은 키워드들이 쏟아지다 보니 정신을 차리기 힘들 정도입니다.
요즘 들어 저와 관련된 키워드는 다음의 것들입니다.

Java, EJB, Beans, JMX, MBean, JNDI, XML, JAXB, RMI, SWT, GEF, EMF,
SOA, WSDL, SOAP, UDDI, ESB, EMB, SSO, IAM, BPM,
EClipse, subclipse, Ant, JUnit, Subversion, LOG4J, MINA,
MVS, Linux, Ubuntu, Fedora, bash, csh, Korn shell,
vim, VMWare, NAT, SecureCRT, WinSCP,
Regular Experession, RAC, Oracle, DB2, JDBC,
CONTROL-M, JES, SAS, syncsoft, FailOver, Step, Job, JCL, Activity, Human Activity,
RBAC, LDAP, Scheduler, Business Timer

이곳의 문화와 용어에 빨리 익숙해져야 하겠습니다.


신고

'회사생활' 카테고리의 다른 글

적응2  (0) 2007.10.10
교육  (1) 2007.08.09
적응  (0) 2007.08.01
첫 출근  (2) 2007.07.09
위즈맥스를 떠나며..  (0) 2007.07.07
좋은회사 나쁜회사 구분하는 법  (0) 2007.06.14
Posted by 지영아빠

티스토리 툴바