비연쇄적 스케줄(Cascadeless Schedule)

데이터베이스 트랜잭션 관리에서 비연쇄적 스케줄(Cascadeless Schedule)은 시스템의 장애나 오류 발생 시, 하나의 트랜잭션 취소(Abort)가 다른 트랜잭션들의 연쇄적인 취소로 이어지는 '연쇄 복귀(Cascading Rollback)' 현상을 방지하기 위해 고안된 스케줄링 방식입니다.

---

1. 비연쇄적 스케줄의 핵심 원리

비연쇄적 스케줄의 규칙은 매우 단순하면서도 강력합니다.

• 원칙: 어떤 트랜잭션이 데이터를 읽을 때, 반드시 '이미 커밋(Commit)이 완료된' 트랜잭션이 기록(Write)한 데이터만 읽도록 허용합니다.
• 즉, 아직 커밋되지 않은 중간 상태의 데이터(Dirty Data)를 다른 트랜잭션이 읽는 것(Dirty Read)을 원천적으로 차단합니다.

2. 왜 비연쇄적 스케줄이 필요할까? (연쇄 복귀의 문제점)

비연쇄적 스케줄이 적용되지 않은 상태에서 발생할 수 있는 '연쇄 복귀'의 위험성을 살펴보겠습니다.

• 상황: 트랜잭션 T_1이 데이터 X를 수정하고 아직 커밋하지 않았습니다. 이때 트랜잭션 T_2가 수정된 데이터 X를 읽어 작업을 수행하고 커밋했습니다.
• 문제 발생: 만약 T_1에 오류가 발생해 롤백(Rollback)을 해야 한다면 어떻게 될까요?
• 결과: T_1이 취소되면 T_1이 남긴 잘못된 데이터를 기반으로 작업한 T_2 역시 취소되어야 합니다. 만약 T_2의 결과를 T_3가 읽었다면 T_3도 취소되어야 합니다. 이렇게 도미노처럼 롤백이 이어지는 현상이 연쇄 복귀이며, 이는 시스템 자원과 시간을 엄청나게 낭비하게 만듭니다.

3. 작동 방식 비교 (예시)

동일한 트랜잭션 상황에서 '일반 스케줄'과 '비연쇄적 스케줄'이 어떻게 다르게 동작하는지 표로 비교해 보겠습니다.

시간 흐름	일반적인 스케줄 (연쇄 복귀 위험 O)	비연쇄적 스케줄 (연쇄 복귀 위험 X)
t_1	T_1: 데이터 X 쓰기 (Write)	T_1: 데이터 X 쓰기 (Write)
t_2	T_2: 데이터 X 읽기 (Read) ⚠️ 커밋 전 읽기 허용	T_2: 데이터 X 읽기 시도 ⛔ 대기 (Wait)
t_3	T_2: 작업 수행 후 커밋 (Commit)	T_1: 커밋 (Commit) 완료
t_4	T_1: 오류 발생 ➔ 롤백 (Rollback)	T_2: 데이터 X 읽기 (Read) ✅ 안전하게 읽기
결과	T_1 롤백으로 인해 T_2도 강제 롤백 (연쇄 복귀 발생)	T_1만 롤백되거나, T_1 정상 종료 후 T_2가 안전하게 실행됨

4. 비연쇄적 스케줄의 주요 특징

• 회복 가능성(Recoverability) 보장: 모든 비연쇄적 스케줄은 시스템에 장애가 발생했을 때 이전의 일관된 상태로 돌아갈 수 있는 '회복 가능한 스케줄(Recoverable Schedule)'의 부분집합에 속합니다.
• 성능과의 트레이드오프: 데이터를 읽기 위해 다른 트랜잭션의 커밋을 기다려야 하므로 동시성(Concurrency)은 다소 떨어질 수 있지만, 복구에 드는 엄청난 비용을 예방하여 시스템의 안정성을 극대화합니다.
• 구현 방식: 주로 엄격한 2단계 로킹(Strict 2PL) 프로토콜 등을 통해 트랜잭션이 완료될 때까지 쓰기 잠금(Write Lock)을 유지하는 방식으로 구현됩니다.