간단하게 SERIALIZABLE과 REPEATABLE READ시 Lock이 어떻게 걸리는지를 테스트 해 보았습니다.
-- 데이터를준비한다.
-- drop table tA
create table tA (col1 int)
insert into tA select 1
insert into tA select 5
insert into tA select 10
-- repeatable read TEST
set transaction isolation level repeatable read
begin tran
select col1 from tA where col1 between 2 and 4
-- 여기까지수행후 다른 spid로 접속해 sp_lock 수행
-- 여기까지수행후 다른 spid로 접속해 sp_lock 수행
REPEATABLE READ의 경우 데이터가 있는 경우 SELECT를 하면 Row Lock 이 걸린다.
commit
-- serializable TEST
set transaction isolation level serializable
begin tran
select col1 from tA where col1 between 2 and 4
-- 여기까지수행후 다른 spid로 접속해 sp_lock 수행
select col1 from tA where col1 between 2 and 6
-- 여기까지수행후 다른 spid로 접속해 sp_lock 수행
데이터가 있으나 없으나 무조건 Table Lock을 걸어 버린다.
생각해 보면 범위잠금을 건다는게 특정한 between 2 and 4 라고 조회했다고 해서
SQL 서버가 2~4까지 조회 중이야! 라고 기억하고 있기에는 부담이 너무 크지 않을까? 라는 생각이 든다.
그래서 조회가 발생하면 아예 Table Lock을 걸어 버리고 하나의 트랜잭션씩 처리해 버리려고 하는 것 같다.
데이터는 정확하겠지만 정말 동시성이 끝장나게 떨어지는 방식이다~! 허걱~!
commit
2008-06-28 추가
삽질한게 밝혀졌습니다. ㅜㅜ
테이블에 인덱스가 있는 경우 테이블락 대신 키 범위 잠금이 걸리게 되네요..
조만간 문서에 업데이트 해 두도록 하겠습니다. 흑~ ㅠ_ㅠ
넥슨 DB 팀 ( http://nexondbteam.tistory.com )