Schedule Recoverablity
Schedule Recoverablity
Schedule Recoverability
- concurrency control을 위해서는 schedule이 serializable해야 하고, recoverable해야 한다.
- schedule이 serializable하다는 것은 schedule 내의 트랜잭션들이 서로 독립적으로 실행되어 일관성 있는 상태로 실행된다는 것을 의미한다.
- schedule이 recoverable하다는 것은 트랜잭션이 rollback되었을 때, 이전 상태로 회복할 수 있는 것을 의미한다.
- schedule이 recoverable하지 않으면 트랜잭션이 rollback되었을 때, 이전 상태로 회복할 수 없기 때문에 데이터베이스의 일관성이 깨질 수 있다.
Unrecoverable Schedule
- rollback을 해도 이전 상태로 회복 불가능할 수 있는 schedule을 unrecoverable schedule이라고 한다.
- rollback을 해도 이전 상태로 회복 불가능할 수 있기 때문에 이런 schedule은 dbms에서 허용하지 않는다.
schedule내에서 transaction T1이 write한 데이터를 transaction T2가 read하고 T2가 commit된 후 T1이 rollback되는 경우. T2은 rollback되어 유효하지 않은 데이터를 읽고 커밋했지만, 이미 commit되었기 때문에 rollback할 수 없다. (commit된 데이터는 durability 속성에 의해 영구적으로 저장되기 때문에 rollback할 수 없다.)
Recoverable Schedule
- unrecoverable schedule을 방지하기 위해 recoverable schedule을 사용한다.
- schedule 내에서 그 어떤 transaction도 자신이 읽은 데이터를 write한 transaction이 먼저 commit/rollback하기 전까지 commit하지 않는다면 recoverable하다. (recoverable schedule)
- rollback시 이전 상태로 온전히 돌아갈 수 있기 때문에 dbms는 이런 schedule을 허용한다.
Cascadeless Schedule
- 하나의 transaction이 rollback하면 의존성이 있는 다른 transaction도 rollback하는 것을 cascade rollback이라고 한다. cascade rollback은 recoverable하지만 비용이 크고, 때문에 cascade rollback을 방지하는 schedule을 cascadeless schedule이라고 한다. (cascading schedule vs cascadeless schedule)
- 데이터를 write한 transaction이 commit/rollback한 뒤에만 다른 transaction이 그 데이터를 읽을 수 있도록 하면 cascade rollback을 방지할 수 있다. 이런 schedule을 cascadeless schedule이라고 한다. (커밋 전 읽기 금지)
Strict Schedule
- cascadeless schedule 의 경우에도 write 연산이 commit 되기 전에 다른 transaction이 그 데이터를 쓸 수 있기 때문에 이상한 결과가 나올 수 있다. 이런 문제를 방지하기 위해 strict schedule을 사용한다. (커밋 전 읽기, 쓰기 모두 금지)
- schedule 내에 어떤 transaction도 commit되지 않는 transaction들이 write한 데이터를 읽지도 쓰지도 않는다면 strict schedule이다.
- strict schedule은 rollback할 때 recovery가 쉽다
This post is licensed under CC BY 4.0 by the author.