간단하게 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
넥슨 DB 팀 ( http://nexondbteam.tistory.com )
URL : http://nexondbteam.tistory.com/36
'연구개발 > DBA' 카테고리의 다른 글
데이터모델링 - 정규화 기본 개념 (0) | 2009.09.26 |
---|---|
데이터베이스 호환성 수준 변경 (0) | 2009.07.29 |
Create Directory SQL (0) | 2009.07.29 |
간단한 암호화 복호화 (0) | 2009.07.29 |
vbs코드를 이용한 Database Scripting (0) | 2009.07.29 |