[DB] Recoverability

Unrecoverable Schedule

트랜잭션 간의 의존성으로 인해, 일부 트랜잭션이 롤백될 때 데이터베이스가 이전의 일관된 상태로 복구될 수 없는 상황을 의미한다. 이러한 스케줄이 발생하면 데이터 일관성에 심각한 문제가 생길 수 있으므로, DBMS는 Unrecoverable Schedule을 허용해서는 안 된다.

예시

• T1이 데이터를 변경한다.
• T1이 커밋하기 전에 T1이 변경한 데이터를 읽고 T2가 커밋한다.
• T1이 어떤 이유로 롤백되면, T2가 읽어 간 데이터는 잘못된 데이터가 되고, T2의 결과는 잘못된 데이터에 기반하게 된다. T2는 이미 커밋되었기 때문에, T1을 롤백한다고 하더라도 전체 시스템의 일관성을 회복할 수 없게 된다.

 

Recoverable Schedule

스케줄 내에서 트랜잭션은 자신이 읽은 데이터를 작성한 트랜잭션이 먼저 커밋/롤백하기 전까지는 커밋하지 않는다. 롤백할 때 이전 상태로 온전히 돌아갈 수 있기 때문에 DBMS는 이런 스케줄만 허용해야 한다.

예시

1. T1이 데이터를 변경하고 커밋하지 않은 상태에서, T2가 T1의 변경된 데이터를 읽는다.
2. T2는 T1이 먼저 커밋을 완료할 때까지 기다린 후, 커밋을 진행한다.
3. 이 경우, 만약 T1이 롤백되면 T2도 롤백될 수 있으므로, 데이터베이스의 일관성을 유지할 수 있다.

 

Cascadeless Schedule

Recoverable Schedule의 특성을 더욱 강화한 스케줄로, 롤백으로 인한 연쇄적인 트랜잭션 롤백(cascading rollback)을 방지한다. 이 스케줄에서는 트랜잭션이 다른 트랜잭션이 커밋되기 전에 해당 트랜잭션이 변경한 데이터를 읽지 않도록 제한한다. 이를 통해 하나의 트랜잭션이 롤백될 때 다른 트랜잭션에도 영향을 미치는 상황을 피할 수 있다.

예시

1. T1이 가격을 1만 원으로 변경한다.
2. T2는 T1이 커밋되기 전에 가격을 2만 원으로 변경하고 커밋한다.
3. 이후 T1이 롤백된다.
4. 최종적으로 가격은 T1의 롤백으로 인해 초기값으로 복원된다.

이 예시는 Cascadeless Schedule에서도 T2가 T1의 변경을 읽지 않고 바로 덮어썼기 때문에 발생할 수 있는 상황을 보여준다. Cascadeless Schedule은 읽기 연산에 대해 제한을 가하지만, 쓰기 연산은 그대로 허용되기 때문에 이런 문제가 발생할 수 있다.

 

Strict Schedule

가장 엄격한 트랜잭션 스케줄링 방식으로, Cascadeless Schedule보다 더 강한 제한을 둔다. 이 스케줄에서는 어떤 트랜잭션이 데이터를 읽거나 쓸 때, 해당 데이터에 대한 이전 트랜잭션이 완료되기 전까지 다른 트랜잭션이 그 데이터를 읽거나 쓸 수 없다. 즉, 이전 트랜잭션이 커밋되거나 롤백된 후에만 데이터 접근이 허용된다.

예시

1. T1이 데이터를 변경한 후 커밋할 때까지, 다른 모든 트랜잭션(T2 등)은 해당 데이터에 접근하지 못한다.
2. T1이 커밋을 완료하면, 그 후에야 T2가 데이터를 읽거나 쓸 수 있다.
3. 이 방식에서는 롤백이나 커밋 전까지 어떤 트랜잭션도 다른 트랜잭션의 데이터에 접근할 수 없기 때문에, 데이터베이스의 일관성이 가장 강하게 보장된다.