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

rekharaghuram
from rekharaghuram More from this publisher
05.11.2015 Views

CHAPTER 4 ■ MEMORY STRUCTURES 137 The SGA is broken up into various pools: • 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 in both Oracle 10g and 9i Release 2. • 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 datasharing tool within the database. This pool is new in Oracle 10g and is resizable online. In the event 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 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

138 CHAPTER 4 ■ MEMORY STRUCTURES In Oracle9i, the various SGA components must be manually sized by the DBA but, starting in Oracle 10g, 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. When using the automatic memory management with Oracle 10g, it is a matter of simply 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. Regardless of whether you are using automatic or manual memory management, you will find that memory is allocated to the various pools in units called granules. A single granule is an area of memory either 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: sys@ORA10G> show parameter sga_target NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ sga_target big integer 576M sys@ORA10G> 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 OSM Buffer Cache 4194304 13 rows selected. 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

138<br />

CHAPTER 4 ■ MEMORY STRUCTURES<br />

In <strong>Oracle</strong>9i, the various SGA components must be manually sized by the DBA but, starting<br />

in <strong>Oracle</strong> 10g, there is a new option to consider: automatic SGA memory management,<br />

whereby the database instance will allocate <strong>and</strong> reallocate the various SGA components at<br />

runtime, in response to workload conditions. When using the automatic memory management<br />

with <strong>Oracle</strong> 10g, it is a matter of simply setting the SGA_TARGET parameter to the desired<br />

SGA size, leaving out the other SGA-related parameters altogether. The database instance will<br />

take it from there, allocating memory to the various pools as needed <strong>and</strong> even taking memory<br />

away from one pool to give to another over time.<br />

Regardless of whether you are using automatic or manual memory management, you will<br />

find that memory is allocated to the various pools in units called granules. A single granule is<br />

an area of memory either 4MB, 8MB, or 16MB in size. The granule is the smallest unit of allocation,<br />

so if you ask for a Java pool of 5MB <strong>and</strong> your granule size is 4MB, <strong>Oracle</strong> will actually<br />

allocate 8MB to the Java pool (8 being the smallest number greater than or equal to 5 that is a<br />

multiple of the granule size of 4). The size of a granule is determined by the size of your SGA<br />

(this sounds recursive to a degree, as the size of the SGA is dependent on the granule size). You<br />

can view the granule sizes used for each pool by querying V$SGA_DYNAMIC_COMPONENTS. In fact,<br />

we can use this view to see how the total SGA size might affect the size of the granules:<br />

sys@ORA10G> show parameter sga_target<br />

NAME TYPE VALUE<br />

------------------------------------ ----------- ------------------------------<br />

sga_target<br />

big integer 576M<br />

sys@ORA10G> select component, granule_size from v$sga_dynamic_components;<br />

COMPONENT<br />

GRANULE_SIZE<br />

------------------------- ------------<br />

shared pool 4194304<br />

large pool 4194304<br />

java pool 4194304<br />

streams pool 4194304<br />

DEFAULT buffer cache 4194304<br />

KEEP buffer cache 4194304<br />

RECYCLE buffer cache 4194304<br />

DEFAULT 2K buffer cache 4194304<br />

DEFAULT 4K buffer cache 4194304<br />

DEFAULT 8K buffer cache 4194304<br />

DEFAULT 16K buffer cache 4194304<br />

DEFAULT 32K buffer cache 4194304<br />

OSM Buffer Cache 4194304<br />

13 rows selected.<br />

In this example, I used automatic SGA memory management <strong>and</strong> controlled the size of<br />

the SGA via the single parameter SGA_TARGET. When my SGA size is under about 1GB, the granule<br />

is 4MB. When the SGA size is increased to some threshold over 1GB (it will vary slightly<br />

from operating system to operating system <strong>and</strong> even from release to release), I see an

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

Saved successfully!

Ooh no, something went wrong!