[MSSQL] DB LOCK 관련

SQL Server나 DB2의 경우는 Locking이 주요한 issue중의 한가지 입니다.

오라클은 Rollback Segment를 통해서 Before Image를 보여줄 수 있기 때문에 타 사용자가 해당 데이타를 DML 작업하고 있어도 SELECT lock이 필요없지만 타 DBMS(DB2, SQL Server)에서는 이전 image를 보여주지 못하므로 locking 상태로 대기하거나 현재 수정되고 있는 데이타를 uncommit 상태로 보여줄 수 밖에 없습니다. 물론 이는 transaction isolation level에 따라 결정됩니다.

​

SQL Server는 4가지 Transaction isolation level이 존재합니다.

이를 간단하게 설명드리면 READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE인데

READ UNCOMMITTED는 COMMIT 되지 않은 데이타(dirty read)를 읽을 수 있는 상태이고 rollback시 이전에 읽은 값에 대한 보장을 할 수 없는 특징이 있고

READ COMMITTED는 COMMIT 되지 않은 모든 트랜잭션에 대해서는 locking 상태에 있고 읽을 수 없는 상태이며 COMMIT된 DATA만 읽을 수 있고

REPEATABLE READ는 한번 SELECT로 가져간 것을 트랜잭션이 끝날 때까지 shared lock 상태로 두어 타 transaction에서 update를 할 수 없도록 하는 경우이며

Serializable은 한번 SELECT로 가져간 것을 트랜잭션이 끝날 때까지 shared lock 상태로 두고 그 사이의 key레벨에 대한 insert도 불가능하도록 합니다.

​

locking에 관련된 요소가 많지만 lock size, lock mode, isolation level, SQL 문장등 다양한 요인에 의해 달라질 수 있습니다.

locking 단위는 row level인지 Page level인지 따라 다를 수 있습니다. 만약 lock size가 Page라면 Page 내의 1개의 row 만 DML작업이 일어나도 Page 전체에 locking이 발생하게 됩니다.

lock mode는 shared lock인지 exclusive lock인지에 따라 달라질 수 있습니다. 위의 여러가지 요인에 의하여 영향을 받기때문에 설명하신 자료만으로는 무엇때문이라고 단정할 수는 없으며 Oracle은 특별한 Case(select for update)를 제외하고는 Lock이 주요한 문제가 되지 않지만 SQL Server나 DB2는 근본적인 lock Mechanism이 다르기에 locking Mechanism을 이해하여 locking을 최소화해야하며 SQL 문장 또는 transaction내에서도 최적의 SQL로 구현하고 lock을 피할수 없다면 최소의 시간만 locking이 되도록 해야할 것입니다.

​

출처 : http://www.dator.co.kr/56591