이전 글 : Serializability 란? [ https://techforme.tistory.com/57 ]
이전 글에서 트랜잭션의 동시성 제어중 Serializability 에 대해서 알아 보았다. 이를 통해 Serializability를 보장하도록 Transaction 을 스케줄링 함으로써 Non-Serial 한 트랜잭션 처리의 결과를 Serial 하도록 만들 수 있었다.
그러나 해당 글에서는 Transaction 이 Rollback 되는 상황을 고려하지 않았는데, Transaction 은 어떠한 경우에서도 오류가 발생하였을 때 Rollback 을 통해 이를 안전하게 되돌릴 수 있도록 보장되어야 한다. (Recoverable) 이번 글에서는 이러한 Recoverable 특성과 관련하여, Transaction 이 시작되기 이전의 상태로 회복(Recover) 될 수 있으려면 어떠한 조건을 만족하여야 하는지를 알아볼 것이다.
1. Recoverability 란?
1) Unrecoverable schedule
Transaction 처리 스케줄이 안전한 Rollback 을 보장할 때 이를 Recovable 이라고 부를 수 있다. Unrecoverable Schedule 이란 '회복 불가능한 스케줄' 이라고 직역될 수 있으며, Transaction Schedule 이 Rollback 으로 인해 예상치 못한 결과를 낳을 때 이를 Unrecoverable 하다고 할 수 있다. 아래 예시를 보자.
Transaction A : Value 에 10 을 뺀다.
Transaction B : Value 에 10을 더한다.
위와 같은 경우 정상적으로 Transaction A 가 롤백되면 Transactino B 만 수행되어 Value 는 30이 되어야 한다. 그러나 Transactino A 이 롤백되면서, A 는 기존의 값인 20 으로 덮어 씌워져 버린다. (참고로 Transactino A 가 롤백이 되면 Undo 로그에 저장된 원래의 값을 복원하는 식으로 동작한다.)
+)
위 상황은 커밋되지 않은 값을 읽었다고 하여 Dirty Read 라고 불린다. 이를 해결하기 위해서는 트랜잭션 격리 수준을 Read Commited 로 설정하면 된다. Read Commited 로 설정하게 되면 Transaction A 가 커밋 되기 전에는 Value 값의 변경 사항을 읽지 않고 undo 로그에서 이전의 값을 읽어온다.
그러나 트랜잭션 격리 수준을 Read Commited 로 설정한다고 해도, Transaction A 와 Transaction B 가 모두 업데이트를 성공 하게 되면 결국 Lost Update 가 발생하게 되는데, 이는 이전편에서 이야기했듯 Repeatable Read 로 해결할 수 있다.
2) Recoverable Schedule 의 조건
그러면 Transaction 이 동시적으로 처리되는 상황에서도 Recover 가 가능하도록 하려면 어떻게 Transaction 을 스케줄링 해야할까? 한 Transacion 의 Rollback 으로 인한 영향 안에, 다른 Transaction 이 Commit 하지 않도록 해야한다. Rollback 안에 다른 Commit 이 없다면, 공유 자원이 다른 Transaction 과 상호작용을 했다고 하더라도 해당 Transaction 또한 Rollback 시키면 되기 때문이다. (이렇게 되면 Rollback 이 연쇄적으로 일어나게 되는데 이를 Cascading Rollback 이라고 한다.)
3) Cascadeless schedule
실제로 Cascading Rollback 을 통한 Recover 는 많은 Resource 를 요하는 작업이기 때문에 이러한 상황을 만들지 않는 것이 좋다. 이를 해결하기 위한 스케줄 조건이 Cascadeless 인데, 이는 아예 특정 Transaction 이 Write 하는 자원을 Read 하지 않고, 해당 Transaction 이 Commit 이나 Rollback 이 될 때까지 기다려서, Rollback 의 영향권에 들어가지 않는 방법을 말한다. 이를 Cascadeless 한 스케줄링이라 한다.
위에 '읽지 않고' 라는 부분에 밑줄을 친 이유가 있다. Cascadeless Schedule 의 조건에는 Write 된 자원에 대한 Read 접근은 제한하지만, Write 접근은 제한하지 않기 때문이다. 이 때문에 특정 자원에 곧바로 Write 연산을 시행하게 되면 또 다시 문제가 생기게 되는데, 아예 Write 까지 제한시키는 스케줄링을 Strict Schedule 이라 부른다.
2. 결론
이전 글에서 Serializability, 이번 글에서 Recoverablity 라는 특성을 다루어 보았다. 이 두가지 특성은 Transaction 의 Isolation 조건을 규정하는 두가지 큰 개념이라고 할 수 있는데, 다시말해 Serializability, Recoverability 와 관련하여 적절한 정책(?) 을 채택함으로써, Isolation 의 level 을 결정지어 Concurrency 와 Consistency 를 컨트롤 할 수 있다고 하는 것이다.
