[MSSQL] 트랜잭션과 락(Lock)

트랜잭션 : 하나의 논리적 작업으로 수행되는 일련의 작업 단위 

트랜잭션의 4가지 속성 

원자성 Atomicity , 일관성 Consistency , 격리성 Isolation , 영속성 Durability (ACID)

 

Atomicity : 트랜잭션은 원자적 작업단위여야 하며, 데이터 수정은 모두 수행되거나 하나도 수행되지 않아야 한다.

Consistency : 완료 시 트랜잭션은 모든 데이터를 일관된 상태로 유지해야 하며, 이는 모든 데이터의 무결성 유지다.

Isolation : 여러 트랜잭션이 동시 실행될 때, 동시 트랜잭션에 의한 수정은 다른 동시 트랜잭션에 의한 수정과 격리되어야 한다.

Durability : 트랜잭션에 의한 수정은 영구적으로 시스템에 적용된다.

 

 

Q. 락(Lock)은 왜 발생할까?

= 락은 트랜잭션의 속성을 보장하기 위해 발생한다.

MSSQL을 포함한 모든 RDBMS에서 락(Lock)은 트랜잭션의 ACID 속성, 그중에서도 특히 격리성(Isolation)과 일관성(Consistency), 영속성(Durability)을 보장하기 위한 핵심 메커니즘입니다.

 

MSSQL은 동시성(Concurrency)과 데이터 격리 수준(Isolation Level) 사이의 균형을 맞추기 위해 다양한 유형의 락을 사용합니다.

1. 공유 락 (Shared Lock - S Lock)
   1. 데이터를 읽을 때(SELECT) 발생합니다.
   2. 다른 트랜잭션이 동시에 읽는 것은 허용하지만, 수정(Update/Delete)하는 것은 막아 읽는 동안 데이터가 변하지 않음을 보장합니다.
2. 배타/독점 락 (Exclusive Lock - X Lock)
   1. 데이터를 수정할 때(INSERT/UPDATE/DELETE) 발생합니다.
   2. 해당 자원에 대해 다른 모든 트랜잭션의 읽기 및 쓰기를 전면 차단합니다.

 

💡 핵심 요약 만약 락이 없다면 트랜잭션 A가 데이터를 수정하는 도중에 트랜잭션 B가 들어와 아직 커밋되지 않은 데이터를 읽어버리는 더티 리드(Dirty Read)나, 데이터를 동시에 고쳐서 한쪽 수정사항이 사라지는 갱신 손실(Lost Update) 현상이 발생하게 됩니다. 락은 이를 막아주는 울타리 역할을 합니다.

 

 

MSSQL은 데이터의 일관성과 동시 처리량 간의 균형을 맞추기 위해 5가지 트랜잭션 격리 수준(Isolation Level)을 제공합니다.

격리 수준이 높아질수록 데이터 정합성은 강력해지지만 락(Lock)의 범위와 유지 시간이 길어져 동시성이 떨어집니다.

 

5가지 트랜잭션 격리 수준(Isolation Level)

격리 수준 (Isolation Level)	읽기 작업 시 락 동작 (Shared Lock)	쓰기 작업 시 락 동작 (Exclusive Lock)	발생 가능한 문제
1. Read Uncommitted	공유잠금(Shared Lock) X (다른 X Lock 무시)	Exclusive Lock 발생	Dirty Read, Non-Repeatable Read, 유령읽기(Phantom Read)
2. Read Committed (기본값)	다른 트랜잭션이 커밋한 내용만 읽음. 읽는 순간에만 S Lock 읽기가 끝나면 즉시 해제	Exclusive Lock 발생 (커밋 시 해제)	Non-Repeatable Read, Phantom Read
3. Repeatable Read	읽은 데이터에 S Lock 트랜잭션이 끝날 때까지 유지	Exclusive Lock 발생 (커밋 시 해제)	Phantom Read
4. Serializable	읽은 범위(Range) 전체에 Range Lock 트랜잭션 끝까지 유지	Exclusive Lock / Range Lock 발생	부정합 현상 없음 (동시성 최하) -> 모든 문제를 방지하지만, 동시성이 가장 낮습니다.
5. Snapshot	락을 사용하지 않음 (tempdb의 Row Versioning 활용)	Exclusive Lock 발생	Snapshot isolation conflict 발생 가능

 

• Non-Repeatable Read : 한 트랜잭션 안에서 같은 조회를 두 번 수행할 때 중간에 다른 트랜잭션이 데이터를 수정/커밋하면 값이 달라짐