Oracle SGA vs PGA Memory: The Difference, Explained

The SGA is shared memory every process in the instance can see; the PGA is private memory for one session alone. Here's what each one actually holds, and how they're sized.

Shared memory vs private memory

The SGA (System Global Area) is a chunk of shared memory allocated once when the Oracle instance starts, used by every background and server process. The PGA (Program/Process Global Area) is private memory allocated separately for each individual server process — one session's PGA content is invisible to every other session.

SGA vs PGA at a glance

	SGA	PGA
Shared or private?	shared across the whole instance	private to a single server process
Allocated	once, at instance startup	per session/process, as needed
Main contents	buffer cache, shared pool (library cache + dictionary cache), redo log buffer	sort areas, hash join work areas, cursor state, session variables
Sized via	SGA_TARGET / SGA_MAX_SIZE (or MEMORY_TARGET for combined auto-tuning)	PGA_AGGREGATE_TARGET

What's inside the SGA

Database buffer cache holds copies of data blocks read from disk, so repeated reads of the same block don't hit storage again. Shared pool holds parsed SQL and PL/SQL (the library cache — so identical statements can skip re-parsing) and cached data dictionary metadata. Redo log buffer holds redo entries briefly before they're flushed to the online redo log files. Larger instances may also configure a large pool and Java pool for specific workloads.

What's inside the PGA

Each session's PGA holds the memory it needs to actually execute its own work: sort areas for ORDER BY/GROUP BY operations that don't fit entirely in the small default work area, hash areas for hash joins, and session-specific cursor and variable state. Because PGA is per-process, a single session doing a large sort can consume a meaningful chunk of PGA without affecting any other session's memory.

Frequently asked questions

What happens if the SGA is too small?

A small buffer cache means more physical reads from disk instead of cache hits, and a small shared pool means more hard parsing (re-compiling SQL that should have been reused from the library cache) — both show up as slower queries and higher I/O/CPU than a well-sized instance would need.

What happens if the PGA is too small for a session's sort?

Oracle spills the sort or hash operation to temporary tablespace on disk instead of keeping it entirely in memory — usually much slower than an in-memory operation. Large ORDER BY, GROUP BY, or hash-join operations on undersized PGA are a common source of unexpectedly slow queries.

Can I manually size the SGA and PGA separately?

Yes, via SGA_TARGET/SGA_MAX_SIZE and PGA_AGGREGATE_TARGET, or you can let Oracle manage total memory automatically with MEMORY_TARGET/MEMORY_MAX_TARGET, which balances SGA and PGA sizing for you within an overall memory budget.

Is this the same on every Oracle edition?

The core SGA/PGA architecture is the same across editions; some advanced auto-tuning and monitoring features (and certain SGA components) can vary by edition and version — confirm specifics against your current Oracle version's documentation.