Recoverability

Recoverable Schedules

동시에 실행중인 트랜잭션 중 하나에 failure 이 발생할 때의 영향을 고려해야 한다.

Recoverable schedule - 트랜잭션 Tj 가 Ti 에 의해 Write 된 데이터를 읽는다면, Ti 가 commit 하기 이전에 Tj 가 먼저 commit 을 해야한다.

-> 값을 write 하는 트랜잭션은 반드시 값을 Read하는 트랜잭션보다 먼저 commit 되어야 한다.

T8 에서 rollback 이 일어나면, T8 이 commit 을 하기 전에 T9 가 먼저 commit 을 한 상태이므로 복구가능하지 않다. 

-> database inconsistent 

 

Cascading Rollbacks

하나의 트랜잭션이 failure 하게 된다면, 연속된 트랜잭션의 rollback 이 일어나게 되는 것이다. 

-> undo 작업은 상당히 많은 시스템 작업량을 요구한다.

T10 트랜잭션에서 failure 이 일어나면 T11과 T12는 Rollback이 되어야 한다. 이것이 Cascading rollback이다.

-> 모든 트랜잭션이 commit 되지 않은 상태이므로 스케줄은 recoverable 하다.

 

Cascadeless schedule (avoid cascading aborts, ACA)

cascading rollback 이 발생할 수 없는 스케줄이다.

Ti 가 먼저 write 한 데이터를 이후에 Tj 가 읽는다면, Tj 가 데이터를 읽기 전에 Ti 는 commit 연산을 한다.

-> 트랜잭션은 항상 commit 된 데이터만을 읽게 된다.

Cascadeless schedule은 모두 Recoverable하다.

 

Relationship Between Histories

write(x) 혹은 read(x) 연산 이전에 write(x) 가 수행된다면, 그 사이에는 반드시 abort 나 commit 이 존재해야 한다.

이를 strict(ST) 라고 한다.

database 에서 요구되는 바람직한 schedule 은 serializable schedule 이면서 ACA, RC 인 스케줄이다.

SR, ST 는 너무 엄격하다.

 

ex) ACA 이지만 ST 가 아닌 스케줄

-> read 이전에 write 를 한다면 반드시 commit 을 해야함. 

ST 를 만족시키려면, T2 가 Write(X) 를 하기 전에 T1 이 commit 을 해야 했다.

 

Concurrency Control

데이터베이스가 동시성 제어를 하려면 다음과 같은 메커니즘을 제공해야 한다.

- conflict serializable
- view serializable

- 하나의 트랜잭션 만이 한 시점에서 실행될 수 있다는 정책은 serial schedule 을 생성하지만, concurrency 차원에서 성능이 좋지 않다.

- 스케쥴을 실행한 뒤에 serializability 를 테스트 하는 것은 너무 늦다. 따라서 Concurrency control protocol 이 존재한다.

 

Concurrency control protocol 은 동시에 실행되는 트랜잭션 스케줄을 허용한다.

그러나 그 스케줄들은 conflict/view serializable 을 보장해야 한다. 또한 recoverable, cascadeless 해야 한다.