Oracle 메모리 구조: SGA·PGA·UGA와 Workarea

핵심 요약

Oracle 메모리는 공유 범위, 소유 단위, 저장하는 상태, 부족할 때 나타나는 증거를 기준으로 구분해야 합니다.

SGA(System Global Area)
→ Instance 단위의 공유 메모리
→ Server Process와 Background Process가 함께 사용
→ Buffer Cache·Shared Pool·Redo Log Buffer 등

PGA(Program Global Area)
→ Oracle Process 또는 Thread별 비공유 메모리
→ 다른 Process와 공유하지 않음
→ Process 상태·Private SQL Area·SQL Workarea 등

UGA(User Global Area)
→ Session의 지속 상태
→ Dedicated Server에서는 PGA
→ Shared Server에서는 SGA의 Large Pool, Large Pool이 없으면 Shared Pool

SQL Workarea
→ Sort·Hash Join·Hash Group By·Bitmap 작업용 메모리
→ 메모리 부족 시 TEMP를 사용해 One-Pass 또는 Multi-Pass 실행

Oracle AI Database 26ai 문서는 기존 SGA·PGA·UGA 외에 일부 신뢰 Process가 선택적으로 연결하는 MGA(Managed Global Area)도 정의합니다. 다만 SQLP의 기본 출발점은 여전히 SGA·PGA·UGA와 Workarea의 역할 및 진단입니다.

학습 목표

• SGA와 PGA를 공유 범위·생성 단위·생명주기로 구분한다.
• Database Buffer Cache·Shared Pool·Redo Log Buffer의 저장 대상을 설명한다.
• Shared SQL Area와 Private SQL Area의 관계를 설명한다.
• UGA가 Session 상태이며 Dedicated·Shared Server에서 위치가 달라지는 이유를 설명한다.
• Shared Server에서 Private SQL Area의 Persistent Area와 Run-Time Area 위치를 구분한다.
• Workarea의 Optimal·One-Pass·Multi-Pass와 TEMP I/O를 연결한다.
• PGA_AGGREGATE_TARGET과 PGA_AGGREGATE_LIMIT을 목표와 제한으로 구분한다.
• V$PGASTAT, V$PROCESS, V$SQL_WORKAREA를 이용해 Instance·Process·SQL 단위로 진단한다.
• Oracle AI Database 26ai의 MEMORY_SIZE와 기존 MEMORY_TARGET·SGA_TARGET 기반 관리를 구분한다.

1. Oracle 메모리의 전체 지도

Oracle Instance의 주요 메모리
├─ SGA: Instance 공유
│  ├─ Database Buffer Cache
│  ├─ Shared Pool
│  │  ├─ Library Cache
│  │  ├─ Data Dictionary Cache(Row Cache)
│  │  └─ Server Result Cache 등
│  ├─ Redo Log Buffer
│  ├─ Large Pool
│  ├─ Java Pool
│  ├─ In-Memory Area 등 선택 영역
│  └─ Fixed SGA
│
├─ 각 Oracle Process의 PGA
│  ├─ Process 전용 상태·Stack
│  ├─ Private SQL Area의 Run-Time 정보
│  └─ Sort·Hash·Bitmap Workarea
│
├─ UGA: Session 상태
│  ├─ Dedicated Server: PGA
│  └─ Shared Server: SGA(Large Pool 우선, 없으면 Shared Pool)
│
└─ MGA: 일부 신뢰 Process가 선택적으로 공유하는 26ai 메모리 Framework

다음 질문으로 위치를 판단합니다.

여러 Process가 같은 Block·SQL·Redo 구조를 함께 재사용해야 하는가?
→ SGA

특정 Process가 현재 Operation을 수행하기 위한 전용 공간인가?
→ PGA

Server Process가 바뀌어도 Session 생명주기 동안 유지돼야 하는가?
→ UGA

SGA 안에 Process가 들어 있는 것은 아닙니다. SGA는 공유 메모리이고 Server·Background Process는 별도의 실행 주체로서 SGA를 읽고 씁니다.

2. SGA: Instance 단위의 공유 메모리

SGA는 Instance Startup 시 할당되고 Shutdown 시 회수되는 읽기·쓰기 공유 메모리입니다. 각 Database Instance는 자신의 SGA를 가지며, 그 Instance의 Server Process와 Background Process가 접근합니다.

2.1 공유 메모리의 장점과 비용

공유 재사용
→ 같은 Data Block을 반복해서 Disk에서 읽는 비용 감소
→ 같은 SQL·PL/SQL 실행 구조의 Hard Parse 감소
→ Session 간 공통 Metadata 재사용

공유 접근
→ 여러 Process가 같은 구조를 동시에 보호·변경
→ Latch·Mutex·Pin 등 동기화 필요
→ Hot Structure에 접근이 집중되면 경합 발생 가능

SGA 크기만 늘리기 전에 어떤 Component가 부족한지, 실제 재사용 실패인지, SQL 구조 문제인지 확인해야 합니다.

3. Database Buffer Cache: Data Block의 메모리 복사본

Database Buffer Cache는 Datafile에서 읽은 Oracle Data Block의 복사본을 저장합니다.

Server Process가 Block 요청
→ Buffer Cache에서 탐색
   ├─ Cache Hit: 메모리 Block 사용
   └─ Cache Miss: Datafile에서 읽어 Cache에 적재

Table·Index·Undo 등 Database Block이 대상입니다. Query가 반환한 최종 100행을 Result Set 형태로 저장하는 일반 Query Result Cache와는 다릅니다.

DML은 Buffer Cache의 Block을 변경하고 Dirty Buffer를 만듭니다.

Block Read
→ Buffer Cache 적재
→ DML로 메모리 Block 변경
→ Dirty Buffer
→ DBWn이 이후 Datafile에 기록

Commit은 Dirty Buffer의 Datafile 기록 완료를 기다리는 사건이 아닙니다. 일반적인 동기 Commit의 핵심은 LGWR가 Commit Record를 포함한 Redo를 Online Redo Log에 기록하는 것입니다.

4. Shared Pool: 실행 구조와 Metadata 재사용

Shared Pool의 핵심은 Library Cache와 Data Dictionary Cache입니다.

4.1 Library Cache

Library Cache는 다음과 같은 실행 가능한 구조와 제어 정보를 저장합니다.

• Shared SQL Area의 Parse Tree와 Execution Plan
• PL/SQL Program Unit의 실행 형태
• Library Cache Handle·Lock·Dependency 정보

동일 SQL 실행
→ 공유 가능한 Cursor 탐색
   ├─ 재사용 가능: Soft Parse 또는 Library Cache Hit
   └─ 재사용 불가: 새 실행 형태 생성, Hard Parse 비용 발생

4.2 Shared SQL Area와 Private SQL Area

Shared SQL Area
→ SQL Text의 Parse 표현과 Execution Plan
→ 여러 Session이 공유 가능

Private SQL Area
→ Bind 값·실행 상태·Fetch 상태 등 Session별 정보
→ 각 실행은 자신의 Private SQL Area를 사용

여러 Session이 같은 Plan을 공유해도 Private SQL Area는 실행·Session별로 별도 존재할 수 있습니다.

4.3 Data Dictionary Cache

Data Dictionary Cache는 Row Cache라고도 하며 Object 정의와 권한 같은 Metadata를 빠르게 조회합니다.

• Table·Column 정의
• User·Privilege 정보
• Object 속성과 Dependency
• 일부 Storage·Segment Metadata

Parse 시 Object 존재, Column Type, 권한 등을 확인하므로 Dictionary Cache Miss도 Parse 비용과 연결됩니다.

4.4 Shared Pool 문제의 대표 원인

• Literal이 다른 유사 SQL 대량 생성
• Hard Parse와 Library Cache Miss 증가
• Child Cursor 과다 생성
• Object Invalidations와 반복 DDL
• Shared Pool 부족 또는 Fragmentation
• 특정 Library Cache Object 접근 집중

Shared Pool을 키우기 전에 SQL Text 표준화, Bind 사용, Child Cursor 분리 원인, Invalidations를 먼저 확인합니다.

5. Redo Log Buffer: Redo의 임시 공유 공간

Redo Log Buffer는 SGA의 순환 Buffer이며 Database 변경을 설명하는 Redo Entry를 임시 저장합니다.

DML
→ Redo 생성
→ Redo Log Buffer
→ LGWR
→ Online Redo Log

Redo Log Buffer는 휘발성 메모리입니다. LGWR가 Redo를 Online Redo Log에 기록한 뒤 장애 복구에 사용할 수 있는 Durable Redo가 됩니다.

Commit 요청
→ Commit Record와 관련 Redo를 LGWR가 기록
→ 일반적인 동기 Commit에서는 Foreground가 기록 완료를 기다림
→ Dirty Buffer는 DBWn이 이후 Datafile에 기록 가능

따라서 Buffer Cache와 Redo Log Buffer의 역할은 다음과 같이 구분합니다.

Buffer Cache
→ 변경된 Data Block의 현재 메모리 복사본

Redo Log Buffer
→ 변경을 재현하기 위한 Redo Entry의 임시 Buffer

6. Large Pool과 선택적 SGA Component

Large Pool은 Shared Pool의 LRU Cache와 분리된 선택적 공유 메모리 영역으로, 큰 Allocation에 사용됩니다.

대표 사용처는 다음과 같습니다.

• Shared Server의 UGA
• Parallel Execution Message Buffer
• RMAN I/O Worker Buffer
• Oracle XA 관련 Session Memory
• 일부 Fast Ingest Buffer

Shared Server의 UGA를 Large Pool에 배치하면 Shared Pool을 Shared SQL·Dictionary Cache에 더 집중해서 사용할 수 있고, 큰 Session Allocation으로 인한 Shared Pool Fragmentation을 줄일 수 있습니다. Large Pool이 구성되지 않으면 Shared Server UGA가 Shared Pool을 사용할 수 있습니다.

그 밖의 Component는 기능을 사용할 때 의미가 있습니다.

Buffer Cache, Library Cache, Result Cache는 저장 대상이 서로 다릅니다.

7. PGA: Process별 비공유 메모리

PGA는 Oracle Process 또는 Thread가 시작될 때 생성되는 비공유 메모리입니다.

Server Process A → PGA A
Server Process B → PGA B
LGWR             → LGWR의 PGA
DBWn             → DBWn의 PGA

각 PGA의 합이 Instance PGA입니다. PGA_AGGREGATE_TARGET과 같은 Parameter는 개별 PGA를 동일 크기로 고정하는 값이 아니라 Instance 전체 PGA와 자동 Workarea 배분에 영향을 주는 목표입니다.

7.1 PGA의 대표 내용

• Process 전용 제어 상태와 Stack
• Private SQL Area의 Run-Time Area
• Sort·Hash Join·Hash Group By·Bitmap Workarea
• PL/SQL·Java 등 Process 전용 Allocation

PGA 사용량은 Workarea만으로 구성되지 않습니다. Session State, PL/SQL, Java, Network Buffer 등 다른 소비자가 있어 PGA_AGGREGATE_TARGET을 Workarea 하나의 크기로 해석하면 안 됩니다.

8. Private SQL Area: Dedicated와 Shared Server의 차이

Private SQL Area는 Parsed SQL을 실행하기 위한 Session별 정보를 보관합니다.

• Bind Variable Value
• Query Execution State
• Cursor·Fetch 상태
• Run-Time Memory

Dedicated Server에서는 Session과 Server Process가 밀접하게 연결되므로 Private SQL Area가 PGA에 위치합니다.

Shared Server에서는 Private SQL Area를 두 관점으로 나눠야 합니다.

Persistent Area
→ Database Call 사이에도 유지해야 하는 Session 상태
→ UGA에 포함
→ SGA의 Large Pool, Large Pool이 없으면 Shared Pool

Run-Time Area
→ 현재 DML·DDL Call을 실행하는 동안 필요한 작업 상태
→ 해당 Call을 처리하는 Shared Server Process의 PGA

따라서 “Private SQL Area는 항상 PGA”라는 문장은 Shared Server를 포함하면 부정확합니다. 반대로 Workarea의 Run-Time Allocation은 Shared Server에서도 Process PGA에서 사용됩니다.

9. UGA: Session 생명주기 동안 유지되는 상태

UGA는 User Session과 연결된 메모리로 Session State를 저장합니다.

대표 정보는 다음과 같습니다.

• Logon·Session 정보
• PL/SQL Package State
• Application Context
• Cursor의 Persistent State 일부
• Shared Server Virtual Circuit 관련 상태

9.1 Dedicated Server

한 Session
→ 한 Dedicated Server Process와 지속적으로 연결
→ UGA를 해당 Process의 PGA에 저장 가능

9.2 Shared Server

한 Session의 Parse·Execute·Fetch·Close Call
→ 서로 다른 Shared Server Process가 처리할 수 있음
→ 특정 Process PGA에 Session State를 고정할 수 없음
→ 모든 Shared Server가 접근 가능한 SGA에 UGA 저장

Large Pool이 있으면 UGA를 Large Pool에 두는 것이 권장되며, 없으면 Shared Pool을 사용할 수 있습니다.

핵심 구분은 다음과 같습니다.

PGA의 소유 단위 → Process
UGA의 소유 단위 → Session

10. SQL Workarea와 TEMP Spill

SQL Workarea는 메모리 집약 Operation이 실행 중 사용하는 PGA Allocation입니다.

10.1 Optimal·One-Pass·Multi-Pass

Optimal
→ 필요한 중간 상태가 Workarea Memory에 들어감
→ TEMP에 중간 결과를 Spill하지 않고 완료

One-Pass
→ Workarea가 Optimal 요구량보다 작음
→ 입력 일부를 TEMP에 기록하고 한 번의 추가 Pass로 완료

Multi-Pass
→ One-Pass 요구량보다도 Memory가 부족
→ TEMP를 여러 번 읽고 쓰며 처리
→ 일반적으로 I/O와 응답시간 부담이 가장 큼

One-Pass나 Multi-Pass가 발생했다고 무조건 Memory Parameter부터 늘리면 안 됩니다.

• Build Input이 불필요하게 큼
• Predicate가 늦게 적용됨
• Cardinality Estimation 오류
• 넓은 Row와 불필요 Column
• Data Skew
• 동시 실행 Workarea 급증
• 부적절한 Join Order·Join Method

SQL로 입력량을 줄이거나 Plan을 개선할 수 있는지 먼저 확인한 뒤 Instance 전체 Memory와 동시성을 검토합니다.

11. Workarea 자동 관리

WORKAREA_SIZE_POLICY=AUTO이면 Oracle은 시스템 PGA 사용량, PGA_AGGREGATE_TARGET, 각 Operator 요구량을 바탕으로 Workarea를 자동 조정합니다. PGA_AGGREGATE_TARGET을 0이 아닌 값으로 설정하면 WORKAREA_SIZE_POLICY는 자동으로 AUTO가 됩니다.

11.1 PGA_AGGREGATE_TARGET

• 모든 Server Process가 사용하는 Aggregate PGA의 목표
• Automatic Workarea Sizing의 기준
• Hard Limit가 아니라 Target
• Workload 급증과 Untunable PGA 때문에 일시적으로 초과 가능

V$PGASTAT의 aggregate PGA auto target은 PGA_AGGREGATE_TARGET 자체와 같지 않습니다. Session Memory 등 다른 PGA 소비를 제외하고 자동 Workarea가 사용할 수 있는 현재 총량입니다.

11.2 PGA_AGGREGATE_LIMIT

• Instance Aggregate PGA의 제한
• 초과 시 Parallel Query를 하나의 단위로 취급
• Untunable PGA를 많이 사용하는 Session의 Call을 먼저 종료
• 계속 초과하면 해당 Session 자체를 종료할 수 있음
• SYS Process와 일부 Background Process는 종료 대상에서 제외

따라서 Limit은 일반적인 Workarea 크기 조정값이 아니라 Instance 보호 장치입니다.

12. Oracle AI Database 26ai 메모리 관리 변화

기존 시험과 운영 환경에서는 다음 방식이 널리 사용됩니다.

Oracle AI Database 26ai는 Unified Memory Management를 위한 MEMORY_SIZE를 추가했습니다.

MEMORY_SIZE > 0
→ Instance 전체 사용 가능 메모리를 통합 관리
→ SGA·PGA·MGA·UGA 등 비율을 Workload에 따라 조정
→ CDB 수준 SGA_TARGET·SGA_MAX_SIZE·PGA_AGGREGATE_LIMIT 설정은 무시될 수 있음
→ MEMORY_TARGET과 MEMORY_MAX_TARGET은 0으로 두어야 함

SQLP에서는 전통적 SGA·PGA 구조와 Parameter 역할을 우선 이해하되, 26ai 환경에서 MEMORY_SIZE가 활성화되면 기존 Parameter 해석이 달라진다는 점을 확인해야 합니다.

12.1 MGA

MGA는 SGA처럼 모든 Server·Background Process가 항상 연결하는 영역이 아니라, 일부 신뢰 Oracle Process가 필요에 따라 선택적으로 연결하고 Memory를 조정·재사용할 수 있는 반공유 Framework입니다.

SGA → Instance의 일반 공유 메모리
PGA → 한 Process의 비공유 메모리
MGA → 선택된 신뢰 Process 집합이 연결하는 26ai 반공유 메모리

MGA를 SGA의 단순 별칭이나 개별 PGA의 합으로 해석하면 안 됩니다.

13. 진단 View와 SQL

13.1 SGA 구성 확인

SELECT name,
       ROUND(bytes / 1024 / 1024, 1) AS mb,
       resizeable
FROM   v$sgainfo
ORDER BY bytes DESC;

SELECT pool,
       name,
       ROUND(bytes / 1024 / 1024, 1) AS mb,
       allocation_count
FROM   v$sgastat
ORDER BY bytes DESC;

V$SGASTAT은 SGA의 상세 Allocation을 보여 주며, 26ai의 일부 Release Update에서는 ALLOCATION_COUNT도 제공합니다.

13.2 Instance PGA 상태

SELECT name,
       value,
       unit
FROM   v$pgastat
ORDER BY name;

중요 항목은 다음과 같습니다.

V$PGASTAT의 누적값은 Instance Startup 이후 계속 쌓이므로 장애 구간의 시작·종료 Snapshot 차이로 해석해야 합니다.

13.3 Process별 PGA

SELECT s.sid,
       s.serial#,
       p.spid,
       p.pga_used_mem,
       p.pga_alloc_mem,
       p.pga_freeable_mem,
       p.pga_max_mem
FROM   v$session s
JOIN   v$process p
  ON   p.addr = s.paddr
WHERE  s.type = 'USER';

PGA_USED_MEM     → 현재 사용 중
PGA_ALLOC_MEM    → Process가 현재 확보한 총량
PGA_FREEABLE_MEM → OS에 반환 가능할 수 있는 Allocation
PGA_MAX_MEM      → Process 생명주기 중 최대 할당량

13.4 SQL별 Workarea

SELECT sql_id,
       operation_type,
       policy,
       estimated_optimal_size,
       estimated_onepass_size,
       last_memory_used,
       last_execution,
       last_tempseg_size,
       optimal_executions,
       onepass_executions,
       multipasses_executions
FROM   v$sql_workarea
WHERE  sql_id = :sql_id
ORDER BY operation_id;

LAST_EXECUTION은 마지막 실행의 OPTIMAL, ONE PASS, MULTI-PASS 상태를 보여 줍니다. LAST_TEMPSEG_SIZE는 마지막 실행에서 TEMP Spill이 없으면 NULL입니다.

현재 실행 중인 Workarea는 V$SQL_WORKAREA_ACTIVE, Instance 전체 분포는 V$SQL_WORKAREA_HISTOGRAM으로 확인할 수 있습니다. Histogram도 Startup 이후 누적값이므로 구간 Snapshot을 비교합니다.

13.5 PGA 변경 효과 예측

SELECT pga_target_for_estimate,
       pga_target_factor,
       estd_extra_bytes_rw,
       estd_pga_cache_hit_percentage,
       estd_overalloc_count
FROM   v$pga_target_advice
ORDER BY pga_target_for_estimate;

V$PGA_TARGET_ADVICE는 과거 Workload를 바탕으로 다른 Target에서 예상되는 추가 I/O와 Over-Allocation을 보여 줍니다. STATISTICS_LEVEL=BASIC이거나 Target이 설정되지 않으면 Advice가 제공되지 않을 수 있습니다.

14. 진단 절차

1. 문제 범위를 구분한다.
   ├─ Instance 전체 PGA 압력인가?
   ├─ 특정 Process의 Untunable PGA 증가인가?
   └─ 특정 SQL Workarea Spill인가?

2. Instance 증거를 수집한다.
   → V$PGASTAT 시작·종료 Delta
   → V$SQL_WORKAREA_HISTOGRAM Delta
   → V$PGA_TARGET_ADVICE

3. Process 증거를 수집한다.
   → V$PROCESS의 USED·ALLOC·FREEABLE·MAX
   → Session·Module·SQL_ID 연결

4. SQL 증거를 수집한다.
   → V$SQL_WORKAREA·V$SQL_WORKAREA_ACTIVE
   → 실행계획의 실제 Row·Memory·Temp
   → Input Row 수·Row 폭·Predicate 적용 시점

5. 개선 우선순위를 정한다.
   → 불필요 입력·정렬·Hash 제거
   → Cardinality·Join Order·Access Path 개선
   → 동시 실행량 제어
   → 그 후 PGA Target·Limit·통합 Memory 설정 검토

사례: Hash Join TEMP Spill

관찰
→ V$SQL_WORKAREA.LAST_EXECUTION='MULTI-PASS'
→ LAST_TEMPSEG_SIZE 큼
→ 같은 시간 global memory bound 급락

해석
→ 해당 SQL의 Build Input 문제와 Instance 동시 Workarea 압력이 함께 존재할 수 있음

조치
→ Build Input·Filter·통계·Skew를 먼저 검토
→ 동시 실행량과 V$PGASTAT Delta 확인
→ V$PGA_TARGET_ADVICE로 Target 변경 효과 검증

단일 통계 하나만으로 원인을 확정하지 않습니다.

15. 혼동하기 쉬운 판단

16. 핵심 정리

SGA
→ Instance 공유
→ Buffer Cache·Shared Pool·Redo Log Buffer·Large Pool

PGA
→ Process 비공유
→ Process 상태·Run-Time Private SQL Area·SQL Workarea

UGA
→ Session 상태
→ Dedicated: PGA
→ Shared: SGA의 Large Pool 또는 Shared Pool

Workarea
→ Optimal: Memory 완료
→ One-Pass: TEMP 한 번의 추가 Pass
→ Multi-Pass: TEMP 여러 Pass

PGA_AGGREGATE_TARGET
→ 자동 Workarea를 포함한 Aggregate PGA Target

PGA_AGGREGATE_LIMIT
→ Aggregate PGA 보호 Limit

26ai MEMORY_SIZE
→ SGA·PGA·MGA·UGA 등을 통합 관리하는 신규 방식