Every Oracle instance has one big memory structure referred to as the System Global Area (SGA). This is a large, shared memory structure that every Oracle process will access at one point or another. It varies in size from a few megabytes on small test systems, to hundreds of megabytes on medium-to-large systems, up to many gigabytes for really big systems.
On UNIX, the SGA is a physical entity you can "see" from the OS command line. It is physically implemented as a shared memory segment—a standalone piece of memory to which processes may attach. It is possible to have an SGA on a system without having any Oracle processes; the memory stands alone. It should be noted, however, that if you have an SGA without any Oracle processes, this is an indication that the database crashed in some fashion. It is an unusual situation, but it can happen.
This is what an SGA "looks like" on Red Hat Linux:
$ ipcs -m | grep ora
0xbba344b8 1540099 ora11gr2 660 270532608 26 0x39381320 1179655 ora10gr2 660 538968064 16 0x6b08d4e8 491529 ora11gr1 640 270532608 21 0x0d998a20 557067 ora9ir2 660 253755392 8 0xe5b0179c 622604 ora10gr1 660 610271232 15
CHAPTER 4 ■ MEMORY STRUCTURES
■
Note I have five instances on my test/demo machine. This is highly unusual. I needed five instances to test the various concepts presented in this book on different releases. The only reasonable, correct number of instances on a production machine is one. In real life, never have more than one instance on a given production server. If you need more than one instance on a physical server, you should use virtualization to split that one server into many virtual servers—each with its own instance of Oracle.Five SGAs are represented here and the report shows the OS account that owns the SGA (ora11gr2 for the first one, for example) and the size of the SGA—258MB for the first example. On Windows, you really can’t see the SGA as a distinct entity the way you can in UNIX/Linux. Because on the Windows platform Oracle executes as a single process with a single address space, the SGA is allocated as private memory to the oracle.exe process. If you use the Windows Task Manager or some other performance tool, you can see how much memory oracle.exe has allocated, but you can’t see what is the SGA versus any other piece of allocated memory.
■
Note Unless you have my parameter settings and you are running my exact same version of Oracle on my exact same OS, you will almost certainly see different numbers than I do. The SGA sizing is very version/OS/parameter-dependent.Within Oracle itself, you can see the SGA regardless of platform, using another magic V$ view called V$SGASTAT. It might look as follows:
ops$tkyte%ORA11GR2> compute sum of bytes on pool ops$tkyte%ORA11GR2> break on pool skip 1
ops$tkyte%ORA11GR2>
ops$tkyte%ORA11GR2> select pool, name, bytes 2 from v$sgastat
3 order by pool, name;
POOL NAME BYTES --- --- ---
java pool free memory 4194304
************ --- sum 4194304
large pool PX msg pool 3894304
free memory 300000
************ --- sum 4194304
shared pool 1:kngisga 16052
ADR_CONTROL 1056
ADR_INVALIDATION 464
AQ Propagation Scheduling 16000
ASH buffers 5368712 ..
CHAPTER 4 ■ MEMORY STRUCTURES
144
xsoqsehift 2404
xssinfo 5560
************ --- sum 159388244
buffer_cache 92274688
fixed_sga 1335924
log_buffer 6438912
************ --- sum 100049524
863 rows selected.
The SGA is broken up into various pools. Here are the major ones you’ll see:
• Java pool: The Java pool is a fixed amount of memory allocated for the JVM running in the database. In Oracle10g, the Java pool may be resized online while the database is up and running.
• Large pool: The large pool is used by shared server connections for session memory, by parallel execution features for message buffers, and by RMAN backup for disk I/O buffers. This pool is resizable online.
• Shared pool: The shared pool contains shared cursors, stored procedures, state objects, dictionary caches, and many dozens of other bits of data. This pool is resizable online in both Oracle 10g and 9i.
• Streams pool: This is a pool of memory used exclusively by Oracle Streams, a data-sharing tool within the database. This pool is new in Oracle 10g and is resizable online. If the Streams pool is not configured and you use the Streams
functionality, Oracle will use up to 10 percent of the shared pool for streams memory.
• The “Null” pool: This one doesn’t really have a name. It is the memory dedicated to block buffers (cached database blocks), the redo log buffer, and a
“fixed SGA” area.
A typical SGA might look as shown in Figure 4-1.
Figure 4-1. Typical SGA
CHAPTER 4 ■ MEMORY STRUCTURES
The parameters that have the greatest effect on the overall size of the SGA are as follows:
• JAVA_POOL_SIZE: Controls the size of the Java pool.
• SHARED_POOL_SIZE: Controls the size of the shared pool (to some degree).
• LARGE_POOL_SIZE: Controls the size of the large pool.
• DB_*_CACHE_SIZE: Eight of these cache_size parameters control the sizes of the various buffer caches available.
• LOG_BUFFER: Controls the size of the redo buffer (to some degree).
• SGA_TARGET: Used with automatic SGA memory management in Oracle 10g and above.
• SGA_MAX_SIZE: Used to control the maximum size to which the SGA can be resized while the database is up and running.
• MEMORY_TARGET: Used with automatic memory management (both PGA and SGA automatic memory management).
• MEMORY_MAX_SIZE: Used to control the maximum amount of memory Oracle should strive to use over both the PGA and SGA sizes under automatic memory
management. This is really just a target; the PGA may exceed the optimum size if the number of users increases beyond some level or a session(s) allocates large untunable bits of memory as demonstrated above.
In Oracle9i, the various SGA components must be manually sized by the DBA. Starting in Oracle 10g and above, however, there is a new option to consider: automatic SGA memory management, whereby the database instance will allocate and reallocate the various SGA components at runtime in response to workload conditions. Moreover, starting in Oracle 11g, there’s another new option: automatic memory management, whereby the database instance will not only perform automatic SGA memory
management and automatic PGA memory management, it will also decide the optimum size of the SGA and PGA for you—reallocating these allotments automatically when deemed reasonable. Using the automatic SGA memory management with Oracle 10g and above is simply a matter of setting the SGA_TARGET parameter to the desired SGA size, leaving out the other SGA-related parameters altogether.
The database instance will take it from there, allocating memory to the various pools as needed and even taking memory away from one pool to give to another over time. When using automatic memory management with Oracle 11g and above, you simply set the MEMORY_TARGET. The database instance will then decide the optimal SGA size and PGA size—and those components will be set up appropriately and do their own automatic memory management within their respective boundaries. Further, the database can and will resize the SGA and PGA allocations as the workload changes over time.
Regardless of whether you are using automatic or manual memory management, you’ll find that memory is allocated to the various pools in the SGA in units called granules. A single granule is an area of memory of 4MB, 8MB, or 16MB in size. The granule is the smallest unit of allocation, so if you ask for a Java pool of 5MB and your granule size is 4MB, Oracle will actually allocate 8MB to the Java pool (8 being the smallest number greater than or equal to 5 that is a multiple of the granule size of 4). The size of a granule is determined by the size of your SGA (this sounds recursive to a degree, as the size of the SGA is dependent on the granule size). You can view the granule sizes used for each pool by querying
V$SGA_DYNAMIC_COMPONENTS. In fact, we can use this view to see how the total SGA size might affect the size of the granules:
CHAPTER 4 ■ MEMORY STRUCTURES
146
ops$tkyte%ORA11GR2> show parameter sga_target
NAME TYPE VALUE
--- --- --- sga_target big integer 256M
ops$tkyte%ORA11GR2> select component, granule_size from v$sga_dynamic_components;
COMPONENT GRANULE_SIZE --- ---
shared pool 4194304
large pool 4194304
java pool 4194304
streams pool 4194304
DEFAULT buffer cache 4194304
KEEP buffer cache 4194304
RECYCLE buffer cache 4194304
DEFAULT 2K buffer cache 4194304
DEFAULT 4K buffer cache 4194304
DEFAULT 8K buffer cache 4194304
DEFAULT 16K buffer cache 4194304
DEFAULT 32K buffer cache 4194304
Shared IO Pool 4194304
ASM Buffer Cache 4194304 14 rows selected.
■
Note This is the SGA information for the Oracle instance started with the initialization parameter file in the previous example. We specified the SGA and PGA sizes ourselves in that parameter file. Therefore we are using automatic SGA memory management and automatic PGA memory management, but not the new in Oracle 11g“memory management” setting, which would have sized and resized our PGA/SGA settings for us.
In this example, I used automatic SGA memory management and controlled the size of the SGA via the single parameter SGA_TARGET. When my SGA size is under about 1GB, the granule is 4MB. When the SGA size is increased to some threshold over 1GB (it will vary slightly from operating system to operating system and even from release to release), I see an increased granule size. First we convert to using a stored parameter file to make altering the SGA_TARGET easier:
sys%ORA11GR2> create spfile from pfile;
File created.
sys%ORA11GR2> startup force;
ORACLE instance started.
Total System Global Area 267825152 bytes Fixed Size 1335924 bytes Variable Size 130026892 bytes Database Buffers 130023424 bytes
CHAPTER 4 ■ MEMORY STRUCTURES
Redo Buffers 6438912 bytes Database mounted.
Database opened.
Then we modify the SGA_TARGET:
sys%ORA11GR2> alter system set sga_target = 1512m scope=spfile;
System altered.
sys%ORA11GR2> startup force ORACLE instance started.
Total System Global Area 1590267904 bytes Fixed Size 1336792 bytes Variable Size 218106408 bytes Database Buffers 1358954496 bytes Redo Buffers 11870208 bytes Database mounted.
Database opened.
sys%ORA11GR2> show parameter sga_target
NAME TYPE VALUE
--- --- --- sga_target big integer 1520M
Now when we look at the SGA components:
sys%ORA11GR2> select component, granule_size from v$sga_dynamic_components;
COMPONENT GRANULE_SIZE --- ---
shared pool 16777216
large pool 16777216
java pool 16777216
streams pool 16777216
DEFAULT buffer cache 16777216
KEEP buffer cache 16777216
RECYCLE buffer cache 16777216
DEFAULT 2K buffer cache 16777216
DEFAULT 4K buffer cache 16777216
DEFAULT 8K buffer cache 16777216
DEFAULT 16K buffer cache 16777216
DEFAULT 32K buffer cache 16777216
Shared IO Pool 16777216
ASM Buffer Cache 16777216 14 rows selected.
As you can see, at 1.5GB of SGA, my pools will be allocated using 16MB granules, so any given pool size will be some multiple of 16MB.
With this in mind, let's look at each of the major SGA components in turn.
CHAPTER 4 ■ MEMORY STRUCTURES
148