7장. Redo · 커밋 · 인스턴스 복구

전원이 뽑혀도 커밋된 데이터는 살아남는다 — 그 약속을 지키는 것이 redo입니다. COMMIT 한 번이 디스크까지 가는 여정과, 크래시 후 Oracle이 스스로 일어서는 2단계 복구를 봅니다.

7.1 Redo란 — 모든 변경의 일기장

6장의 undo가 "되돌리기 위한" 데이터라면, redo는 "다시 하기(re-do) 위한" 데이터입니다. 데이터 블록에 가해지는 모든 변경은 그 변경을 재현할 수 있는 redo record로 먼저 기록됩니다. 테이블 블록 변경도, 인덱스 블록 변경도, 심지어 undo 블록 변경도 redo에 남습니다.

왜 이런 이중 기록을 할까요? Buffer Cache의 변경된(dirty) 블록을 매번 디스크에 쓰는 것은 느립니다 — 블록이 datafile 여기저기에 흩어져 있어 랜덤 I/O이기 때문입니다. 반면 redo는 로그 파일 끝에 이어 쓰기만 하는 순차 I/O라 빠릅니다. 그래서 Oracle의 전략은:

redo가 흐르는 경로는 세 정거장입니다.

• Redo Log Buffer — SGA 안의 작은 원형 버퍼. 서버 프로세스가 redo record를 일단 여기에 씁니다.
• LGWR(Log Writer) — log buffer의 내용을 디스크로 내리쓰는 전담 백그라운드 프로세스(4장).
• Online Redo Log 파일 — 디스크 위의 redo 최종 목적지. 최소 2개의 그룹이 돌아가며 쓰입니다.

7.2 COMMIT 한 번의 여정 — 커밋은 왜 빠른가

많은 분들이 오해합니다. "커밋하면 변경된 데이터가 디스크에 저장된다"고요. 사실 커밋 시점에 디스크에 확실히 쓰이는 것은 데이터 블록이 아니라 redo입니다.

LGWR가 log buffer를 디스크로 내리는 계기는 커밋만이 아닙니다.

• 세션이 COMMIT(또는 ROLLBACK)할 때
• 3초마다 주기적으로
• log buffer가 1/3 찼거나 쌓인 redo가 1MB에 달했을 때
• DBWn이 dirty 블록을 쓰기 직전 — 블록보다 그 블록의 redo가 먼저 디스크에 있어야 한다는 write-ahead 규칙 때문

7.3 Log Switch와 ARCHIVELOG — 일기장 돌려쓰기

online redo log는 최소 2개의 그룹이 원형으로 돌아가며 쓰입니다. 현재 그룹이 가득 차면 다음 그룹으로 넘어가는 것이 log switch입니다. 그런데 한 바퀴 돌아 다시 첫 그룹을 덮어써야 할 때, 그 안의 redo가 지워지면 그 시점 이전으로의 복구 능력도 사라집니다. 그래서 운영 DB는 ARCHIVELOG 모드를 켜고, 덮어쓰기 전에 ARCn 프로세스가 사본(archived log)을 떠 둡니다.

-- redo log 그룹 상태 확인
SELECT group#, status, bytes/1024/1024 AS mb, archived
FROM   v$log;

GROUP#  STATUS    MB   ARCHIVED
------  --------  ---  --------
     1  INACTIVE  200  YES      ← 아카이브 완료, 재사용 가능
     2  CURRENT   200  NO       ← LGWR가 지금 쓰는 중
     3  ACTIVE    200  YES      ← 체크포인트 미완료, 아직 복구에 필요

-- 아카이브 모드 확인 / 수동 log switch
ARCHIVE LOG LIST;
ALTER SYSTEM SWITCH LOGFILE;

7.4 Checkpoint — 복구 시작선을 앞으로 당기기

Checkpoint는 "여기까지의 변경은 datafile에 확실히 반영되었다"는 동기화 지점입니다. DBWn이 그 시점까지의 dirty 블록을 디스크에 쓰고, CKPT 프로세스가 컨트롤 파일과 datafile 헤더에 체크포인트 위치(SCN)를 기록합니다.

체크포인트가 중요한 이유는 단 하나 — 크래시 복구를 어디서부터 시작할지를 정하기 때문입니다. 체크포인트 이전의 redo는 이미 datafile에 반영됐으니 재생할 필요가 없습니다. 체크포인트가 자주 진행될수록 복구는 빨라지고, 대신 평상시 디스크 쓰기는 늘어납니다. 이 균형은 FAST_START_MTTR_TARGET(목표 복구 시간, 초 단위) 파라미터로 조절합니다.

7.5 인스턴스 복구 — 크래시에서 스스로 일어서는 2단계

전원 장애로 인스턴스가 즉사했다고 합시다. 그 순간 디스크의 상태는 엉망입니다.

• 커밋됐지만 datafile에는 아직 안 쓰인 변경이 있고 (dirty 블록은 메모리와 함께 증발),
• 반대로 커밋 안 됐는데 datafile에 이미 쓰인 변경도 있습니다 (DBWn은 커밋 여부와 무관하게 씁니다).

다음 기동 때 SMON이 이 둘을 정리합니다. 무기는 redo와 undo, 순서는 정확히 2단계입니다.

7.6 PostgreSQL WAL과 나란히 놓고 보기

같은 write-ahead 철학이라 대응 관계가 깔끔합니다. PostgreSQL을 아는 분이라면 이 표 하나로 이 장을 복습할 수 있습니다 (PostgreSQL 9장 WAL과 Checkpoint).

가장 큰 차이는 마지막 줄입니다. PostgreSQL은 미커밋 변경도 "새 버전 튜플"일 뿐이라 복구에서 되돌릴 것이 없습니다(커밋 안 된 XID의 튜플은 그냥 안 보임). Oracle은 제자리 수정 구조라 undo를 이용한 rollback 단계가 반드시 필요합니다 — 6장에서 본 구조 차이가 복구 절차의 차이로 그대로 이어지는 것이죠.

✍️ 이해도 체크