DBMS는 어떻게 트랜잭션을 관리할까?
데이터베이스 KOCW
Transaction
Transaction
- 쪼갤 수 없는 업무처리 최소 단위를 말한다.
- cocurrency control(동시성 제어)를 하는데 쓰이는 개념
- DBMS는 log를 유지하며 문제가 생기면 log를 통해 recovery
- recovery는 consistency를 유지하는데 도움을 줌
- consistency : 모두 update or 모두 update x
- inconsistency : 일부만 update
- 기본적으로 각각의 SQL문은 하나의 transaction
- 여러개의 SQL문을 transaction으로 사용하려면 사용자가 정의해야함
Transaction의 특성(ACID)
- Atomicity
- all or nothing : transaction이 모두 수행되거나 모두 수행되지 않거나
- transaction은 log로 기록된다.(commit 여부까지도)
- transaction이 일부만 수행되고 failure하는 경우에는 log를 활용하여 수행한 것을 undo함으로써 원자성을 보장함
- DBMS 의 recovery module에 의해 보장됨
- Consistency
- 어떤 transaction이 수행하기 전의 상태가 consistent하다면 그 후의 상태도 consistent한 상태이다.
- transaction이 수행중인 상태는 inconsistent한 상태를 가질 수 있다.
- DBMS의 concurrency control module, 무결성 제약조건에 의해 보장됨
- Isolation
- 동시에 수행중인 transaction간의 상호간섭을 하면 안된다.
- DBMS 응용사항에 따라 Isolation level(높으면 동시에 덜 수행)을 제공함
- DBMS의 concurrency control module에 의해 보장됨
- Durability
- transaction이 commit되면 failure가 발생하더라도 절대로 손실되어서는 안된다.
- DBMS 의 recovery module에 의해 보장됨
commit, abort
- commit
commit한 transaction의 변경사항은 데이터베이스에 반영된다는 것을 보장 - abort
transaction의 변경사항을 철회(원상복구)하는 것을 의미. 이 경우 log에 기록된 Old value로 rollback하는 undo과정이 필요함
DBMS의 기능(ACID를 지키기 위한)
Concurrency control
- 동시에 read (O), Conflict의 위험으로 동시에 write(X)
- shared resource를 어느 level(value, tuple, relation..)까지 허용할 것인가
- 가능한 작은 단위의 정보까지 공유하는 것이 목표
- serializable한 non-serial schedule을 수행하는 것(어떤 규칙을 통해서)
serial schedule: transaction을 한번에 하나씩만 수행
non-serial schedule: 동시에 여러개의 transaction을 수행
serializable: non-serial schedule의 결과가 serial schedule 의 결과와 같을때 이러한 non-serial schedule이 serializable하다고 함
동시성 제어를 하지 않으면
- lost update : update 내용이 날라감
a=1 일때 a++/a-- 가 동시에 수행되면 둘중에 먼저 완료된 update는 lost - dirty read : 종료되지 않은 transaction(갱신이 불투명한)이 update한 결과를 읽어오는 것
- unrepeatable read : 한 transaction이 동일한 data를 두번 읽을때 서로 다른 값을 읽을 가능성이 있음
동시성 제어의 방법 (Lock)
- 접근하려는 resource에 lock을 걸어 동시성을 제어할 수 있다.
- lock table을 통해 관리함
- 독점 lock(X-lock, eXclusive), 공유 lock(S-lock, Shared) 이 존재
- X-lock은 write를 할때 필요하며 해당 resource에 대한 lock의 발급을 막음
- S-lock은 read를 할때 필요하며 해당 resource에 대한 X-lock의 발급만 막음
- 병렬성을 위해선 unlock을 최대한 빨리 하는 것이 좋다. 하지만 일반적으로 commit할때 unlock을 함
- lock을 하는 것만으로 dirty read, unrepeatable read를 막지는 못함
- 2-page locking protocol로 해결 가능
- lock을 얻는 단계와 unlock하는 단계를 나눔
- lock을 얻는 단계에서는 오직 lock을 얻을 수 있고 unlock을 하는 단계에는 unlock만 할 수 있음
- unlock은 commit할때 한번에 하는것이 일반적임
- 단점으로는 dead lock의 가능성이 존재(victim을 선정하여 해결, 다른 방법도 존재)
다중 lock 단위(multiple granuality)
- 하나의 transaction이 lock할 수 있는 데이터의 항목이 2개이상이면 다중 lock 단위라고 함
- lock의 단위는 다양함(DB-relation-disk block-tuple)
- lock의 단위는 system이 transaction을 분석해서 알아서 결정한다.
- lock의 단위가 작아지면 병렬성은 높아지지만 locking에 대한 overhead는 증가함
phantom problem
- 현재 존재하지 않는 tuple에 lock을 걸 수 없다.(insert 하는 상황)
- lock을 Index에 걸어서 해결할 수 있음(Index가 있고, Index와 관련되면)
...
Recovery module
- log를 저장하여 redo,undo 작업을 수행하는 것이 일반적임(log based recovery)
- 그래서 log가 중요함. log를 중복 저장하는 것이 중요(RAID를 활용하면 해결할 수 있음)
- log를 기반으로한 즉시 갱신이 일반적임
- = transaction이 완료되기 전에 DB에 반영가능
- DB 내용에 영향을 주는 모든 transaction은 log record에 기록됨
- 각 log record는 LSN(Log Sequence Number)로 식별됨
- Recovery 관련 더 자세한 내용 : DBMS는 어떻게 트랜잭션을 관리할까?
