16. Concurrency control 기초 2부 : recoverability

본 내용은 유튜버 쉬운코드의 강의 "데이터베이스"를 참고하여 작성하였습니다.

 

unrecoverable schedule

20만원을 K -> H로 이체하는 상황에서 H가 본인 계좌에 30만원을 입금하는 상황

• 20만원을 K 계좌에서 출금하고 /  30만원을 입금하고 / 20만원을 H 계좌에 입금한다.
• 그런데 transaction 2(tx2)에서 문제가 생겨서 rollback을 하여 H 계좌를 200만원으로 돌려둔다.
• tx2는 더 이상 유효하지 않으므로 tx2가 write 했던 H_balance를 읽은 tx1도 rollback 해야 한다.
• 하지만 tx1은 이미 commit을 하여 DB에 영구적으로 저장이 됨. (transaction의 속성 Durability)

 

• uncoverable schedule : schedule 내에서 commit 된 transaction이 rollback된 transaction이 write했었던 데이터를 읽은 경우
• rollback을 해도 이전 상태로 회복 불가능할 수 있기 때문에 이런 schedule은 DBMS가 허용하면 안된다.
• 그러면 어떤 schedule이 recoverable 한가?

---

recoverable schedule

• tx2가 먼저 commit 하고 tx1을 commit 해야 함.
• tx2가 rollback 해야 하는 상황이면 tx1을 abort 하고 tx2도 abort 함.

-> tx1이 tx2에 의존하고 있으므로 tx2를 먼저 종료시키고 tx1을 종료해야 한다.

 

recoverable schedule : schedule 내에서 그 어떤 transaction도 자신이 읽은 데이터를 write한 transaction(의존하고 있는 것)이 먼저 commit/rollback 전까지는 commit 하지 않는 경우

• rollback할 때 이전 상태로 온전히 돌아갈 수 있기 때문에 DBMS는 이런 schedule만 허용해야 한다.

---

cascading rollback

• 하나의 transaction이 rollback하면 의존성이 있는 다른 transaction도 rollback 해야 한다.
• 여러 transaction의 rollback이 연쇄적으로 일어나면 처리하는 비용이 많이 든다.

-> 데이터를 write한 transaction이 commit/rollback 한 뒤에 데이터를 읽는 schedule만 허용하자! (위의 사진에서는 w2(H) 하고 이를 읽으려고 할 때(r1(H)) tx2를 완료하고 난 이후에 가능하게 하자!)

---

cascadeless schedule

• schedule 내에서 어떤(any) transaction도 commit 되지 않은 transaction들이 write한 데이터는 읽지 않는 경우

---

strict schedule

H가 수행한 tx2가 tx1을 rollback하면서 사라짐

• 위의 schedule은 cascadeless schedule임에도 rollback 했을 때 문제가 생김

-> strict schedule : schedule 내에서 어떤 transaction도 commit 되지 않은 transaction들이 write한 데이터는 쓰지도 읽지도 않는 경우

strict schedule

 

• rollback 할 때 recovery가 쉽다. transcation 이전 상태로 돌려놓기만 하면 된다.

---

최종 정리

• unrecoverable schedule은 rollback했을 때 이전 상태로 복구할 수가 없으므로 RDBMS에서 허용하면 안됨.
• cascadeless schedule은 commit 되지 않은 transaction을 쓰지 않는 schedule
• strict schedule은 commit 되지 않은 transaction을 쓰지도 읽지도 않는 schedule

• concurrency control provides serializability & recoverability(isolation과 관련)