
Transaction Recovery
장애 유형
DB 장애가 발생하는 원인은 크게 트랜잭션 장애, 시스템 장애, 미디어 장애로 나눠볼 수 있다.
| 유형 | | |
|---|
| 트랜잭션 장애 | 원인 | 트랜잭션 수행 중 오류가 발생한 경우 |
| 이유 | 트랜잭션의 논리적 오류, 잘못된 데이터 입력, 시스템 과다 사용 요구, 처리 대상 데이터 부재 등 |
| 시스템 장애 | 원인 | 하드웨어의 결함 |
| 이유 | |
| 미디어 장애 | 원인 | 디스크 장치의 결함 |
| 이유 | |
Recovery 원리
- DB 회복의 핵심원리는 데이터를 중복 저장하는 것이다.
- 데이터를 별도의 장소에 미리 복사해두고, 장애로 문제가 발생했을때 복사본을 이용해 원래의 상태로 복원하는 것이다.
- 사용하는 방식으로 덤프 또는 로그 방법을 사용한다.
Dump
- 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법
- 정해진 주기에 따라, 디스크와 같은 비휘발성 저장 장치에 데이터베이스 복사본을 저장한다.
Log
- 데이터베이스에서 변경 연산이 실행될 때마다 데이터를 변경하기 이전 값과 변경한 이후 값을 별도의 파일에 기록하는 방법
- 로그는 데이터베이스에 대한 변경 연산과 관련하여 데이터를 변경하기 이전의 값과 변경한 이후의 값을 기록한다.
- 로그를 저장한 파일을 로그 파일이라고 하고, 로그 파일은 레코드 단위로 기록된다.
- 로그는 데이터 손실이 발생하지 않는 저장 장치에 저장한다.
로그 Ex
1: <T1, Start> // 트랜잭션 T1 이 실행되었음을 기록
2: <T1, X, 10000, 5000> // 트랜잭션 T1이 데이터 X를 이전 값에서 새로운 값으로 변경하는 연산을 실행했음을 기록
3: <T1, Y, 0, 5000> // 트랜잭션 T1이 데이터 Y를 이전 값에서 새로운 값으로 변경하는 연산을 실행했음을 기록
4: <T1, Commit> // 트랜잭션 T1 이 성공적으로 완료되었음을 기록
Recovery 연산
덤프 or 로그로 중복 저장한 데이터를 이용해 회복하는 방법은 redo 나 undo 연산을 실행하는 것이다.
Redo(재실행)
가장 최근에 저장한 데이터베이스 복사본을 가져온 후 로그를 이용해 복사본이 만들어진 이후에 실행된 모든 변경 연산을 재실행하여 장애가 발생하기 직전의 데이터베이스 상태로 복구
트랜잭션이 완료되기 전에 장애가 발생한 경우(로그 파일에 트랜잭션 시작 로그는 있지만 커밋 로그는 없을 때)에는 undo 연산을 실행
Undo(취소)
로그를 이용해 지금까지 실행된 모든 변경 연산을 취소하여 데이터베이스를 원래의 상태로 복구
트랜잭션이 완료되고 나서 장애가 발생한 경우(로그 파일에 트랜잭션 시작 로그, 커밋 로그 모두 있을 때)에는 redo 연산을 실행
Log Recovery
로그를 사용하여 회복을 한다.
로그를 이용한 회복 기법은 로그 전체를 분석하여 로그에 기록된 모든 트랜잭션을 대상으로 redo 나 undo 회복 연산을 결정해야 하므로, 너무 많은 시간이 걸리고 redo 연산을 수행할 필요가 없는 트랜잭션에도 redo 연산을 수행하는 일이 발생한다.
Log Recovery #즉시 갱신
즉시 갱신 회복은 데이터를 변경할 때 장애 발생에 대비하기 위해 데이터 변경에 대한 내용을 로그 파일에도 기록한다.
데이터 회복시 로그를 정상적으로 사용하려면, 트랜잭션에서 데이터 변경 연산이 실행될 때 로그 파일에 먼저 로그 레코드를 기록한 후 데이터 변경 연산을 수행해야한다.
장애 발생 시점에 따라 로그 파일을 참조하여 redo 나 undo 연산을 실행한다.

1번 지점에서 장애가 발생했을 때
T1 트랜잭션이 완료되기 전이므로, Undo(T1) 연산을 수행한다.
2번 지점에서 장애가 발생했을 때
T1 트랜잭션은 완료되었고, T2 트랜잭션은 완료되지 않았다.
Redo(T1), Undo(T2) 연산을 수행한다.
Log Recovery #지연 갱신
지연 갱신 회복 기법은 트랜잭션이 수행되는 동안에는 데이터 변경 연산의 결과를 데이터베이스에 즉시 반영하지 않고 로그 파일에만 기록해두었다가, 트랜잭션 연산이 부분 완료(연산은 끝났고 커밋 되기 전) 후에 로그에 기록된 내용을 이용해 DB에 한 번에 반영한다.
트랜잭션 수행 중에 장애가 발생하면 로그에 기록된 내용을 버리기만 하면 되기 때문에 Undo 연산은 필요없고 Redo 연산만 수행하면 된다.
그렇기 때문에 로그 레코드에는 변경 이전 값을 기록할 필요가 없다.
트랜잭션이 완료되기 전에 장애가 발생한 경우
로그 내용을 무시하고 버림
트랜잭션이 완료된 후에 장애가 발생 한 경우
Redo 연산 수행

1번 지점에서 장애가 발생했을 때
로그 내용을 무시하고 버림
2번 지점에서 장애가 발생했을 때
T1 트랜잭션은 완료되었고, T2 트랜잭션은 완료되지 않았다.
T1은 Redo, T2의 로그 내용은 무시하고 버림
Checkpoint
- 체크포인트 회복 기법은 로그를 사용하되, 일정 시간 간격으로 체크 포인트를 만들어 둔다.
- 일정 시간 간격으로 메인 메모리에 있는 모든 로그 레코드를 안정 저장 장치에 있는 로그 파일에 기록하고, 트랜잭션의 데이터 변경 내용을 DB에 반영한다.
- 그리고 장애가 발생하면 가장 최근 검사 시점 이전의 트랜잭션에는 회복 작업을 수행하지 않고, 이후의 트랜잭션에만 회복 작업을 수행한다.
- 체크포인트 이후의 로그 기록에만 회복 작업을 수행. 회복 작업의 범위가 정햊디면 로그 회복과 동일하게 수행
로그 회복과 체크포인트 회복의 차이는
회복 작업의 범위이다.
- 전체 DB 내용을 일정 주기마다 다른 안전한 저장 장치에 복사해두는 덤프를 이용
- 비용이 많이 들고 복사하는 동안에 트랜잭션 수행을 중단해야 하므로 CPU가 낭비된다는 단점이 있음.
DBMS가 Durability를 보장하는 방식
- Write-ahead Logging(WAL)
- 가장 흔히 사용되는 Durability를 보장 메커니즘 중 하나
- 커밋되기 전에 해당 트랜잭션의 변경 내용을 로그 파일에 기록
- 로그 파일은 디스크에 안전하게 저장되며, 커밋된 트랜잭션의 변경 내용을 재실행하는데 사용된다.
- WAL을 사용하면 시스템 장애가 발생해도 로그 파일을 사용하여 데이터베이스를 복구할 수 있다.
- Write Synchronization
- DBMS는 디스크에 데이터를 기록하기 전에 일정 수준의 데이터 일관성을 보장하기 위해 적절한 동기화 메커니즘을 사용한다.
- Write Synchronization은 주로 트랜잭션 로그를 디스크에 안전하게 기록하는 작업을 의미한다.
- 일반적으로 데이터베이스는 캐시 버퍼를 사용하여 트랜잭션 변경 내용을 모아두었다가 일괄적으로 디스크에 기록하는 방식으로 동기화를 수행한다.
- Redo Logging
- Redo Logging은 WAL 메커니즘의 일부로, 트랜잭션 변경 내용을 로그 파일에 기록하는 과정을 의미한다.
- 시스템 장애 발생 시, 로그 파일의 Redo 정보를 사용하여 커밋된 트랜잭션의 변경 내용을 디스크에 재적용하여 데이터의 일관성을 복구한다.
- Checkpoints
- 데이터베이스의 상태를 주기적으로 저장하는 절차
- 디스크에 데이터베이스 상태를 기록하고, 이 상태로부터 데이터베이스를 복구한다.
- 체크포인트는 WAL 로그 파일의 크기를 제한하고, 데이터베이스 복구 시간을 단축시키는데 도움을 준다,