Memory Structures - Expert Oracle Database Architecture - page 127

■ Some operating system configurations are incompatible with automatic memory management (for example,
Linux hugepages). See the Oracle Database administrator's reference for Linux and uNIX-Based Operating Systems
manual for details.

Note

We'll attack all of the methods by first discussing PGA and UGA memory management, first manual and then
automatic. We'll then move onto the SGA, again looking at manual and then automatic memory management
methods. We'll close with a look at how to manage memory using just a single parameter to control both the SGA and
PGA regions.

The Process Global Area and User Global Area
The PGA is a process-specific piece of memory. In other words, it is memory specific to a single operating system
process or thread. This memory is not accessible by any other process or thread in the system. It is typically allocated
via either of the C runtime calls malloc() or memmap() , and it may grow (or even shrink) at runtime. The PGA is never
allocated in Oracle's SGA; it is always allocated locally by the process or thread—the P in PGA stands for process or
program ; it is not shared.
The UGA is, in effect, your session's state. It is memory that your session must always be able to get to. The
location of the UGA is dependent on how you connect to Oracle. If you connect via a shared server, the UGA must be
stored in a memory structure that every shared server process has access to—and that's the SGA. In this way, your
session can use any one of the shared servers, since any of them can read and write your session's data. On the other
hand, if you are using a dedicated server connection, there's no need for universal access to your session state, and the
UGA becomes virtually synonymous with the PGA; it will, in fact, be contained in the PGA of your dedicated server.
When you look at the system statistics, you'll find the UGA reported in the PGA in dedicated server mode (the PGA
will be greater than or equal to the UGA memory used; the PGA memory size will include the UGA size as well).
So, the PGA contains process memory and may include the UGA. The other areas of PGA memory are generally
used for in-memory sorting, bitmap merging, and hashing. It would be safe to say that, besides the UGA memory,
these are the largest contributors by far to the PGA.
Starting with Oracle9 i Release 1, there are two ways to manage this other non-UGA memory in the PGA:

• Manual PGA memory management , where you tell Oracle how much memory it can use to
sort and hash any time it needs to sort or hash in a specific process.

• Automatic PGA memory management , where you tell Oracle how much memory it should
attempt to use system wide.

Starting with Oracle 11 g Release 1, automatic PGA memory management can be implemented using one of the
two following techniques:

PGA_AGGREGATE_TARGET initialization parameter and telling Oracle how much
PGA memory to attempt to use instance wide.

• By setting the

MEMORY_TARGET initialization parameter and telling Oracle how much total
memory the database instance should use for both the SGA and the PGA; the PGA size will be
figured out by the instance itself from this parameter.

• By setting the

The manner in which memory is allocated and used differs greatly in each case, so we'll discuss each in turn.