(─━┘_└━─)/ 머리만1톤(Head1Ton)

간단하게 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 수행


       select col1 from tA where col1 between 2 and 6
       -- 여기까지수행후 다른 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

 
하만철 / Ha Man cheol
넥슨 DB 팀 ( http://nexondbteam.tistory.com ) 
URL : http://nexondbteam.tistory.com/36