Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
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
- Page 132 and 133: CHAPTER 3 ■ FILES 87 6 ( 7 TYPE O
- Page 134 and 135: CHAPTER 3 ■ FILES 89 A Brief Revi
- Page 136 and 137: CHAPTER 3 ■ FILES 91 Redundant Ar
- Page 138 and 139: CHAPTER 3 ■ FILES 93 (data from m
- Page 140 and 141: CHAPTER 3 ■ FILES 95 dictionary t
- Page 142 and 143: CHAPTER 3 ■ FILES 97 ■Note df i
- Page 144 and 145: CHAPTER 3 ■ FILES 99 “accidenta
- Page 146 and 147: CHAPTER 3 ■ FILES 101 So, at the
- Page 148 and 149: CHAPTER 3 ■ FILES 103 Password Fi
- Page 150 and 151: CHAPTER 3 ■ FILES 105 USER is "SY
- Page 152 and 153: CHAPTER 3 ■ FILES 107 Flashback L
- Page 154 and 155: CHAPTER 3 ■ FILES 109 of the requ
- Page 156 and 157: CHAPTER 3 ■ FILES 111 IMPDP, howe
- Page 158 and 159: CHAPTER 3 ■ FILES 113 tkyte@ORA10
- Page 160 and 161: CHAPTER 4 ■ ■ ■ Memory Struct
- Page 162 and 163: CHAPTER 4 ■ MEMORY STRUCTURES 117
- Page 164 and 165: CHAPTER 4 ■ MEMORY STRUCTURES 119
- Page 166 and 167: CHAPTER 4 ■ MEMORY STRUCTURES 121
- Page 168 and 169: CHAPTER 4 ■ MEMORY STRUCTURES 123
- Page 170 and 171: CHAPTER 4 ■ MEMORY STRUCTURES 125
- Page 172 and 173: CHAPTER 4 ■ MEMORY STRUCTURES 127
- Page 174 and 175: CHAPTER 4 ■ MEMORY STRUCTURES 129
- Page 176 and 177: CHAPTER 4 ■ MEMORY STRUCTURES 131
- Page 178 and 179: CHAPTER 4 ■ MEMORY STRUCTURES 133
- Page 180 and 181: CHAPTER 4 ■ MEMORY STRUCTURES 135
- Page 184 and 185: CHAPTER 4 ■ MEMORY STRUCTURES 139
- Page 186 and 187: CHAPTER 4 ■ MEMORY STRUCTURES 141
- Page 188 and 189: CHAPTER 4 ■ MEMORY STRUCTURES 143
- Page 190 and 191: CHAPTER 4 ■ MEMORY STRUCTURES 145
- Page 192 and 193: CHAPTER 4 ■ MEMORY STRUCTURES 147
- Page 194 and 195: CHAPTER 4 ■ MEMORY STRUCTURES 149
- Page 196 and 197: CHAPTER 4 ■ MEMORY STRUCTURES 151
- Page 198 and 199: CHAPTER 4 ■ MEMORY STRUCTURES 153
- Page 200 and 201: CHAPTER 5 ■ ■ ■ Oracle Proces
- Page 202 and 203: CHAPTER 5 ■ ORACLE PROCESSES 157
- Page 204 and 205: CHAPTER 5 ■ ORACLE PROCESSES 159
- Page 206 and 207: CHAPTER 5 ■ ORACLE PROCESSES 161
- Page 208 and 209: CHAPTER 5 ■ ORACLE PROCESSES 163
- Page 210 and 211: CHAPTER 5 ■ ORACLE PROCESSES 165
- Page 212 and 213: CHAPTER 5 ■ ORACLE PROCESSES 167
- Page 214 and 215: CHAPTER 5 ■ ORACLE PROCESSES 169
- Page 216 and 217: CHAPTER 5 ■ ORACLE PROCESSES 171
- Page 218 and 219: CHAPTER 5 ■ ORACLE PROCESSES 173
- Page 220 and 221: CHAPTER 5 ■ ORACLE PROCESSES 175
- Page 222 and 223: CHAPTER 5 ■ ORACLE PROCESSES 177
- Page 224 and 225: CHAPTER 5 ■ ORACLE PROCESSES 179
- Page 226 and 227: CHAPTER 5 ■ ORACLE PROCESSES 181
- Page 228 and 229: CHAPTER 6 ■ ■ ■ Locking and L
- Page 230 and 231: CHAPTER 6 ■ LOCKING AND LATCHING
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