멋지게 놀아라

DB2는 SELECT문을 수행 중에도 Row에 대한 Lock을 획득한다. 이는 기본 isolation level인 CS(Cursor Stability) 때문이다.

CS는 쿼리 수행 시 Commit된 데이터만 보여준다. 이 때문에 쿼리에서 검색되어져야 할 행에 Lock이 걸려 있을 경우 쿼리는 종료가 되지 않으며, 행에 걸려 있는 Lock이 풀릴 때 까지 대기한다.(DB의 LOCK_TIMEOUT 값 시간이 -1일 경우)

오라클은 쿼리에서 검색 되어져야 할 행에 변경이 가해졌을 경우 이전 데이터 값을 Rollback Segment에서 읽어와서 보여준다. 즉, SELECT 문 수행 시에는 Lock이 걸려서 대기하는 경우가 없다.

DB2 9.7에서는 오라클 사용자를 안기 위해서 많은 부분에 변화를 가했다. Lock 메커니즘 또한 그 동안 오라클 과의 비교에서 약점이 되던 "읽기 일관성" 부분을 해결한 것이다.

DB2 9.7에서 변경 된 Lock 메커니즘은 "SELECT 시 Lock을 획득하기 위하여 대기를 하지 않는다" 이다.

오라클은 버퍼캐시상의 Undo Block / Rollback Segment를 이용하여 이전 행의 이미지를 가져온다.

하지만 DB2 9.7에서는 로그 버퍼와 로그 파일의 트랜잭션 로그를 읽어와서 이전 값을 보여준다.

쿼리에 의해서 읽혀져야 할 행에 Lock이 걸려 있으면, 로그버퍼나 트랜잭션 로그에서 읽어와서 처리를 한다.

V9.1ESE 과 V9.7 Express-C를 가지고 테스트를 했다.

이게 기본적으로 DB2의 Isolation Level인 CS의 동작 개념이다. 내 쿼리에 의해서 Return 되어야 하는 행은 항상 최신 Commit된 데이터만 보여준다. 이것이다.

로그에서 읽어서 이전 값을 보여주는 발상이란 .. 대단한 것 같다. 어차피 Commit되거나 Rollback 되지 않은 트랜잭션 로그가 있는 로그는 재 사용될 일이 없기 때문이다.

이로 인하여 오라클 에서 발생하는 "snapshot too old" 메시지를 안 만나게 할 수 있다는 것이다.

진작에 이렇게 공격적으로 나오지 왜 이제서야 … 이런 생각의 변화를 가지는지 안타까울 따름이다.