05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 4 ■ MEMORY STRUCTURES 135<br />

PGA <strong>and</strong> UGA Wrap-Up<br />

So far, we have looked at two memory structures: the PGA <strong>and</strong> the UGA. You should underst<strong>and</strong><br />

now that the PGA is private to a process. It is the set of variables that an <strong>Oracle</strong> dedicated<br />

or shared server needs to have independent of a session. The PGA is a “heap” of memory in<br />

which other structures may be allocated. The UGA is also a heap of memory in which various<br />

session-specific structures may be defined. The UGA is allocated from the PGA when you use<br />

a dedicated server to connect to <strong>Oracle</strong> <strong>and</strong> from the SGA under a shared server connection.<br />

This implies that when using a shared server, you must size your SGA’s Large pool to have<br />

enough space in it to cater for every possible user that will ever connect to your database concurrently.<br />

So, the SGA of a database supporting shared server connections is generally much<br />

larger than the SGA for a similarly configured, dedicated server mode–only database. We’ll<br />

cover the SGA in more detail next.<br />

The System Global Area<br />

Every <strong>Oracle</strong> instance has one big memory structure referred to as the System Global Area<br />

(SGA). This is a large, shared memory structure that every <strong>Oracle</strong> process will access at one<br />

point or another. It will vary in size from a few of megabytes on small test systems, to hundreds<br />

of megabytes on medium to large systems, up to many gigabytes in size for really big<br />

systems.<br />

On a UNIX operating system, the SGA is a physical entity that you can “see” from the OS<br />

comm<strong>and</strong> line. It is physically implemented as a shared memory segment—a st<strong>and</strong>-alone<br />

piece of memory to which processes may attach. It is possible to have an SGA on a system<br />

without having any <strong>Oracle</strong> processes; the memory st<strong>and</strong>s alone. It should be noted, however,<br />

that if you have an SGA without any <strong>Oracle</strong> processes, this is an indication that the database<br />

crashed in some fashion. It is an unusual situation, but it can happen. This is what an SGA<br />

“looks like” on Red Hat Linux:<br />

[tkyte@localhost tkyte]$ ipcs -m | grep ora<br />

0x99875060 2031619 ora10g 660 538968064 15<br />

0x0d998a20 1966088 ora9ir2 660 117440512 45<br />

0x6b390abc 1998857 ora9ir1 660 130560000 50<br />

Three SGAs are represented here: one owned by the OS user ora10g, another by the OS<br />

user ora9ir2, <strong>and</strong> the third by the OS user ora9ir1. They are about 512MB, 112MB, <strong>and</strong><br />

124MB, respectively.<br />

On Windows, you really cannot see the SGA as a distinct entity the way you can in<br />

UNIX/Linux. Because on the Windows platform, <strong>Oracle</strong> executes as a single process with a<br />

single address space, the SGA is allocated as private memory to the oracle.exe process. If you<br />

use the Windows Task Manager or some other performance tool, you can see how much memory<br />

oracle.exe has allocated, but you cannot see what is the SGA versus any other piece of<br />

allocated memory.<br />

Within <strong>Oracle</strong> itself, you can see the SGA regardless of platform, using another magic V$<br />

view called V$SGASTAT. It might look as follows (note that this code does not come from the<br />

preceding system; it’s from a system with all features configured to enable viewing of all pools<br />

available):

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!