4장. 백그라운드 프로세스

여러분이 COMMIT을 누르는 순간, 디스크에 쓰이는 것은 데이터가 아니라 redo입니다 — 이 한 문장을 이해하면 Oracle의 쓰기 성능과 장애 복구가 한 줄로 꿰어집니다.

4.1 전체 지도 — 인스턴스를 움직이는 상근 직원들

서버 프로세스(3장)가 "손님(세션)을 응대하는 직원"이라면, 백그라운드 프로세스는 인스턴스가 기동될 때부터 종료될 때까지 각자 맡은 일만 반복하는 상근 직원들입니다. 서버 프로세스가 무거운 일(디스크 쓰기, 로그 관리, 청소)을 직접 하지 않고 이들에게 위임하기 때문에, 개별 쿼리가 빨라집니다.

먼저 전체 지도에서 일곱 주인공의 위치를 눈에 익히세요. 각 프로세스가 SGA의 어느 부분과 디스크의 어느 파일 사이에서 일하는지가 포인트입니다.

현재 인스턴스에서 실제로 돌고 있는 백그라운드 프로세스는 이렇게 확인합니다.

-- 지금 떠 있는 백그라운드 프로세스 목록
SELECT name, description
FROM   v$bgprocess
WHERE  paddr <> '00'   -- 실행 중인 것만
ORDER BY name;

NAME  DESCRIPTION
----  ----------------------------------
CKPT  checkpoint
DBW0  db writer process 0
LGWR  Redo etc.
PMON  process cleanup
SMON  System Monitor Process
...

4.2 DBWn — 서두르지 않는 기록자

2장에서 봤듯 UPDATE는 버퍼 캐시만 고치고 끝납니다. dirty buffer를 데이터파일에 실제로 쓰는 것은 DBWn입니다(쓰기 부하가 크면 DBW0, DBW1…처럼 여러 개를 둘 수 있어 n이 붙습니다). DBWn이 움직이는 대표적인 계기는:

• 서버 프로세스가 빈 버퍼를 못 찾을 때 (자리를 만들어야 함)
• 체크포인트가 발생했을 때 (CKPT의 지시)
• 주기적인 한가한 시점의 정리

중요한 것은 DBWn은 커밋과 무관하게 움직인다는 사실입니다. 커밋 안 된 변경도 자리가 필요하면 디스크에 쓰고, 커밋된 변경도 한참 뒤에 쓸 수 있습니다. "그래도 괜찮은" 이유가 다음 절의 LGWR입니다.

4.3 LGWR — 커밋의 실체

커밋의 내구성(durability)을 책임지는 것은 LGWR입니다. 세션이 COMMIT을 실행하면, LGWR이 그 트랜잭션의 redo entry를 온라인 리두 로그 파일에 물리적으로 쓸 때까지 세션은 기다립니다(이 대기가 그 유명한 log file sync 대기 이벤트입니다). 기록이 끝나야 "커밋 완료" 응답이 나갑니다.

왜 데이터 블록 대신 redo를 쓸까요? redo는 로그 파일 끝에 이어 쓰는 순차 쓰기라서 작고 빠릅니다. 반면 데이터 블록은 파일 여기저기에 흩어진 랜덤 쓰기죠. "빠른 순차 쓰기로 안전을 확보하고, 느린 랜덤 쓰기는 나중에 몰아서" — 이것이 Oracle 쓰기 성능의 비밀이며, PostgreSQL의 WAL(pg 9장)과 동일한 설계입니다.

-- 커밋 대기(log file sync)가 얼마나 발생했는지
SELECT event, total_waits, time_waited_micro/1000000 AS sec
FROM   v$system_event
WHERE  event = 'log file sync';

EVENT           TOTAL_WAITS  SEC
--------------  -----------  ------
log file sync       9214432  518.3

4.4 CKPT — "여기까지는 반영됨" 책갈피

CKPT(Checkpoint Process)는 체크포인트 시점마다 컨트롤파일과 데이터파일 헤더에 체크포인트 위치를 기록하고, DBWn에게 dirty buffer 기록을 지시합니다. 체크포인트 위치는 "redo 스트림의 이 지점까지는 데이터파일에 반영 완료"라는 책갈피입니다.

이 책갈피의 존재 이유는 복구 시간 단축입니다. 크래시 후 복구할 때 redo 전체가 아니라 마지막 체크포인트 이후의 redo만 재생하면 되기 때문입니다. 책갈피가 자주 갱신될수록(체크포인트가 잦을수록) 복구는 빨라지지만 평상시 I/O 부담이 늘어나는 트레이드오프가 있습니다 — 7장에서 자세히 다룹니다.

4.5 SMON — 크래시에서 살려내는 복구 반장

SMON(System Monitor)의 대표 임무는 인스턴스 복구(instance recovery)입니다. 정전 등으로 인스턴스가 갑자기 죽으면 메모리(SGA)의 내용은 모두 증발합니다. 커밋됐지만 데이터파일에 아직 안 쓰인 변경(dirty buffer였던 것들)도 함께요. 재기동 시 SMON이 redo와 undo를 이용해 데이터베이스를 일관된 상태로 되돌립니다. 그 밖에 쓰다 버려진 임시 세그먼트 정리 같은 청소 업무도 SMON 담당입니다.

4.6 나머지 상근 직원들 — PMON · ARCn · MMON

✍️ 이해도 체크