Oracle 프로세스 구조: Server Process·DBWn·LGWR·CKPT

핵심 요약

Oracle Process 구조는 요청을 보내는 주체, 사용자 호출을 실행하는 주체, Instance 공통 작업을 수행하는 주체로 나누면 이해하기 쉽습니다.

Client Process
→ Application 측에서 SQL·Bind·Fetch·Commit 요청을 전송

Server Process(Foreground Process)
→ Parse·Execute·Fetch·PL/SQL 실행
→ Buffer Cache와 PGA를 사용하고 필요한 Database I/O를 요청

Background Process
→ Instance 공통의 기록·Checkpoint·Recovery·Cleanup·Monitoring 수행

DML과 Commit의 핵심 흐름은 다음과 같습니다.

Client가 UPDATE 요청
→ Server Process가 Current Block을 확보하고 Row 변경
→ Undo와 Redo 생성, Buffer Cache Block은 Dirty 상태
→ Client가 COMMIT 요청
→ LGWR가 Commit Record와 관련 Redo를 Online Redo Log에 기록
→ Commit 성공 반환
→ DBWn은 이후 Dirty Buffer를 Datafile에 기록
→ CKPT는 Checkpoint 위치를 Control File·Datafile Header에 기록

핵심 판단 기준은 다음 네 가지입니다.

1. 사용자 SQL을 누가 실행하는가? → Server Process
2. Dirty Data Block을 누가 Datafile에 기록하는가? → DBWn
3. Redo를 누가 Online Redo Log에 기록하는가? → LGWR
4. Checkpoint 정보를 누가 기록하는가? → CKPT

학습 목표

• Client Process·Server Process·Background Process를 구분한다.
• Dedicated Server와 Shared Server에서 Database Call이 처리되는 경로를 설명한다.
• DBWn·LGWR·CKPT의 기록 대상과 상호 의존성을 구분한다.
• SMON·PMON Group·ARCn·LREG·RECO·MMON의 핵심 책임을 설명한다.
• UPDATE부터 COMMIT, Datafile Write, Instance Recovery까지의 흐름을 연결한다.
• V$SESSION, V$PROCESS, V$BGPROCESS, Wait Event를 이용해 Process 병목을 진단한다.
• Process와 Operating System Process·Thread를 동일 개념으로 단정하지 않는다.

1. Process 구조의 전체 지도

1.1 Client Process

Client Process는 Oracle Database 밖에서 요청을 보내는 Application 측 실행 주체입니다.

대표 예시는 다음과 같습니다.

• SQL*Plus·SQLcl
• Java·Python Application
• Web Application Server
• Batch Program
• BI·ETL Tool

Client Process는 Oracle Net을 통해 SQL Text, Bind 값, Fetch 요청, Commit·Rollback 요청을 보냅니다. Client가 Database Block을 직접 읽거나 SQL 실행계획을 수행하는 것은 아닙니다.

1.2 Server Process

Server Process는 Client의 Database Call을 받아 실제 Database 작업을 수행합니다.

주요 역할은 다음과 같습니다.

• SQL Parse와 Shared SQL Area 탐색
• Optimizer를 통한 실행계획 생성·선택
• SQL·PL/SQL Execute
• Buffer Cache Block 탐색과 Pin
• 필요한 Datafile Read 요청
• DML에 따른 Undo·Redo 생성
• Result Row Fetch와 Client 반환

Client Process
→ Oracle Net
→ Server Process
→ PGA·SGA 사용
→ Database File 접근 또는 Background Process에 Write 요청

Server Process는 일반적으로 사용자 요청을 수행하는 Foreground Process입니다. Parallel Execution에서는 Foreground가 Query Coordinator가 되고 Pnnn Parallel Worker가 작업을 나누어 수행할 수 있습니다.

1.3 Background Process

Background Process는 특정 Client 한 명의 일반 SQL을 대신 실행하는 Process가 아니라 Instance 운영에 필요한 공통 작업을 수행합니다.

Oracle 26ai에서는 Background Process를 V$PROCESS.PNAME이 NULL이 아닌 Process로 식별할 수 있습니다. 다만 THREADED_EXECUTION=TRUE인 환경에서는 여러 Oracle Process가 Operating System Thread로 실행될 수 있으므로 Oracle Process와 OS Process를 항상 1:1로 가정하면 안 됩니다.

2. Dedicated Server와 Shared Server

2.1 Dedicated Server

Dedicated Server에서는 하나의 Client Session에 하나의 Server Process가 전담 연결됩니다.

Client A ─ Server Process A
Client B ─ Server Process B
Client C ─ Server Process C

특징은 다음과 같습니다.

• Session과 Server Process의 관계가 단순하다.
• 긴 SQL, 큰 PGA Workarea, 관리 작업에 적합하다.
• Connection 수가 증가하면 Server Process 수와 PGA 사용량도 증가한다.
• Dedicated Session의 UGA는 해당 Server Process의 PGA에 위치한다.

2.2 Shared Server

Shared Server에서는 Client가 Server Process에 직접 고정 연결되지 않고 Dispatcher와 연결됩니다.

Client
→ Listener가 Dispatcher 주소 안내
→ Dispatcher
→ SGA의 Common Request Queue
→ 사용 가능한 Shared Server Process
→ Dispatcher별 Response Queue
→ Dispatcher
→ Client

중요한 점은 하나의 Session에서 발생한 Database Call마다 서로 다른 Shared Server Process가 처리할 수 있다는 것입니다. Parse 요청, 첫 Fetch, 다음 Fetch, Cursor Close가 각각 다른 Shared Server에서 수행될 수 있습니다.

따라서 Shared Server Session의 지속 상태인 UGA는 어느 Shared Server에서도 접근할 수 있도록 SGA에 위치합니다. Shared Server Process의 PGA에는 Process 전용 정보가 위치합니다.

2.3 Listener의 경계

Listener는 최초 Connection을 적절한 Service Handler로 전달합니다. 연결이 성립한 뒤 SQL Parse·Execute·Fetch를 수행하는 주체는 Server Process입니다.

Listener → 접속 중개
Server Process → SQL 처리

3. 핵심 Background Process 비교

SQLP에서는 Process 이름을 암기하는 데 그치지 않고 무엇을 어디에 기록하는지, 어떤 대기와 연결되는지, 다른 Process와 어떤 선후관계를 가지는지를 연결해야 합니다.

4. DBWn: Dirty Buffer를 Datafile에 기록

Server Process가 Buffer Cache의 Data Block을 변경하면 해당 Buffer는 Dirty 상태가 됩니다.

Datafile Block
→ Buffer Cache에서 Current Block 확보
→ DML 변경
→ Dirty Buffer
→ DBWn
→ Datafile

DBWn은 다음과 같은 상황에서 Dirty Buffer를 기록합니다.

• Server Process가 충분한 Clean Reusable Buffer를 찾지 못해 DBWn에 Write를 요청할 때
• Checkpoint 위치를 전진시키기 위해 주기적으로 Dirty Buffer를 기록할 때
• Checkpoint·Tablespace 상태 변경 등 Database가 Write를 요구할 때

DBWn은 가능한 경우 여러 Block을 묶어 기록합니다. Datafile의 Dirty Block은 물리적으로 흩어져 있을 수 있으므로 LGWR의 순차 Redo Write와 I/O 특성이 다릅니다.

4.1 Write-Ahead 원칙

DBWn이 변경된 Data Block을 Datafile에 쓰기 전에는 그 변경을 재현할 Redo가 먼저 Online Redo Log에 기록돼 있어야 합니다.

Redo 영속화
→ 그 Redo가 보호하는 Dirty Block의 Datafile Write 가능

DBWn이 아직 기록되지 않은 Redo를 발견하면 LGWR에 Flush를 요청하고 완료를 기다린 뒤 Data Block을 기록합니다. 이것이 장애 후 Redo로 변경을 재현할 수 있게 하는 Write-Ahead 원칙입니다.

4.2 관련 Wait Event

• db file parallel write: DBWn이 Datafile I/O 완료를 기다리는 시간
• free buffer waits: Foreground가 재사용 가능한 Buffer를 확보하지 못한 상황
• write complete waits: 필요한 Buffer의 Write 완료를 기다리는 상황

free buffer waits가 보인다고 Storage만 단정하지 않습니다. Dirty Buffer 생성 속도, DBWn 처리량, Checkpoint 압력, Buffer Cache 크기, Datafile I/O를 함께 확인합니다.

5. LGWR: Redo를 Online Redo Log에 기록

LGWR는 Redo Log Buffer의 Redo Entry를 현재 Online Redo Log Group에 기록합니다.

DML
→ Redo Log Buffer
→ LGWR
→ Online Redo Log

LGWR의 주요 Flush 조건은 다음과 같습니다.

• User Transaction이 Commit할 때
• Online Redo Log Switch가 발생할 때
• 마지막 Write 이후 약 3초가 지났을 때
• Redo Log Buffer가 약 1/3 차거나 1MB의 Buffered Redo를 포함할 때
• DBWn이 Dirty Buffer를 쓰기 전에 관련 Redo Write가 필요할 때

5.1 Fast Commit

일반적인 동기 Commit은 다음과 같이 처리됩니다.

Foreground가 COMMIT 요청
→ Commit Record와 관련 Redo를 준비
→ LGWR에 Flush 요청
→ LGWR가 Online Redo Log에 기록
→ Foreground에 완료 통지
→ Client에 COMMIT 성공 반환

Commit은 Transaction의 모든 Dirty Data Block이 Datafile에 기록될 때까지 기다리지 않습니다. Redo가 Durable해지면 장애 후 변경을 재현할 수 있기 때문에 Commit을 빠르게 반환할 수 있습니다.

5.2 관련 Wait Event

• log file sync: Foreground가 LGWR의 Commit Flush 완료와 Post를 기다림
• log file parallel write: LGWR가 Online Redo Log I/O 완료를 기다림
• log buffer space: Foreground가 Redo Log Buffer의 여유 공간을 기다림

log file sync가 높지만 log file parallel write가 낮다면 Redo Storage 외에도 과도한 Commit 빈도, CPU Scheduling, LGWR Posting 지연을 함께 확인합니다.

6. CKPT와 Checkpoint

Checkpoint Position은 Instance Recovery를 시작해야 하는 Redo Stream의 위치입니다. 이 위치는 Buffer Cache에서 가장 오래된 Dirty Buffer의 Redo 위치에 의해 결정됩니다.

CKPT의 핵심 역할은 다음과 같습니다.

• Checkpoint 요청을 시작하고 DBWn에 Dirty Buffer Write를 알림
• Control File에 Checkpoint 위치·SCN 기록
• 필요한 Checkpoint에서 Datafile Header에 Checkpoint 정보 기록

CKPT → Checkpoint 조정·Header 정보 기록
DBWn → Dirty Data Block Write
LGWR → Redo Write

CKPT는 Data Block을 Datafile에 직접 기록하지 않으며 Redo를 Online Redo Log에 직접 기록하지도 않습니다.

6.1 Incremental Checkpoint 주의점

DBWn이 Dirty Buffer를 기록하면 Checkpoint Position이 전진합니다. Incremental Checkpoint에서는 CKPT가 전진한 위치를 Control File에 기록하되 매번 모든 Datafile Header를 갱신하는 것은 아닙니다. 따라서 모든 Checkpoint를 동일한 File Header Write 패턴으로 단순화하면 안 됩니다.

6.2 Checkpoint의 목적

• Instance Recovery에서 적용할 Redo 범위를 줄임
• Dirty Buffer를 정기적으로 Datafile에 반영
• Consistent Shutdown에서 모든 Commit Data를 Disk에 반영
• Log Switch·Tablespace 상태 변경 등 File 상태 전환 지원

Checkpoint를 지나치게 공격적으로 밀면 Recovery 목표는 짧아질 수 있지만 Datafile Write 부하가 증가할 수 있습니다.

7. SMON과 Instance Recovery

비정상 종료 시 Commit된 변경 중 일부가 Datafile에 아직 기록되지 않았을 수 있고, 미커밋 변경이 Datafile에 이미 기록됐을 수도 있습니다.

Instance Recovery는 자동으로 다음 두 단계로 진행됩니다.

1. Roll Forward(Cache Recovery)
   → Online Redo를 적용해 필요한 변경을 Data Block에 재현
   → Commit·미커밋 변경 모두 Redo에 기록된 범위는 먼저 적용

2. Rollback(Transaction Recovery)
   → Undo를 사용해 미커밋 Transaction의 변경 제거
   → Commit된 결과만 남김

SMON이 Instance Recovery를 수행합니다. 큰 미완료 Transaction의 Rollback은 SMON이 계속 처리할 수 있고, 필요한 Block을 먼저 접근한 Foreground가 해당 Block의 Transaction Recovery를 수행할 수도 있습니다.

SMON은 Instance Recovery 외에도 Undo Segment 유지, 일시적으로 불일치한 Data Dictionary 정리, SCN-to-Time Mapping 유지 등의 System 작업을 수행합니다.

8. PMON Group과 Cleanup

비정상 종료한 Server Process가 남기고 간 자원은 정리돼야 합니다.

• Process·Session 상태
• Lock과 Transaction 상태
• Memory·Network 관련 자원
• Shared Server·Dispatcher 관련 상태

Oracle 26ai의 PMON Group은 다음처럼 이해합니다.

PMON
→ 비정상 종료 Process를 주기적으로 탐지
→ Cleanup 작업을 조정

CLMN·CLnn
→ PMON이 조정한 Cleanup 작업 수행

따라서 최신 구조에서 모든 Cleanup을 PMON 한 Process가 직접 수행한다고 단순화하지 않습니다. Listener Service 등록은 PMON이 아니라 LREG의 역할입니다.

PMAN은 Shared Server, Pooled Server, Job Queue Process, Restartable Background Process 등 여러 Process의 생성과 감시를 담당합니다.

9. ARCn·LREG·RECO·MMON

9.1 ARCn

ARCHIVELOG Mode에서 Log Switch가 완료된 Online Redo Log를 Archive Destination에 복사합니다.

LGWR → 현재 Online Redo Log에 기록
Log Switch
ARCn → 전환 완료 Log를 Archived Redo Log로 복사

Archived Redo Log는 Media Recovery, Point-in-Time Recovery, Standby Redo Apply에 사용됩니다. 다음 Group을 재사용해야 하는데 이전 Log가 Archive되지 않았다면 log file switch (archiving needed) 대기가 발생할 수 있습니다.

9.2 LREG

LREG는 Instance, Service, Dispatcher, Handler, Endpoint 정보를 Oracle Net Listener에 등록합니다. ALTER SYSTEM REGISTER는 즉시 등록을 요청할 때 사용합니다.

ALTER SYSTEM REGISTER;

Listener가 Service를 알고 있더라도 SQL을 실행하는 것은 아닙니다. Listener는 Connection을 Handler에 전달하고 이후 SQL은 Server Process가 처리합니다.

9.3 RECO

RECO는 Distributed Transaction의 Two-Phase Commit 중 장애로 In-Doubt 상태가 된 Transaction을 자동으로 해결합니다. 일반 단일 Instance의 Row Lock Cleanup이나 Instance Recovery를 담당하는 Process가 아닙니다.

9.4 MMON·MMNL

MMON과 MMNL은 AWR Snapshot, Metric, Alert 등 Manageability 작업을 수행합니다. 사용자 SQL의 Parse·Execute·Fetch를 대신하지 않습니다.

10. UPDATE와 COMMIT 전체 흐름

다음 SQL을 가정합니다.

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

COMMIT;

단계별 처리

1. Client가 UPDATE와 Bind 값을 전송
2. Server Process가 Parse·Execute
3. Buffer Cache에서 Current Block 확보, 없으면 Read 요청
4. Undo Block과 Data Block 변경
5. Undo 변경과 Data 변경에 대한 Redo 생성
6. Buffer Cache의 관련 Block이 Dirty 상태가 됨
7. Client가 COMMIT 요청
8. Server Process가 LGWR에 Commit Flush 요청
9. LGWR가 Commit Record와 관련 Redo를 Online Redo Log에 기록
10. Foreground가 완료 통지를 받고 Client에 Commit 성공 반환
11. DBWn이 이후 Dirty Buffer를 Datafile에 기록
12. CKPT가 Checkpoint 위치를 Control File·필요한 Datafile Header에 기록

Commit의 직접적인 내구성 경계는 LGWR의 Redo Write입니다. Datafile Write는 DBWn이 이후 수행할 수 있으며, DBWn Write 전에는 관련 Redo가 먼저 기록돼야 합니다.

11. Process와 Wait Event 진단

11.1 User Session과 Oracle Process 연결

SELECT s.sid,
       s.serial#,
       s.username,
       s.status,
       s.server,
       s.sql_id,
       s.event,
       s.state,
       p.pid,
       p.spid,
       p.sosid,
       p.stid,
       p.pname,
       p.program
FROM   v$session s
JOIN   v$process p
  ON   p.addr = s.paddr
WHERE  s.type = 'USER';

• V$SESSION.PADDR와 V$PROCESS.ADDR를 연결합니다.
• Threaded Execution에서는 OS Process ID 하나만으로 Oracle Process를 구분하기 어려울 수 있으므로 SOSID, STID, PNAME, PROGRAM을 함께 확인합니다.
• RAC에서는 GV$SESSION, GV$PROCESS와 INST_ID를 사용합니다.

11.2 실행 중인 Background Process

SELECT pid,
       spid,
       sosid,
       stid,
       pname,
       program,
       background
FROM   v$process
WHERE  pname IS NOT NULL
ORDER BY pname;

PNAME IS NOT NULL은 Oracle Background Process를 식별하는 공식 기준입니다. BACKGROUND Column만 단독 기준으로 사용하면 SYSTEM Background와 기타 Process 구분에서 누락이 생길 수 있습니다.

11.3 Background Process 정의와 실행 상태 연결

SELECT b.name,
       b.description,
       b.type,
       b.priority,
       p.spid,
       p.program
FROM   v$bgprocess b
LEFT JOIN v$process p
  ON   p.addr = b.paddr
ORDER BY b.name;

V$BGPROCESS는 Background Process의 이름과 설명을 제공하고 PADDR로 실행 Process와 연결할 수 있습니다.

11.4 현재 Non-Idle Wait 확인

SELECT s.sid,
       s.serial#,
       s.sql_id,
       s.event,
       s.wait_class,
       s.state,
       s.wait_time_micro,
       p.pname,
       p.spid
FROM   v$session s
JOIN   v$process p
  ON   p.addr = s.paddr
WHERE  s.state = 'WAITING'
AND    s.wait_class <> 'Idle';

현재 Wait 한 건만으로 원인을 확정하지 않습니다. AWR·ASH, Session 누적 통계, SQL 실행량, Commit 빈도, I/O 지연과 같은 시간 구간 증거를 결합합니다.

12. 증상과 Process 연결

진단 원칙

1. Wait가 발생한 주체가 Foreground인지 Background인지 확인합니다.
2. Wait Event가 표현하는 직접 대기 대상을 확인합니다.
3. 관련 Process의 처리량과 I/O를 같은 시간 구간에서 비교합니다.
4. 통계와 Wait Event를 원인 자체가 아니라 증거로 사용합니다.

13. 혼동 방지 표

14. 진단·적용 절차

단계 1: 업무 증상과 시간 구간 고정

• Commit 지연인지
• Query·DML 실행 지연인지
• Buffer 부족인지
• Log Switch 정체인지
• Service Registration 문제인지 구분합니다.

단계 2: Session과 Process 연결

V$SESSION.PADDR = V$PROCESS.ADDR로 Session, SQL_ID, Wait Event, OS 실행 주체를 연결합니다.

단계 3: 역할별 직접 증거 확인

• LGWR: log file sync, log file parallel write, Commit 수, Redo Byte
• DBWn: db file parallel write, free buffer waits, Dirty Buffer 발생량
• CKPT: Checkpoint 진행, Log Switch 대기
• ARCn: Archive Destination과 Archiving 대기
• LREG: Listener Service 등록 상태

단계 4: 누적값과 순간값 분리

Instance Startup 이후 누적 통계는 장애 구간 전후 Delta로 비교하고, 순간 V$SESSION Wait는 ASH·AWR와 함께 해석합니다.

단계 5: 변경 후 회귀 검증

Storage·Log 크기·Commit 단위·Process 설정을 변경했다면 다음을 함께 검증합니다.

• 처리량과 P95·P99 응답시간
• Redo Byte와 Commit 수
• Foreground·Background Wait 분포
• Recovery 목표와 Checkpoint 부하
• 오류·Rollback·장애 복구 동작

15. 핵심 정리

Server Process
→ 사용자 Database Call의 Parse·Execute·Fetch·DML 수행

DBWn
→ Dirty Buffer를 Datafile에 기록

LGWR
→ Redo를 Online Redo Log에 기록하고 동기 Commit 완료에 관여

CKPT
→ Checkpoint를 조정하고 Control File·Datafile Header에 위치 기록

SMON
→ Instance Recovery와 System 유지 작업

PMON Group
→ 비정상 Process 탐지와 Cleanup 조정

ARCn
→ 전환 완료 Redo Log를 Archive

LREG
→ Service·Handler 정보를 Listener에 등록

RECO
→ In-Doubt Distributed Transaction 해결