All
회복 시스템
회복의 역할
•
예상치 못한 HW, SW 오류로 인해 안정적 디스크 반영 여부 보장이 불가능
•
오류 발생 이전의 일관된 상태로 데이터베이스를 복원
•
데이터베이스는 장애에 대비한 내재적 복원 절차 제공
시스템 실패 유형
•
트랜잭션 실패
◦
논리적: 잘못된 데이터 입력, 부재, 버퍼 오버플로, 자원 초과 이용
◦
시스템적: 운용 시스템의 교착상태 발생 등 시스템 제어 오류
•
시스템 장애
◦
시스템의 하드웨어 고장, 소프트웨어 오류
◦
메모리가 손실되므로 커밋 여부 식별할 수 있는 로그가 중요함
•
디스크 실패
◦
디스크 저장장치의 손상 및 고장으로 인한 데이터 자체 손실
◦
이 경우 로그만으로 회복이 어렵고 주기적인 백업 필요
데이터 저장 구조
•
전체 데이터는 디스크와 같은 비휘발성 저장장치에 저장
•
트랜잭션 처리시 메인 메모리내의 버퍼 영역에 데이터 적재하고 연산 수행
•
데이터는 블록 단위로 디스크 
메모리 간 전송, 메모리에 올라온 각 블록 = 버퍼 블록
메모리 간 전송, 메모리에 올라온 각 블록 = 버퍼 블록•
트랜잭션은 디스크로부터 주기억장치로 데이터를 가져오며, 변경된 데이터는 일정 시점에 Output 연산을 통해 디스크로 보내짐
데이터베이스 연산 처리 과정
메인 메모리와 디스크 사이 연산
•
Input(X): 물리적 블록 X를 디스크에서 읽어 메인 메모리(버퍼)에 적재
•
Output(X): 버퍼에 있는 블록 X를 디스크에 저장
트랜잭션이 수행하는 연산
•
Read(X)
◦
버퍼 블록 X가 메인 메모리에 없을 경우 Input(X)수행
◦
버퍼 블록 X 값을 변수 X에 할당
•
Write(X)
◦
버퍼 블록 X가 메인 메모리에 없을 경우 Input(X) 수행
◦
변수 X 값을 버퍼 블록 X에 반영
로그 기반 회복
데이터베이스가 수행한 모든 수정 작업을 기록한 여러 종류의 로그를 사용해 회복하는 시스템
로그 레코드의 종류
•
: 가 데이터 항목 변경 연산을 수행해 의 값을 에서 로 변경
•
: 시작
•
: 커밋
•
: 취소(롤백)
WAL(Write-Ahead Log)
•
트랜잭션이 실제 데이터를 변경하기 전에, 해당 변경 내용을 로그에 먼저 기록
•
로그 기록이 완료되지 않은 상태에서 데이터가 디스크에 반영되면 장애 발생 시 복원이 불가능해지므로 변경 순서가 반드시 로그 → 데이터 순이 되도록 강제함
회복을 위한 연산
1.
Redo()
•
T가 수행한 변경을 데이터베이스에 재적용
2.
Undo()
•
T가 수행한 변경을 되돌림 기록
시스템 장애 발생시 회복 판단 기준
•
로그에 start가 있지만 commit 또는 abort 포함하는 경우
→ T를 Redo (커밋 되었으나 디스크 반영여부 불확실)
•
로그에 start가 있지만 commit 또는 abort 가 없는 경우
→ T를 Undo (커밋 전 실패한 트랜잭션)
데이터베이스 변경과 커밋
•
트랜잭션의 변경 내용이 버퍼에만 반영된 상태에서 커밋된 경우
→ 아직 디스크에는 반영되지 않았기 때문에 장애 발생 시 Redo 필요
•
트랜잭션 수행 중 데이터가 수정되었지만 커밋 전에 장애가 발생한 경우
→ 트랜잭션은 정상적으로 종료되지 않았기 때문에 Undo 필요
트랜잭션 커밋 완료 판단 기준
•
커밋 로그 레코드가 안정된 저장장치에 기록 완료된 경우
→ 트랜잭션 커밋으로 간주, Redo 대상
•
커밋 로그 레코드가 기록되기 전에 장애가 발생한 경우
→ 커밋되지 않은 것으로 간주, Undo 대상
회복의 유형
회복 기법은 트랜잭션이 수정한 데이터가 언제 디스크에 반영되는지에 따라 구분
•
지연 갱신 회복
◦
트랜잭션 수행 중에는 디스크에 반영하지 않고 로그에만 기록
◦
트랜잭션이 커밋된 후에야 디스크에 적용
◦
장애 발생 시 로그만 보고 Redo만 수행하면 됨 → Undo 불필요
•
즉시 갱신 회복
◦
변경이 발생하면 즉시 디스크에 반영
◦
장애 발생 시, 디스크에 이미 반영된 갱신을 로그 기반으로 Undo 또는 Redo를 통해 정리해야 함
체크포인트의 필요성과 기법
로그 크기는 시간이 지남에 따라 계속 증가하므로 대용량 로그 탐색 비용이 매우 커짐. Redo 해야하는 트랜잭션 중 대부분은 이미 데이터베이스에 반영되어 있으므로 재실행은 자원 낭비
→ 이를 해결하기 위한 체크포인트 기법
•
일정 시점에 메인 메모리의 버퍼 블록에 존재하는 모든 로그 레코드 안정 저장장치로 기록
•
수정된 모든 버퍼 블록 디스크에 반영
•
로그 레코드 <checkpoint ListT>를 안정한 저장장치에 기록
이후 회복시 체크포인트 이후 로그만 탐색하면 되므로 복구 효율 향상
체크포인트 기반 회복 과정
•
로그의 마지막부터 역방향으로 탐색해 <checkpoint ListT> 레코드 찾음
•
<checkpoint ListT> 이후에 실행된 트랜잭션에 대해서만 Redo/Undo 수행
회복 알고리즘
트랜잭션 롤백 알고리즘
1.
로그를 역방향으로 탐색
2.
의 로그 레코드 찾을 때마다:
a.
데이터 항목 의 값을 로 복원
b.
로그 레코드 을 로그에 기록(복원 작업 기록)
3.
찾으면:
a.
역방향 탐색 종료
b.
로그에 레코드 기록
시스템 장애 후 회복 알고리즘
시스템 장애 이후 재시작 시 로그 전체를 기반으로 복구작업 진행
** List of Undo: 미커밋 상태인 트랜잭션만 모아놓은 것
1.
Redo 단계
•
최근 체크포인트에서부터 순방향 로그 탐색
•
롤백 대상 트랜잭션의 List of Undo를 ListT로 초기화
•
, 형태의 모든 레코드를 재실행
•
발견시 를 List of Undo에 추가
•
, 발견시 를 List of Undo에서 제거
2.
Undo 단계
•
Redo 단계가 끝난 시점부터 역방향으로 로그 탐색하며 List of Undo에 남아있는 트랜잭션에 대해 롤백 수행
•
발견시 로그에 기록하고 List of Undo에서 제거
•
List of Undo에 트랜잭션이 존재하지 않는 상태가 되면 Undo 단계 종료
Redo 단계에서는 커밋된 트랜잭션, 즉 실행했지만 반영 안된 작업을 재실행, Undo 단계에서는 미커밋 트랜잭션, 즉 중간에 실패했을 가능성이 있는 작업을 이전 값으로 복원하는 작업임