꿈꾸는 개발자, DBA 커뮤니티 구루비

DBWR

변경된 데이터베이스 버퍼를 메모리에서 디스크로 즉시 기록할 필요는 없다.
제한된 메모리를 가지므로, 버퍼 캐시가 N블록 저장할 수 있는 크기인 경우 N+1 블록을 변경 시 디스크로 기록이 필요하다.
언제 디스크로 기록을 수행하고 / 어떤 방식으로 기록할 블록을 선택할 것인가 ?
디스크에 저장된 데이터 블록 + 리두 적용 = 메모리상에 존재하는 버퍼와 일치.
현재 디스크에 저장된 데이터 블록의 SCN (last change SCN)을 확인
해당 SCN을 소유한 리두 로그를 찾고 해당 시점부터 현재까지의 모든 체인지 벡터를 블록에 적용.
DB캐시 내 데이터 블록 손상 시 복구
위 절차에서는 온라인 리두로그만 대상으로 하며, 복구 절체 수행하는 동안에는 해당 버퍼에 독점적으로 pin을 설정.
RMAN의 block recover 기능은 아카이브 리두로그를 읽는 것이 가능.
automatic block mediate recovery 기능은 리두와 아카이브 로그를 이용한다.

위 방법으로 복구 수행 시 엄청난 양의 리두를 적용해야 할 수 있다.

블록이 메모리 내에서 처음으로 변경된 시점을 관리함으로써, "가장 오래된 버퍼 먼저" 디스크 로 기록하는 전략을 사용.

체크포인트 큐

각 working data set 은 두 개의 체크포인트 큐를 가진다.
버퍼를 변경하려는 세션이, 버퍼가 속한 working database set 을 관리하는 checkpoint queue latch 래치 중 하나를 획득.
해당 버퍼를 체크포인트 큐의 최근 끝 위치에 연결한다.
LRBA를 설정한다. ( 연관 리두레코드의 low redo block address. log file seq#.log file block# 형식으로 표현)
이는 redo block address 순으로 연결됨을 뜻한다.
래치 획득 방식은 immediate 모드. 버퍼가 체크포인트 큐에 연결될 때 까지 래치 소유.

이러한 변경된 버퍼를 체크포인트 큐에 연결하는 절차는
버퍼가 더티상태가 되는 경우, 블록 복제 (Cloning) 시에도 발생.
테이블 스캔 방식으로 update 수행 시 cloning 동작
- 세션은 current 블록을 복제, 해당 복제본을 current 블록으로 사용한다.
  (switch current to new buffer 성능통계에서 확인 가능. 기존 current 블록은 CR블록이 됨)

체크포인트 큐 내의 복제 버퍼(헤더) 교환방식

복제 버퍼는 체크포인트 큐 내의 동일한 위치로 교체되므로, 버퍼 헤더의 LRBA 는 변경되지 않는다.
HSCH (high SCN), HSBU (high Sub-SCN) 은 current SCN으로 변경된다.
DBWR은 해당 값을 이용하여 버퍼의 최근 변경시점을 확인.
이러한 연결 과정에서 사용되는 모든 매커니즘(link/unlink)은
다수 세션들이 동시에 동일 작업을 수행할 수 있기에 래치에 의해 보호되어야 한다.

Incremental 체크포인트

DBWR 체크포인트 큐에 버퍼가 존재하는지 확인 작업
: willing-to-wait 모드로 checkpoint queue latch 래치 순차적으로 획득한다.
큐에 버퍼가 존재할 경우
- checkpoint RBA에 도달할 때까지 버퍼의 LRBA와 checkpoint RBA를 비교하며,
  버퍼를 디스크로 기록한 후 큐로부터 분리함.
- 이로써 버퍼는 clean 상태로 표시, LRBA:는 정리된다.
큐에 버퍼가 존재하지 않을 경우
- dbwr sleep.
  incremental 체크포인트 관련파라미터
fast_start_mttr_target
fast_start_io_target
log_checkpoint_timeout
log_checkpoint_interval
_target_rba_max_lag_percentage

incremental 체크포인트는 데이터 현재상태에 매우 근접한 스냅샷 보장.

지속적으로 목표 (checkpoint RBA)를 앞으로 이동하면서 더티버퍼를 디스크로 기록.

current 리두로그 이전의 온라인 리두 로그 없이도 복구가 가능할 것이다.