RDB 공유 잠금 기능

1. 개요

---

오늘 팀 단톡방에 좋은 질문이 올라와 읽던 중 공유

 

 

2. 질문

---

- 공유 잠금 기능이 MSSQL 만의 기능인가?

-> "MSSQL 은 기본적으로 SELECT 시 공유잠금(S Lock) 이 걸린다. 이는 MSSQL 의 기본 격리수준(Isolation Level) 이 Read Committed 이기 때문이다. 즉, DML(INSERT, UPDATE, DELETE) 작업중인 ROW 또는 TABLE 에 SELECT 할 경우, 해당 작업이 끝나야 SELECT 할 수 있다는 의미이다.

 

 

 

3. 답변

---

 - DBMS 마다 lock 정책이 다르지만, 공유잠금이란 개념은 모두 존재

- MSSQL 은 read commited 정책을 도입함

- 아래 내용은 read lock 이 왜 생기게 되었는지, 이를 해결하기 위해선 어떤 방법을 써야 하는지 추가적으로 그 방법을 쓸 경우에는 무엇을 주의해야되는지에 대한 설명

일반적으로 디폴트 값이 1. 즉, recommited 이고 commit 된 데이터만 읽기 위해서, select도 lock, 즉 read lock을 겁니다. 그래서, 이런 표준을 지키는 디비들은 매우 느리거나 장애 나는 경우가 많음.

특이하게 오라클이 처음으로 MVCC라는 비표준 방식으로 데이터 정합성을 해결했는데,

오라클은 commit되기 전 값을 rollback segment에 저장하고, 롤백되기 전 값을 다른 놈이 읽어야 할때, 이 rollback segment에 있는 before image를 일게 만들어서 성능이 매우 좋았음.

이게 유행이 되서 , 여기 저기 디비들이 MVCC를 지원하기 시작했음. 그래서 MVCC를 지원하는 디비들에서는 isolation level이란 의미가 예전 ANSI 표준에서 의미하는것과 많이 달라짐. 그래서, MS SQL도 MVCC를 지원하는 모드가 있기는 하나, 자신들도 추천 하지는 않음. MS SQL에서 MVCC를 쓰지 않고, 저런 read lock문제를 해결할려면, isolation level 0, 즉, dirty read를 써야함. 이걸 쓰면, 커밋되지 않은 되이터를 읽게 됨.

실제 대부분의 OLTP에서는 commit 대비, rollback의 비율이 작아서 큰 의미에서느 문제가 안되나,

반듯이 정합성을 필요로 하는 데이터는 최소 isolation level 1로 읽어야 함.

동기화 지연이 발생하는 read only 노드를 쓰면, 약간의 이전 데이터를 읽는 위험이 있어서, 이거 허용되는 업무에서만 read olny 노드를 읽어야 하는것 처럼. dirty read 를 허용 하는 업무도 아주 신중하게 선택 해야 함.

isolation level은 세션 단위로도 바꿀수 있음.

그래서 여러 데이터 저장소 중에, MVCC를 지원하는 것은, ACID를 엄격하게 보장하는 RDB에만 있는 피처임.