Recoverability
이 포스트를 이해하시려면
schedule과 serializability에 관한
이해가 필요합니다.
이전 포스트와 동일한 예제인
K가 H에게 20만원을 이체할 때,
H도 본인 계좌에 30만원을 입금하는 경우
이번 글에서도 활용하도록 하겠습니다.
Unrecoverable schedule
K가 20만원을 이체하는 와중에 H가 30만원을 입금했다.
그리고 H의 트랜잭션이 커밋된 이후
K의 트랜잭션이 롤백 된 상황이 발생했다.
하지만 H의 트랜잭션은 이미 K의 트랜잭션에서
값을 읽고 데이터를 커밋한 상태이다.
즉, Durability 속성에 의해 rollback을 할 수 없다. 데이터 불일치가 발생했기 때문이다.
정리하면 스케줄 내에서 커밋된 트랜잭션이
롤백된 트랜잭션이 Write한 데이터를 읽은 경우를
Unrecoverable schedule이라고 한다.
이때는 rollback을 해도
이전 상태로 회복이 불가능 할 수 있기 때문에
이런 schedule은 DBMS가 허용하면 안된다.
Recoverable schedule
스케줄 내에서 그 어떤 트랜잭션도
자신이 읽은 데이터를 write한 트랜잭션이
먼저 commit/rollback 전까지는
commit하지 않은 경우를 말한다.
위의 그림에서 이미 작업은 모두 완료된 상태이다.
다만 커밋 순서가 중요하다.
커밋 순서에 따라 회복가능한 스케줄인지,
혹은 불가능한 스케줄인지가 결정되기 때문이다.
1번 트랜잭션은 2번 트랜잭션에 의존하고 있는 상태이다.
이 상태에서는 1번 트랜잭션이 먼저 커밋이 되어야 한다.
만일, 2번 트랜잭션이 롤백 되어야 하는 상황이 발생하면
1번 트랜잭션이 2번에 의존성이 있기 때문에
함께 롤백 되어야 한다.
즉, 의존성이 있는 트랜잭션은
의존하는 트랜잭션이 커밋/롤백될 때까지
커밋/롤백을 하면 안된다.
cascading rollback
하나의 트랜잭션이 롤백하면
의존성이 있는 다른 트랜잭션도 롤백 하는 것
하지만 cascading rollback은
여러 트랜잭션의 롤백이 연쇄적으로 일어나면
처리하는 비용이 많이 든다.
각각을 트랜잭션 시작 이전으로 돌려야하기 때문이다.
그렇다면 이렇게 비용이 발생하는 문제를
어떻게 해결할 수 있을까?
-> 데이터를 write한 트랜잭션이
commit/rollback한 뒤에
데이터를 읽는 스케줄만 허용하자.
Cascadeless schedule
(= avoid cascading rollback)
스케줄 내에서 어떤 트랜잭션도
커밋되지 않은 트랜잭션들이 write한 데이터는
읽지 않는다.
데이터를 write한 트랜잭션이
commit/rollback한 뒤에
데이터를 읽는 스케줄만 허용 되면,
위처럼 트랜잭션 2번에 문제가 생겨서 롤백을 하더라도
트랜잭션 2번에 의존하는 트랜잭션이 없기 때문에
2번만 롤백하면 된다.
즉, 연쇄적인 롤백이 없기 때문에 비용이 줄어든다.
Strict schedule
스케줄 내에서 어떤 트랜잭션도
commit되지 않은 트랜잭션들이
write한 데이터는 쓰지도 읽지도 않는 경우
가장 엄격한 스케줄이다.
위와 같이 피자가격이 3만원일 때,
K가 피자가격을 1만원 낮추려하고
H가 피자가격을 2만원 낮추는 상황이 발생했다.
여기서는 read는 발생하지 않았고, write만 발생했다.
즉, Cascadeless schedule이다.
하지만, 동시에 write할 때,
K의 트랜잭션이 롤백되면 원치 않게
H의 트랜잭션도 함께 롤백되는 상황이 발생한 것이다.
이러한 상황을 방지하기 위해
commit되지 않은 트랜잭션이 write하는 데이터는
읽는 것도, 쓰는 것도 막는 것이
Strict schedule이다.
아래와 같은 형태가 Strict schedule의 예시이다.
트랜잭션 1이 write하고 commit/abort를 한 후에
트랜잭션 2의 write가 진행되어야 한다.
이러한 스케줄은 롤백을 하기 쉽다.
각각의 트랜잭션이 시작하기 전으로 돌려놓으면 된다.
Recoverability 총정리
위와 같이 포함 관계로 생각하면 이해하기 편하다.
-
Recoverability schedule
스케줄 내에서 그 어떤 트랜잭션도
자신이 읽은 데이터를 write한 트랜잭션이
먼저 commit/rollback 전까지는
commit하지 않은 경우 -
Cascadeless schedule
스케줄 내에서 어떤 트랜잭션도
커밋되지 않은 트랜잭션들이 write한 데이터는
읽지 않는 경우 -
Strict schedule
스케줄 내에서 어떤 트랜잭션도
commit되지 않은 트랜잭션들이
write한 데이터는 쓰지도 읽지도 않는 경우
Concurrency Control
Concurrency Control은
Serializability와 Recoverability를
모두 제공하는 것이다.
그리고 이와 관련된 DB의 속성이 Isolation이다.
출처
