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

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

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
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 테이블에는 다음과 같은 레코드가 저장되어있다.1. Non-Repeatable ReadsNon-Repeatable Reads란 위의 예처럼, 하나의 UOW 안에서 동일한 레코드를 2번 이상 조회하는 경우에, 다른 트랜잭션에서 해당 레코드를 변경함으로 인해, 조회 시마다 결과가 다르게 나타나는 현상이다. 이러한 이상현상을 해결하기 위해서는 쿼리의 result set에 해당되는 레코드에 로우 레벨의 락을 설정하는 RS (Read Stability) Isolation level을 사용하면 된다.2. Phantom readsPhantom 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 이다.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
제공 : DB포탈사이트 DBguide.net