DB2 UDB의 Locking 매커니즘과 동시성 제어:Part 1 - Lock escalation (2)

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

--테스트의 편의성을 위해 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에 출력되는 내용이다.*) 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_MODELOCK_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의 내용은 아래와 같다.*) 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 의 내용을 참조하여, 해당 어플리케이션에서 필요이상의 락을 장기간 획득해야만 하는지에 대한 타당성 점검을 할 필요성이 있다.제공 : DB포탈사이트 DBguide.net