DB Study

3장. PGA와 서버 프로세스

SGA가 모두의 작업대라면, PGA는 각 프로세스의 개인 책상입니다. 정렬과 해시가 벌어지는 이 사적 공간이 부족해지는 순간 — 쿼리는 소리 없이 디스크로 미끄러집니다.

중급 ⏱ 약 25분 🎬 애니메이션 2개 선수 지식: 1~2장
🧭
이 장에서 배우는 것

① PGA — 프로세스마다 갖는 사적 메모리 ② 구성 요소: SQL work area(정렬·해시)와 세션 메모리 ③ 정렬이 메모리를 초과하면 벌어지는 temp spill(one-pass/multi-pass) ④ PGA_AGGREGATE_TARGET과 dedicated/shared server의 PGA 위치 차이

3.1 PGA — 나눠 쓰지 않는 메모리

PGA(Program Global Area)는 서버 프로세스(그리고 백그라운드 프로세스)가 각자 하나씩 갖는 사적 메모리입니다. SGA와 달리 다른 프로세스는 이 공간을 들여다볼 수 없습니다. 세션이 100개면(dedicated 기준) PGA도 100개 — 그래서 인스턴스 전체 메모리를 계산할 때는 SGA + 모든 PGA의 합을 봐야 합니다.

SGAPGA
소유인스턴스에 하나 — 모든 프로세스가 공유프로세스마다 하나 — 사적 공간
할당 시점인스턴스 기동 시프로세스 생성 시 (세션 접속 시)
담는 것버퍼 캐시, Shared Pool, redo 버퍼 …정렬·해시 작업 공간, 세션 상태, 커서 실행 상태
관리 파라미터SGA_TARGETPGA_AGGREGATE_TARGET
비유사무실 공용 작업대·자료실직원 개인 책상
💡
왜 정렬을 SGA에서 안 할까?

정렬 중간 결과는 그 쿼리에게만 의미 있는 일회용 데이터입니다. 공유해 봐야 이득이 없고, 공유 메모리는 접근할 때마다 동시성 제어(래치) 비용이 듭니다. "공유하면 이득인 것(데이터 블록, 실행계획)은 SGA에, 나만 쓰는 것은 PGA에" — Oracle 메모리 설계의 대원칙입니다.

3.2 PGA 안에는 무엇이 있나

PGA는 크게 두 부류로 나뉩니다.

성능 관점의 주인공은 단연 work area입니다. 크기가 충분하면 정렬이 메모리에서 끝나고, 부족하면 디스크로 넘칩니다. 그 드라마를 애니메이션으로 봅시다.

3.3 정렬의 세 가지 운명 — optimal, one-pass, multi-pass

Oracle은 work area 크기에 따라 정렬 실행을 세 등급으로 부릅니다. optimal(전부 메모리에서), one-pass(디스크에 한 번 내렸다가 한 번의 병합으로 완료), multi-pass(병합을 여러 번 반복 — 가장 느림). 디스크로 내려간 중간 결과는 temp 테이블스페이스에 기록됩니다.

🪑 PGA — Sort Work Area 📋 테이블 스캔 ORDER BY name 데이터 전부가 work area 안에 쏙! ✅ optimal 메모리에서 정렬 완료 📚 대용량 테이블 ORDER BY … (수 GB) work area 초과! 🫗 💾 Temp 테이블스페이스 run 1 run 2 run 3 정렬된 조각(run)을 디스크로 spill 🔁 병합(merge) 한 번에 끝나면 one-pass, 여러 번이면 multi-pass(최악)

실행 등급별 통계는 인스턴스 누적 뷰에서 바로 확인할 수 있습니다. multi-pass가 눈에 띄게 잡히면 PGA 부족 신호입니다.

-- work area 실행이 어느 등급으로 끝났는지 (인스턴스 누적)
SELECT name, value
FROM   v$sysstat
WHERE  name LIKE 'workarea executions%';

NAME                              VALUE
--------------------------------  --------
workarea executions - optimal     1284933   ← 대부분 여기여야 정상
workarea executions - onepass          214
workarea executions - multipass          3  ← 0이 이상적
⚠️
temp spill은 조용히 일어난다

spill이 발생해도 쿼리는 에러 없이 그냥 느려질 뿐입니다. "어제는 빨랐는데 오늘은 느려요"의 흔한 범인 — 데이터가 늘어 optimal에서 one-pass로 넘어간 경우입니다. 실행계획의 TempSpc 컬럼, v$sql_workarea로 추적할 수 있습니다. PostgreSQL에서 work_mem을 넘겨 temp 파일로 spill되는 것과 완전히 같은 구도입니다(pg 2장).

3.4 PGA_AGGREGATE_TARGET — 개인 책상의 총예산

work area 크기를 쿼리마다 수동으로 정하는 건 불가능하니, Oracle은 자동 PGA 관리를 제공합니다. PGA_AGGREGATE_TARGET으로 인스턴스 전체 PGA 합계의 목표치를 정해주면, Oracle이 동시 실행 중인 쿼리들에게 work area를 알아서 배분합니다. 동시 세션이 적을 때는 한 쿼리가 큰 work area를 받고, 몰릴 때는 각자 조금씩 받는 식입니다.

-- PGA 목표치와 실제 사용 현황
SHOW PARAMETER pga_aggregate_target;

NAME                  TYPE         VALUE
--------------------- ------------ ------
pga_aggregate_target  big integer  4G

SELECT name, value/1024/1024 AS mb
FROM   v$pgastat
WHERE  name IN ('aggregate PGA target parameter',
                'total PGA allocated',
                'maximum PGA allocated');
💡
target은 "목표"지 "상한"이 아니다

세션 수가 폭증하면 실제 PGA 합계가 target을 넘을 수 있습니다. 진짜 상한은 별도 파라미터 PGA_AGGREGATE_LIMIT이 담당하며, 이를 초과하면 Oracle이 가장 많이 쓰는 세션의 호출을 중단시킵니다. "target = 노력 목표, limit = 안전 차단기"로 기억하세요.

3.5 Dedicated vs Shared Server — 내 세션 메모리는 어디에

1장에서 예고한 퍼즐을 풀 차례입니다. 세션 상태(UGA)는 dedicated server에서는 PGA 안에 있지만, shared server에서는 SGA로 이사합니다. 이유는 단순합니다 — shared server에서는 내 요청을 매번 다른 공유 프로세스가 처리할 수 있는데, PGA는 사적 공간이라 다른 프로세스가 볼 수 없기 때문입니다.

Dedicated Server 프로세스 1 프로세스 2 프로세스 3 PGA+UGA PGA+UGA PGA+UGA 세션 1개 = 전담 프로세스 1개 Shared Server 📮 Dispatcher 요청을 큐에 분배 공유 P1 공유 P2 세션 100개도 프로세스는 몇 개뿐 🧠 SGA (Large Pool) UGA 세션1 UGA 세션2 UGA 세션3 세션 상태를 공용 공간에 → 누구든 이어받기 가능 📌 정리 dedicated: UGA는 각자의 PGA 안에 shared: UGA는 SGA(Large Pool)로 이사

✍️ 이해도 체크

대용량 ORDER BY 정렬 중 PGA work area가 부족해지면 Oracle이 하는 일은?
✅ work area를 초과하면 정렬된 run을 temp 테이블스페이스로 spill하고 마지막에 병합합니다(one-pass/multi-pass). 에러 없이 조용히 느려지는 것이 함정 — v$sysstat의 workarea executions 통계나 실행계획의 TempSpc로 감지해야 합니다.
shared server 구성에서 세션 메모리(UGA)가 SGA에 놓이는 이유는?
✅ shared server에서는 내 세션의 이번 요청은 프로세스 P1이, 다음 요청은 P2가 처리할 수 있습니다. PGA는 프로세스 사적 공간이므로, 세션 상태(UGA)는 어느 프로세스든 읽을 수 있는 SGA(주로 Large Pool)에 두어야 합니다. dedicated에서는 전담 프로세스의 PGA 안에 있습니다.
📚
원문으로 더 깊이

Oracle Database 19c Concepts Guide — Memory Architecture의 PGA 절과 Process Architecture 장에서 work area 관리와 shared server 구조의 공식 설명을 볼 수 있습니다.