Redo·Checkpoint·Commit 원리: WAL·Fast Commit·Instance Recovery

핵심 요약

Oracle은 Commit할 때마다 변경된 Data Block을 즉시 Datafile에 기록하지 않습니다. Server Process가 Data Block과 Undo Block을 Buffer Cache에서 변경하고 Redo를 Redo Log Buffer에 생성하면, Commit 시 LGWR가 해당 Transaction의 선행 Redo와 Commit Record를 Online Redo Log에 영속화합니다. 이후 DBWn이 Dirty Buffer를 Datafile에 기록합니다.

DML 수행
→ Data Block·Undo Block 변경
→ Redo Log Buffer에 Redo 생성
→ COMMIT
→ LGWR가 선행 Redo와 Commit Record를 Online Redo Log에 기록
→ 동기 Commit 성공 반환
→ DBWn이 Dirty Buffer를 이후 Datafile에 기록

이 순서를 가능하게 하는 핵심 원칙이 Write-Ahead Logging(WAL)이고, Commit 시 Datafile Write를 기다리지 않는 구조가 Fast Commit입니다. Checkpoint는 Transaction을 Commit하는 기능이 아니라 Instance Recovery 시작점을 앞으로 이동시키는 작업입니다.

학습 목표

• Redo·Undo·Data Block의 역할을 구분한다.
• Change Vector와 Redo Record의 관계를 설명한다.
• Redo Log Buffer·LGWR·Online Redo Log의 처리 흐름을 설명한다.
• Redo Thread·Group·Member·Sequence Number를 구분한다.
• WAL과 Fast Commit이 함께 동작하는 이유를 설명한다.
• Group Commit과 COMMIT WRITE 옵션의 성능·내구성 Trade-off를 판단한다.
• DBWn·CKPT·Checkpoint의 역할을 구분한다.
• Log Switch·ARCn·Archived Redo Log의 관계를 설명한다.
• Instance Recovery와 Media Recovery를 구분한다.
• Redo 관련 Wait Event와 동적 성능 View로 병목을 진단한다.

1. Redo·Undo·Change Vector

1.1 Redo와 Undo

Redo는 Database 변경을 장애 후 다시 적용할 수 있도록 기록한 정보입니다. Undo는 변경을 취소하고 Query SCN 시점의 과거 버전을 재구성하는 데 사용됩니다.

변경 재적용
→ Redo

변경 취소·과거 버전 재구성
→ Undo

두 구조는 대체 관계가 아닙니다. 한 번의 DML은 Data Block과 Undo Block을 변경하며, 두 Block을 장애 후 복구하려면 각각의 변경에 대한 Redo가 필요할 수 있습니다.

1.2 Change Vector와 Redo Record

Redo Change Vector는 하나의 Database Block에 가해진 변경을 설명합니다. 하나의 논리적 작업이 여러 Block을 변경하면 여러 Change Vector가 하나의 Redo Record를 구성할 수 있습니다.

한 행 UPDATE
├─ Table Data Block 변경
├─ Index Leaf Block 변경
├─ Undo Block 변경
└─ Transaction 관련 Block 변경

각 Block 변경
→ Change Vector

관련 Change Vector 묶음
→ Redo Record

Redo는 SQL 문장 자체를 Text로 저장해 재실행하는 개념이 아니라 Block 변경을 복구할 수 있는 내부 정보입니다.

2. DML부터 Commit까지의 Memory·File 흐름

다음 UPDATE를 실행한다고 가정합니다.

UPDATE accounts
SET    balance = balance - 10000
WHERE  account_id = 101;

일반적인 흐름은 다음과 같습니다.

1. Server Process가 필요한 Block을 Buffer Cache에서 찾는다.
2. 변경 전 정보를 보존할 Undo Record를 만든다.
3. Data Block과 Undo Block을 Memory에서 변경한다.
4. 각 Block 변경에 대한 Redo를 Redo Log Buffer에 복사한다.
5. 변경된 Buffer는 Dirty 상태가 된다.
6. COMMIT 시 LGWR가 선행 Redo와 Commit Record를 Online Redo Log에 기록한다.
7. WAIT Commit은 Redo 영속화 완료 후 성공을 반환한다.
8. DBWn은 Dirty Buffer를 적절한 시점에 Datafile에 기록한다.

핵심은 Commit 완료와 Datafile Write 완료가 서로 다른 사건이라는 점입니다.

Commit 내구성의 기준
→ Redo의 영속화

Datafile 최신화
→ DBWn이 이후 수행 가능

3. Redo Log Buffer와 LGWR

3.1 Redo Log Buffer

Redo Log Buffer는 SGA의 순환 Buffer입니다. Server Process는 Database 변경에 대한 Redo Entry를 이 영역에 복사합니다.

Server Process
→ Redo Log Buffer
→ LGWR·LGnn
→ Online Redo Log Group의 모든 Member

Memory 영역이므로 Instance가 종료되면 Buffer 자체의 내용은 사라집니다. 동기 Commit의 내구성을 확보하려면 관련 Redo가 Online Redo Log에 기록돼야 합니다.

3.2 LGWR와 LGnn

LGWR는 Redo Log Buffer의 Redo를 Online Redo Log에 순차적으로 기록합니다. 26ai에서는 병렬 처리가 유리한 일부 작업을 LGnn Worker가 도울 수 있지만, Commit 완료와 Redo Write 조정의 중심은 LGWR입니다.

대표적인 Redo Flush 계기는 다음과 같습니다.

• Foreground Session의 Commit 요청
• Redo Log Buffer 공간 확보 필요
• DBWn이 Dirty Buffer를 기록하기 전에 해당 Redo 영속화 필요
• Log Switch와 내부 Flush 조건
• 관리 명령이나 운영상의 Flush 요구

고정 숫자만 암기하기보다 다음 원리를 이해해야 합니다.

Commit Redo 영속화
+
Dirty Block보다 Redo 선행 기록
+
순환 Redo Log Buffer 공간 확보

4. Online Redo Log의 구조

Online Redo Log는 Thread → Group → Member 구조로 이해합니다.

Redo Thread
├─ Group 1
│  ├─ Member A
│  └─ Member B
├─ Group 2
│  ├─ Member A
│  └─ Member B
└─ Group 3
   ├─ Member A
   └─ Member B

4.1 Redo Thread

Redo Thread는 한 Instance가 생성하는 Redo Stream입니다.

• Single Instance Database는 일반적으로 하나의 Redo Thread를 사용합니다.
• RAC에서는 각 Instance가 자신의 Redo Thread와 Online Redo Log 집합을 사용합니다.

4.2 Group과 Sequence Number

LGWR는 현재 Group에 기록하고, Group이 가득 차거나 강제 전환이 발생하면 다음 Group으로 이동합니다. 이 사건이 Log Switch입니다. Group이 다시 사용될 때마다 새로운 Log Sequence Number가 부여됩니다.

Group 1 / Sequence 101
→ Group 2 / Sequence 102
→ Group 3 / Sequence 103
→ Group 1 / Sequence 104

Group 번호는 물리적 순환 단위이고, Sequence Number는 Redo Stream의 시간 순서를 나타냅니다.

4.3 Member

한 Group의 여러 Member에는 같은 Redo가 기록됩니다. Member는 Redo를 나눠 쓰는 Stripe가 아니라 동일 Group의 복사본입니다.

Group 1
├─ Member A: 동일 Redo
└─ Member B: 동일 Redo

다중화 효과를 얻으려면 Member를 동일 장애에 함께 노출되지 않도록 서로 다른 Disk Group·Controller·장애 영역에 배치해야 합니다. Member 수가 늘면 LGWR가 모든 Member의 Write 완료를 처리해야 하므로 무조건 많을수록 빠르다고 판단할 수 없습니다.

4.4 V$LOG 상태와 Archive 여부

STATUS와 ARCHIVED는 다른 판단 축입니다.

INACTIVE
→ Instance Recovery 필요 여부 기준

ARCHIVED=YES/NO
→ Archive 완료 여부 기준

ARCHIVELOG Mode에서는 Group이 Instance Recovery에 불필요해도 Archive가 완료되지 않았다면 재사용할 수 없습니다.

5. Write-Ahead Logging

WAL은 Dirty Data Block을 Datafile에 기록하기 전에 해당 변경을 복구할 Redo가 Online Redo Log에 먼저 기록되도록 보장하는 원칙입니다.

Redo 먼저 영속화
→ Dirty Block 나중 기록

Data Block이 먼저 Datafile에 기록되고 Redo가 손실되면 장애 후 일관된 복구가 불가능할 수 있습니다. 따라서 DBWn이 특정 Dirty Buffer를 기록하려면 LGWR가 해당 변경의 Redo까지 먼저 기록해야 합니다.

WAL은 Commit 때만 적용되는 규칙이 아닙니다. DBWn의 Datafile Write 순서에도 적용되는 복구 원칙입니다.

6. Fast Commit과 Commit 내구성

6.1 Fast Commit

Fast Commit은 Commit 시 Transaction이 변경한 모든 Dirty Buffer를 Datafile에 기록하지 않고, 선행 Redo와 Commit Record가 Online Redo Log에 기록되면 성공을 반환하는 구조입니다.

COMMIT 요청
→ Commit 정보 생성
→ LGWR가 선행 Redo와 Commit Record 기록
→ Foreground에 완료 통지
→ DBWn의 Datafile Write는 이후 가능

이 구조 덕분에 Commit 응답은 여러 Datafile의 Random Write를 모두 기다리지 않고 순차 Redo Write를 중심으로 결정될 수 있습니다.

6.2 Commit 성공과 Datafile 최신화

Commit 후 Datafile Write 전에 Instance 장애가 발생해도 Startup 시 Instance Recovery가 Redo를 적용해 Commit 결과를 복구할 수 있습니다.

7. Group Commit

여러 Session이 비슷한 시점에 Commit하면 LGWR가 여러 Commit의 Redo를 한 번의 물리 Write 묶음에 포함할 수 있습니다.

Session A COMMIT ┐
Session B COMMIT ├→ LGWR Redo Write → A·B·C 완료 통지
Session C COMMIT ┘

Group Commit의 핵심은 다음과 같습니다.

• Session Commit 수와 Physical Redo Write 수가 항상 1:1은 아닙니다.
• 각 WAIT Session은 자신의 Commit Record가 영속화될 때까지 기다립니다.
• 동시 Commit이 많으면 하나의 Write가 여러 Commit을 서비스할 수 있습니다.
• Group Commit이 존재한다고 해서 행마다 Commit하는 설계가 효율적이 되는 것은 아닙니다.
• BATCH는 다른 Redo와 함께 기록할 여지를 늘리지만, 일반 동기 Commit에서도 동시성에 따라 Grouping이 발생할 수 있습니다.

8. COMMIT WRITE 옵션

COMMIT WRITE는 반환 시점과 Redo Write 요청 방식을 조합합니다.

COMMIT WRITE IMMEDIATE WAIT;
COMMIT WRITE BATCH NOWAIT;

명시적인 설정이 없을 때의 기본 동작은 WAIT IMMEDIATE이며, 관련 초기화 Parameter가 설정된 환경에서는 생략된 Clause의 동작에 영향을 줄 수 있으므로 실제 설정을 확인합니다.

8.1 WAIT

성공 응답 수신
→ 관련 Redo가 Durable Media에 기록됐음을 보장

장애 시에도 성공으로 응답한 Transaction의 내구성을 보장해야 하는 일반 업무에는 WAIT가 기준입니다.

8.2 NOWAIT

성공 응답 반환
→ Redo Write 완료 전일 수 있음
→ 직후 장애 시 성공으로 인식한 Transaction 손실 가능

NOWAIT는 단순 응답시간 최적화 옵션이 아니라 내구성 계약을 바꾸는 선택입니다. 데이터 손실 허용 범위, 재처리, Idempotency, 외부 시스템과의 정합성을 먼저 정의해야 합니다.

9. DBWn·CKPT·Checkpoint

9.1 DBWn

DBWn은 Buffer Cache의 Dirty Buffer를 Datafile에 기록합니다. 대표 계기는 다음과 같습니다.

• 재사용 가능한 Clean Buffer 확보 필요
• Checkpoint 진행
• Dirty Buffer 누적과 내부 Write 정책
• File·Tablespace 상태 변경에 필요한 Write
• Instance Recovery 목표에 따른 Checkpoint Write

DBWn은 WAL에 따라 관련 Redo가 먼저 영속화된 뒤 Dirty Block을 기록합니다.

9.2 Checkpoint

Checkpoint는 Recovery 시작 지점을 앞으로 이동시키는 과정입니다. Checkpoint 위치보다 이전 변경의 필요한 Data Block이 Datafile에 반영됐다고 판단할 수 있으므로, 장애 시 적용해야 할 Redo 범위를 줄입니다.

Checkpoint Position 전진
→ DBWn의 Dirty Buffer Write 촉진
→ Recovery 시작 Redo 위치 전진
→ 예상 Instance Recovery 작업량 감소

일반적인 Incremental Checkpoint는 모든 Dirty Buffer를 한 번에 Flush하는 사건이 아닙니다. Database 운영 중 DBWn이 지속적으로 Block을 기록하면서 Checkpoint Position을 점진적으로 이동시킵니다. 특정 명령이나 상태 전환에서는 Full Checkpoint가 발생할 수 있습니다.

9.3 CKPT

CKPT는 DBWn에 Checkpoint Write를 요청하고, 완료된 Checkpoint 정보를 Control File과 Datafile Header에 반영합니다.

DBWn
→ Dirty Data Block 기록

CKPT
→ Checkpoint 시작·조정
→ Header·Control File의 Checkpoint 정보 갱신

CKPT가 사용자 Data Block이나 Redo를 직접 기록하는 Process로 해석하면 안 됩니다.

9.4 Commit과 Checkpoint

9.5 MTTR과 Redo Log 크기

FAST_START_MTTR_TARGET은 목표 Instance Recovery 시간과 Checkpoint Write 압력의 Trade-off를 조정합니다. V$INSTANCE_RECOVERY에서 다음 값을 확인할 수 있습니다.

• TARGET_MTTR: 적용되는 목표 MTTR
• ESTIMATED_MTTR: 현재 Dirty Buffer와 Redo 상태를 바탕으로 한 예상 MTTR
• OPTIMAL_LOGFILE_SIZE: 현재 MTTR 목표를 고려한 권고 Online Redo Log 크기
• Checkpoint Write 원인별 통계

Redo Log 크기만 독립적으로 조정하지 말고 Redo 생성률, Log Switch 간격, Checkpoint Write, Archive 처리량과 함께 평가합니다.

10. Log Switch와 Archived Redo Log

10.1 Log Switch

현재 Group이 가득 차거나 관리 명령으로 전환되면 LGWR가 다음 Group으로 이동합니다.

현재 CURRENT Group 기록 종료
→ Log Switch
→ 다음 재사용 가능 Group에 새 Sequence Number 부여
→ 다음 Group이 CURRENT

다음 Group을 재사용하려면 일반적으로 다음 조건을 확인합니다.

Instance Recovery에 더 이상 필요하지 않음
+
ARCHIVELOG Mode라면 Archive 완료

10.2 ARCn과 Archive

ARCHIVELOG Mode와 자동 Archive가 활성화되면 ARCn이 전환된 Online Redo Log를 Archive Destination으로 복사합니다. Archive가 뒤처지면 Oracle은 필요한 수의 ARCn Process를 추가로 사용할 수 있습니다.

Archived Redo Log는 다음에 사용됩니다.

• Media Recovery
• Point-in-Time Recovery
• Standby Database Redo 전송·적용
• LogMiner 등 Redo 분석

Archived Redo Log만으로 복구가 완성되는 것은 아닙니다. Datafile Backup과 Archived·Online Redo를 복구 목표에 맞게 함께 구성해야 합니다.

10.3 지나치게 잦은 Log Switch

작은 Redo Log 또는 Redo 폭증은 Switch를 지나치게 자주 발생시킬 수 있습니다.

• Checkpoint Write 압력 증가
• ARCn과 Archive Destination 부하 증가
• log file switch 계열 대기
• Control File·운영 Log 관리 부담

무조건 큰 Redo Log가 정답도 아닙니다. 복구 목표, Redo 발생량, Archive 처리 속도, Storage와 운영 정책을 함께 봅니다.

11. Instance Recovery와 Media Recovery

11.1 Instance Recovery

Instance가 비정상 종료되면 Commit된 변경의 Redo는 존재하지만 해당 Dirty Buffer가 Datafile에 기록되지 않았을 수 있습니다. Startup 시 Recovery는 다음 단계로 진행됩니다.

1. Cache Recovery·Roll Forward
   → Checkpoint 이후 Redo 적용
   → Commit된 변경과 미커밋 변경 모두 Data Block에 재현 가능

2. Transaction Recovery·Roll Back
   → Undo를 이용해 미커밋 Transaction 변경 제거

중요한 점은 Roll Forward가 Commit된 Redo만 골라 적용하는 절차가 아니라는 것입니다. 먼저 필요한 Redo를 적용해 Block 상태와 Undo를 복구한 뒤, 미커밋 Transaction을 Undo로 제거합니다.

Instance Recovery는 일반적으로 비정상 종료된 Instance를 Startup할 때 자동으로 수행하며 Datafile Backup 복원이 필요하지 않습니다.

11.2 Media Recovery

Datafile 손실·손상처럼 저장 매체 문제가 발생하면 Backup을 복원하고 Redo를 적용합니다.

Backup Datafile 복원
→ Archived Redo 적용
→ 필요한 Online Redo 적용
→ 목표 SCN·시점까지 복구

12. Redo 관련 Wait Event

12.1 log file sync

Foreground Session이 Commit Redo의 Write 완료와 LGWR의 완료 통지를 기다리는 시간입니다. 이 시간에는 LGWR가 CPU를 얻고 I/O를 제출하고, I/O 완료 후 Foreground를 깨우는 과정이 포함될 수 있습니다.

대표 원인:

• 지나치게 잦은 Commit
• Redo Storage 지연
• LGWR CPU Scheduling·Posting 지연
• Redo 폭증
• 느린 Member 또는 장애 영역 구성 문제
• 동기 Redo Transport의 추가 지연

평균값만 보면 소수의 긴 Outlier가 많은 Session의 log file sync를 동시에 늘려 왜곡할 수 있으므로 Histogram과 애플리케이션 Transaction 응답시간을 함께 봅니다.

12.2 log file parallel write

LGWR가 Redo Block을 Online Redo Log Member에 기록하는 I/O와 연결된 대기입니다.

log file sync 증가
+
log file parallel write 증가
→ Redo Storage·Member I/O 우선 점검

log file sync만 상대적으로 증가
→ Commit 빈도·CPU·Posting·Redo Transport도 점검

두 Event는 측정 주체와 발생 횟수가 다르므로 1:1로 비교하지 않습니다.

12.3 log buffer space

Session이 Redo Log Buffer에 Redo를 추가할 공간을 기다리는 상태입니다.

• LGWR가 Redo 생성 속도를 따라가지 못함
• Redo Storage 지연
• 순간 Redo 폭증
• Log Switch 지연
• 작은 Log Buffer 또는 내부 Strand Flush 문제

Buffer 크기 변경 전에 Redo 생성 SQL, LGWR I/O, Switch·Archive 지연을 함께 확인합니다.

12.4 log file switch (checkpoint incomplete)

다음 Group을 사용해야 하지만 Checkpoint가 충분히 전진하지 않아 해당 Group이 Instance Recovery에 아직 필요할 때 발생합니다.

• 작은 Online Redo Log
• 지나치게 잦은 Switch
• 느린 DBWn·Datafile Write
• 공격적인 MTTR 목표
• 높은 Dirty Buffer 생성률

12.5 log file switch (archiving needed)

다음 Group을 사용해야 하지만 Archive가 완료되지 않았을 때 발생합니다.

• Archive Destination 공간 부족
• ARCn 지연
• Archive Storage I/O 병목
• Remote Destination·Standby 전송 지연
• Switch 빈도 증가

13. Commit 빈도와 Transaction 크기

13.1 지나치게 잦은 Commit

행마다 COMMIT
→ Commit Record와 log file sync 증가
→ Database Call·Network Round Trip 증가
→ 업무 원자성 분할
→ 재처리 복잡성 증가

Commit 횟수를 줄여도 DML 자체가 생성하는 Redo가 사라지는 것은 아닙니다. 다만 Commit 처리와 왕복 비용, Transaction 경계를 줄일 수 있습니다.

13.2 지나치게 큰 Transaction

거대한 Transaction
→ Undo 사용량 증가
→ Lock 보유시간 증가
→ 실패 시 Rollback 시간 증가
→ 재시작 단위 확대
→ 복구 부담 증가

Commit Unit은 임의의 N행보다 함께 성공하거나 함께 취소해야 하는 업무 원자성 단위를 우선으로 정합니다.

14. Redo 구조·통계 확인 SQL

14.1 Online Redo Log Group

SELECT thread#,
       group#,
       sequence#,
       bytes,
       members,
       archived,
       status,
       first_change#,
       first_time
FROM   v$log
ORDER BY thread#, group#;

14.2 Redo Log Member

SELECT group#,
       type,
       status,
       member
FROM   v$logfile
ORDER BY group#, member;

14.3 최근 Log Switch

SELECT thread#,
       sequence#,
       first_time
FROM   v$log_history
ORDER BY first_time DESC
FETCH FIRST 30 ROWS ONLY;

14.4 Archived Redo 완료 상태

SELECT thread#,
       sequence#,
       dest_id,
       archived,
       applied,
       status,
       completion_time,
       name
FROM   v$archived_log
WHERE  completion_time >= SYSDATE - 1
ORDER BY completion_time DESC;

같은 Thread·Sequence가 여러 Destination이나 Backup·Restore로 여러 행 존재할 수 있으므로 한 행만 존재한다고 가정하지 않습니다.

14.5 Redo·Commit Delta

SELECT name,
       value
FROM   v$sysstat
WHERE  name IN (
         'redo size',
         'redo entries',
         'redo writes',
         'user commits',
         'user rollbacks'
       )
ORDER BY name;

Instance 시작 이후 누적값이므로 장애 구간 시작·종료 Snapshot의 Delta와 초당 비율을 계산합니다.

14.6 Recovery·Redo Log 크기

SELECT target_mttr,
       estimated_mttr,
       optimal_logfile_size,
       ckpt_block_writes,
       writes_mttr,
       writes_logfile_size
FROM   v$instance_recovery;

14.7 Redo 관련 Wait

SELECT event,
       total_waits,
       time_waited_micro,
       ROUND(
         time_waited_micro / NULLIF(total_waits, 0) / 1000,
         3
       ) AS avg_wait_ms
FROM   v$system_event
WHERE  event IN (
         'log file sync',
         'log file parallel write',
         'log buffer space',
         'log file switch (checkpoint incomplete)',
         'log file switch (archiving needed)'
       )
ORDER BY time_waited_micro DESC;

System 누적값만으로 원인 SQL을 확정하지 않고 AWR·ASH·Session 통계·Storage 지표로 문제 구간을 좁힙니다.

15. Redo 진단 절차

1. 증상을 Commit 지연, Redo Buffer 지연, Switch 정지로 구분한다.
2. 같은 시간 구간의 user commits·redo size·redo writes Delta를 계산한다.
3. 애플리케이션 TPS·Transaction 응답시간과 Commit 빈도를 연결한다.
4. log file sync·log file parallel write의 분포와 Outlier를 비교한다.
5. Redo Log Member의 위치·I/O Latency·오류 상태를 확인한다.
6. Group 크기·Switch 간격·Thread별 Sequence 흐름을 확인한다.
7. checkpoint incomplete이면 DBWn·Datafile Write·MTTR 목표를 확인한다.
8. archiving needed이면 ARCn·Destination 공간·Remote 전송을 확인한다.
9. Redo를 많이 만드는 SQL·Index·불필요한 DML을 분석한다.
10. 변경 후 응답시간·처리량·내구성·MTTR·Archive 여유를 함께 검증한다.

16. 잘못된 판단과 정확한 기준

17. 핵심 정리

Redo
→ Block 변경 재적용 정보

Undo
→ 변경 취소와 과거 버전 재구성

LGWR
→ Redo Log Buffer를 Online Redo Log에 기록

WAL
→ Dirty Block보다 관련 Redo를 먼저 영속화

Fast Commit
→ Commit Redo 영속화 후 반환, Datafile Write는 이후 가능

Group Commit
→ 여러 Commit을 한 Redo Write에 함께 처리 가능

DBWn
→ Dirty Buffer를 Datafile에 기록

CKPT
→ Checkpoint를 조정하고 Header·Control File 정보 갱신

ARCn
→ ARCHIVELOG Mode에서 전환된 Redo를 Archive

Instance Recovery
→ Redo Roll Forward + 미커밋 Transaction Rollback