[데이터베이스] Chapter 17. Transaction
Reference
1. Database System Concepts-Abraham Silberschatz, Henry Korth, S. Sudarshan
2. Database System class by Professor Yon Dohn Chung, Department of Computer Science and Engineering, Korea University
Topic
- Transaction Concept
- Transaction State
- Concurrent Executions
- Serializability
- Recoverability
- Implementation of Isolation
- Transacton Definition in SQL
- Testing for Serializability
17.1 Transaction Concept
- data item을 접근하거나 수정하는 프로그램의 실행 단위
ACID
(1) Atomicity (원자성)
- All or Nothing
- 트랜잭션 작업이 부분적으로 실행되거나 중단되지 않음을 보장
- 트랜잭션의 모든 연산이 정상 수행 or 어떠한 연산도 수행되지 않은 상태
(2) Consistency (일관성)
- 트랜잭션이 성공적으로 완료되면, 일관적인 DB 상태를 유지한다.
- 올바른 logic 작업을 수행 중은 일시적으로 inconsistent 하지만 작업이 완료되면 다시 consistent해야 한다.
(3) Isolation (격리성)
- 트랜잭션 수행시 다른 트랜잭션의 작업이 끼어들지 못하도록 보장
- 트랜잭션끼리 서로를 간섭할 수 없다.
- 트랜잭션이 작업 중인 inconsistent한 DB를 다른 트랜잭션이 읽지 못하도록 해야 한다.
(4) Durability (지속성)
- 성공적으로 수행된 트랜잭션은 영원히 반영된다.
- commit 하면 현재 상태는 영원히 보장된다.
17.4 Transcation Atomicity and Durabuility
Transaction State
- Active : 초기화 상태, 트랜잭션이 수행 중인 상태이다.
- P*artially committed:* 마지막 statement가 수행된 이후의 상태
- Failed : 더이상 진행 불가능한 상태
- Aborted : 트랜잭션이 roll back되고 db가 원상복구 된 이후의 상태
- Committed : 성공적으로 트랜잭션이 끝난 상태
17.5 Transaction Isolation
Concurrent Executions
여러 트랜잭션이 시스템에서 동시에 실행되면 다음과 같은 장점이 있다.
- processor와 disk 이용률이 증가한다.
- 평균 응답 시간이 감소한다.
- Concurrency control schemes - isolation을 위한 메카니즘
- Schedule - 동시에 여러 개의 트랜잭션들이 병행 실행되는 경우, 연산들이 실행되는 순서
- commit : 작업 완료
- abort : 작업 실패
- 둘 다 모두 트랜잭션이 성공적으로 끝냈음을 의미한다
17.6 Serializability
(1) Serial schedule (직렬 스케줄)
- 한 트랜잭션을 구성하는 연산들이 모두 수행된 이후 다른 트랜잭션을 수행
- 오류는 없지만 성능이 안 좋다
↔ Concurrent schedule
(2) Serializable schedule
- Concurrent 스케줄이지만 serial schedule로 만들 수 있는 것
- consistency를 확인해야 한다
conflicting instructions
- read끼리는 충돌 x
- 그 외 나머지는 충돌 o → 순서를 바꾸면 작업 결과가 바뀐다.
- 만약 충돌이 일어나지 않는다면 실행 순서를 교환할 수 있다.
Conflict serializability
- 만약 스케줄 S를 non-conflicting한 교환으로 S’로 바꿀 수 있다면, 이들은 conflict equivalent
- 만약 S가 serial schedule과 conflict equivalent하다면, S는 conflict serializable 하다.
(5) View Serializability
View equivalent
S와 S`이 같은 트랜잭션의 집합을 스케쥴한 것이고, 다음 조건을 만족하면 View equivalent
- S가 읽은 Q의 초기값과 S`이 읽은 Q의 초기값이 같아야함
- S의 Tj가 write(Q)하고, Ti에서 read(Q) 했다면 S`또한 Tj 의 write(Q)를 먼저, Ti의 read(Q)가 나중에 수행되어야함 (순서가 중요)
- 어느 한 스케쥴이 최종 write를 했다면(디스크에 저장) 다른 스케쥴 또한 write를 해야함
Testing for Conflict Serializability
Precedence graph : 트랜잭션끼리의 방향 그래프 → 사이클 유무를 판단
- Ti와 Tj가 서로 conflict한 연산을 가지며 Ti가 먼저 data에 접근하면 Ti → Tj로 edge를 추가한다.
- 스케줄이 conflict serializable하다면, precedence graph는 acyclic하다.
- precedence graph가 acyclic하면, serializability order는 topological sorting을 통해 얻을 수 있다.
17.7 Transaction Isolation and Atomicity
(3) Recoverable Schedule
- recovery 가능한 스케줄로, 도중 실패시 원상 복구가 가능하다.
- T2가 T1이 write한 data를 read했다면, T2의 commit은 T1의 commit 이후에 있어야 한다.
⇒ T1이 commit 하기 전에 T2이 commit 한다면, data가 알맞은 값임을 보장할 수 없다.
- Durability를 지키는 것 (낙장불입)
Cascading rollback
- 하나의 트랜잭션의 실패가 연속적인 트랜잭션의 roll back으로 이어지는 것
- 성능 저하 및 자원 낭비
(4) Cascadeless schedules
- T2가 T1이 write한 data를 read 할 때는, T1의 commit 이후에 T2가 read 해야 한다.
- commit 한 것만 read 가능
- 모둔 cascadeless 스케줄인 모두 recoverable하다.
17.8 Transaction Isolation Levels
Transaction Isolation으로 나타나는 문제
(1) Drity Read
- 다른 트랜잭션에 의해 수정됐지만, 아직 commit되지 않은 data를 읽는 것
- T2가 T1이 처리한 data를 읽고 작업하는데 T1이 갑자기 roll back되면 T2는 잘못된 data로 작업
⇒ 오직 commit된 데이터만 읽도록 해서 해결해야 한다.
(2) Non-repeatable Read
- 한 트랜잭션 내에서 같은 key를 가진 record를 2번 읽었을 때 서로 결과가 다른 경우
- 1개의 row에 대해
(3) Phantom phenomenon
- 한 트랜잭션 내에서 같은 쿼리를 2번 수행했는데, 첫번째 쿼리에서 없던 유령 레코드가 나오는 현상
- 다수의 요청에 대해
Levels of Consistency
⇒ 각 트랜잭션 별로 지정이 가능하다.
(1) Serializable
- default
(2) Repeatable read
- 오직 commit된 record만 read가 가능하다.
- 같은 record를 read할 때 똑같은 값을 리턴해야 한다.
- serializable하지 않을 수 있다.
(3) Read committed
- 오직 commit된 record만 read가 가능하다.
- 하지만 같은 record를 연속으로 read할 때, 다른 값이 나올 수 있다.
(4) Read uncommitted
- commit되지 않은 record도 read 가능
Implementation of Isolation Levels
- Locking: shared lock vs exclusive locks
- Timestamps : Read timestamps, write timestamps
- Multiple versions of each data item (snapshot)