Redo 로그

• Redo 로그 버퍼에 저장된 로그 레코드(데이터/컨트롤 파일의 모든 변경 사항)가 Redo 로그 블록 단위(512 Byte)로 저장되는 곳이다.
  
  이미지출처

Redo 로그 구분

1. Online Redo 로그

• Redo 로그 버퍼에 버퍼링된 로그 엔트리를 기록한다.
• 최소 두 개 구성되어 있어 라운드 로빈 로그 스위칭이 발생한다.

2. Archived Redo 로그

• Online Redo 로그 파일이 재사용 되기 전 다른 위치로 저장되는 백업본이다.
• 미디어 파일 복구시 사용된다.

Redo 목적

1. Database Recovery

• Media Fail 발생 후 복구시 Archived Redo 로그를 활용한다.

2. Cache Recovery (Instance Recovery)

• 휘발성의 버퍼 캐시 데이털를 복구하기 위해 Redo 로그를 사용한다.
• 데이터 파일에는 Commit 된 변경 사항만 존재한다.
• 인스턴스가 비정상으로 종료된 경우 인스턴스를 재기동하는 과정
  • 1. Online Redo 로그의 마지막 Checkpoint 이후에 존재했던 트랜잭션을 Roll Forward 시킨다.
       이 때 버퍼 캐시에만 존재했던 변경 사항이 Commit 여부와 관계 없이 복구 된다.
  • 2. 인스턴스 비정상 종료 시 인스턴스 재기동 :: Undo 데이터를 이용해 Commit 안된 트랜잭션을 Rollback (Transaction Recovery)

3. Fast Commit

✅ Block 과 Redo 로그의 속도 차이

• Block은 Random Access 방식으로 쓰기(Write)를 진행하므로 상대적으로 느리다.
• Redo 로그는 Append 방식(뒤로 바로 덧붙이는 방식)으로 쓰기(Write)를 진행하므로 상대적으로 빠르다.

• Commit 시 데이터 Block 쓰기 대신 Redo 쓰기를 한다.
• 변경 사항은 Redo 로그에는 바로 기록하고, 버퍼 블록의 메모리-디스크 동기화는 나중에 일괄 수행한다.

3-1. Fast Commit의 또다른 의미🧐

• Commit 시점에는 Undo 세그먼트 헤더의 트랜잭션 테이블에만 Commit 정보를 기록하고 블록 클린아웃(Commit 정보 기록, 로우 Lock 해제)은 나중에 수행하는 방식이다.

  ✅ 블록 클린아웃이란?

  • 트랜잭션에 의해 설정된 로우 Lock을 해제하고 블록 헤더(캐시 체인)에 커밋 정보를 기록하는 오퍼레이션이다.
  • 블록에 설정된 로우 레벨 락을 해제(Cleanout)한 후 ITL 정보(SCN, Flag, Lock Byte 등)가 갱신된다.

• 커밋 시점에 모든 블록에 대해 cleanout을 수행하지 않는다.
• 성능상의 문제로 변경된 데이터 블록들 중 버퍼 캐시에 올라와 있는 일부 블록들에 대해서만 cleanout을 수행한다.
• Commit시 변경된 일부 데이터 블록들의 헤더에 대해서만 변경 작업을 수행 하여 변경되는 정보의 량을 최소화한다.
• Lock byte 정보는 트랜잭션에 의해 변경된 모든 로우에 저장되므로 변경해야 할 데이터의 양이 많기 때문에 ITL 정보에서 Flag와 SCN 정보만 변경되고 lock byte 정보는 변경되지 않는다.
• 리두 데이터가 생성되지 않고, 커밋 마크만이 리두에 저장된다.
• 수백만 건의 데이터를 변경한 후에 커밋을 수행하는 경우에도 매우 빠른 속도로 커밋 처리가 되는 것은 이러한 기법 덕분이다.

4. Delayed Block Cleanout

• 커밋 이후 해당 블록을 액세스하는 첫 번째 쿼리에 의해 클린아웃되는 것이다.
• 트랜잭션이 갱신한 블록 개수가 총 버퍼 캐시 블록 개수의 1/10을 초과할 때 사용한다.
• 커밋 이후 해당 블록을 액세스하는 첫 번째 쿼리에 의해 클린아웃된다.
• Delayed Block Cleanout시 기록 내역
  • Undo 세그먼트 헤더의 트랜잭션 테이블에는 Transaction Status가 기록된다.
  • 블록 헤더 ITL 슬롯에는 커밋 Flag과 커밋 SCN이 기록된다.
  • Redo 로그에는 Commit Mark가 기록된다.

    ✅ 블록을 읽는 과정에서 Active 상태의 블록을 만났을 때

    • Active 상태의 블록을 만난 경우 해당 블록은 다른 트랜잭션이 발생시킨 변경사항에 대한 커밋 정보가 ITL에 기록되지 않은 상태이다.
    • Delayed Block Cleanout 과정
      ① 블록 클린아웃을 먼저 시도한다.
      ② ITL 슬롯에 기록된 트랜잭션 ID를 확인 한다.
      ③ 확인한 ID를 이용해 Undo 세그먼트 헤더에 있는 트랜잭션 테이블 슬롯을 탐색한다.
      ④ 트랜잭션의 현재 상태가 커밋이라면 ITL 슬롯에 반영한다.
      ⑤ 로우 Lock 정보를 해제한다.

Redo 로그를 쓰는 경우

• 3초마다 DBWR 프로세스로 부터 신호를 받을때
• 로그 버퍼의 1/3이 차거나 기록된 Redo 레코드가 1MB를 넘을 때
• 사용자가 커밋 또는 롤백 명령을 날릴 때 (Log Force at Commit)

Write Ahead Logging

• 로그 선행 기록을 의미한다.
• 모든 수정은 실제 적용을 하기전에 로그에 먼저 기록되어야 한다.

1. SGA에서의 Write Ahead Logging

• 서버 프로세스가 변경 내용을 Redo 로그 버퍼에 먼저 기록 후 버퍼캐시의 데이터 블록을 갱신한다.

2. 디스크에서의 Write Ahead Logging

• LGWR 프로세스가 변경 내용을 Redo 로그에 먼저 기록 후 Dirty 데이터 블록을 디스크에 기록한다.
• log file sync
  • LGWR 프로세스가 Redo 로그 버퍼의 Redo 엔트리를 Redo 로그에 기록을 완료 할 때까지 발생 하는 대기 이벤트이다.

COMMIT_WRITE (파라미터)

1. COMMIT_WRITE(IMMEDIATE, WAIT)

• Redo Write를 즉각 요청한다.
• Server Process가 Redo Data를 Redo Log File에 기록을 완료할 때까지 대기한다.
• 시스템 기본값이다.

2. COMMIT_WRITE(IMMEDIATE, NOWAIT)

• Redo Write를 즉각 요청한다.
• Server Process가 Redo Data를 Redo Log File에 기록을 완료할 때까지 대기하지 않고 바로 커밋한다.
  • _WAIT_FOR_SYNC = FALSE 와 같은 효과이다.

3. COMMIT_WRITE(BATCH, WAIT)

• Redo Write를 모아서 요청한다.
• Server Process가 Redo Data를 Redo Log File에 기록을 완료할 때까지 대기한다.

4. COMMIT_WRITE(BATCH, NOWAIT)

• Redo Write를 모아서 요청한다.
• Server Process가 Redo Data를 Redo Log File에 기록을 완료할 때까지 대기하지 않고 바로 커밋한다.
• PL/SQL 블록 내의 Commit 과 같은 효과이다.

Redo 로깅 관련 모드

1. _DISABLE_LOGGING = TRUE

• Redo 로그에 기록하는것만 패스하는 것으로 위험한 파라미터이다.

2. NOLOGGING

• NOLOGGING 모드임에도 불구하고 Redo 레코드가 발생한다.
  • Data Dictionary 변경 내역
  • 새로 할당된 Extent 상태 변경(Invalid) 내역