Computer >> 컴퓨터 >  >> 프로그래밍 >> SQL

지연된 업데이트 복구:안정적인 데이터 무결성을 위해 NO-UNDO 및 REDO 사용

지연 업데이트 복구에서는 트랜잭션이 커밋될 때까지 디스크의 실제 데이터베이스 수정이 연기됩니다. 업데이트는 실행 중에 로그 및 캐시 버퍼에만 기록됩니다. 커밋 전에 트랜잭션이 실패하면 디스크의 데이터베이스는 영향을 받지 않으므로 UNDO가 실행되지 않습니다. 변경 사항이 디스크에 기록되지 않은 커밋된 트랜잭션에는 REDO만 필요합니다.

지연 업데이트 프로토콜

  • 트랜잭션은 커밋 지점에 도달할 때까지 디스크의 데이터베이스를 수정할 수 없습니다.
  • 모든 REDO 로그 항목은 커밋하기 전에 디스크에 강제로 기록되어야 합니다(Write-Ahead Logging).
  • REDO 로그 항목(새 값/AFIM)만 필요하며 UNDO 항목은 필요하지 않습니다.

복구 절차(RDU_M)

엄격한 2단계 잠금을 사용하는 다중 사용자 시스템의 경우 복구 알고리즘은 두 개의 목록을 유지합니다.

  • 마지막 체크포인트 이후 커밋된 트랜잭션 목록을 커밋합니다.
  • 활성 목록 아직 활성 상태인(커밋되지 않은) 트랜잭션입니다.

REDO는 커밋된 트랜잭션의 WRITE 작업에 로그 순서대로 적용됩니다. 활성(커밋되지 않은) 트랜잭션은 사실상 취소되므로 다시 제출해야 합니다.

타임라인 예시

체크포인트(t1) 크래시(t2) T1(커밋됨) T2 → REDO T3 → REDO T4 → 무시(커밋 없음) T5 → 무시(커밋 없음)

T1은 체크포인트 이전에 커밋되었으며 다시 실행할 필요가 없습니다. 체크포인트 이후에 커밋된 T2, T3는 다시 실행해야 합니다. T4, T5는 커밋되지 않고 무시됩니다(지연 업데이트 시 디스크에 변경 사항 없음).

REDO 최적화

항목 X가 커밋된 트랜잭션에 의해 여러 번 업데이트된 경우 마지막 업데이트만 다시 실행하면 됩니다.

  • 로그를 역순으로 탐색합니다.
  • 이미 다시 실행된 항목 목록을 유지합니다.
  • 이미 목록에 있는 항목을 건너뜁니다(마지막 값은 이미 복구됨).
  • 아직 목록에 없는 항목만 REDO한 후 추가하세요.

장점 및 한계

장점 제한사항 실패 시 롤백 필요 없음(NO-UNDO)쓰기 잠금 항목은 커밋까지 잠긴 상태로 유지계단식 롤백 없음(커밋까지 잠긴 항목)커밋까지 모든 업데이트에 버퍼 공간 필요중단된 트랜잭션은 간단히 다시 제출됨변경 사항이 거의 없는 짧은 트랜잭션에만 실용적

결론

NO-UNDO/REDO 지연 업데이트는 커밋까지 디스크 쓰기를 연기하므로 복구 중에 UNDO 작업이 필요하지 않습니다. 마지막 체크포인트 이후 커밋된 트랜잭션에만 REDO가 필요합니다. 이는 복구를 단순화하지만 동시성을 제한하고 커밋되지 않은 모든 변경 사항을 보관할 충분한 버퍼 공간이 필요합니다.

지연된 업데이트 복구:안정적인 데이터 무결성을 위해 NO-UNDO 및 REDO 사용