Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 4 ■ MEMORY STRUCTURES 139 sys@ORA10G> alter system set sga_target = 1512m scope=spfile; System altered. sys@ORA10G> startup force ORACLE instance started. Total System Global Area 1593835520 bytes Fixed Size 779316 bytes Variable Size 401611724 bytes Database Buffers 1191182336 bytes Redo Buffers 262144 bytes Database mounted. Database opened. sys@ORA10G> 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 OSM Buffer Cache 16777216 13 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. Fixed SGA The fixed SGA is a component of the SGA that varies in size from platform to platform and from release to release. It is “compiled” into the Oracle binary itself at installation time (hence the name “fixed”). The fixed SGA contains a set of variables that point to the other components of the SGA, and variables that contain the values of various parameters. The size of the fixed SGA is something with which we have no control over, and it is generally very small. Think of this area as a “bootstrap” section of the SGA—something Oracle uses internally to find the other bits and pieces of the SGA.
140 CHAPTER 4 ■ MEMORY STRUCTURES Redo Buffer The redo buffer is where data that needs to be written to the online redo logs will be cached temporarily, before it is written to disk. Since a memory-to-memory transfer is much faster then a memory-to-disk transfer, use of the redo log buffer can speed up database operation. The data will not reside in the redo buffer for very long. In fact, LGWR initiates a flush of this area in one of the following scenarios: • Every three seconds • Whenever someone commits • When LGWR is asked to switch log files • When the redo buffer gets one-third full or contains 1MB of cached redo log data For these reasons, it will be a very rare system that will benefit from a redo buffer of more than a couple of megabytes in size. A large system with lots of concurrent transactions could benefit somewhat from large redo log buffers because while LGWR (the process responsible for flushing the redo log buffer to disk) is writing a portion of the log buffer, other sessions could be filling it up. In general, a long-running transaction that generates a lot of redo log will benefit the most from a larger than normal log buffer, as it will be continuously filling up part of the redo log buffer while LGWR is busy writing out some of it. The larger and longer the transaction, the more benefit it could receive from a generous log buffer. The default size of the redo buffer, as controlled by the LOG_BUFFER parameter, is whatever is the greater of 512KB and (128 * number of CPUs)KB. The minimum size of this area is OS dependent. If you would like to find out what that is, just set your LOG_BUFFER to 1 byte and restart your database. For example, on my Red Hat Linux instance I see the following: sys@ORA10G> alter system set log_buffer=1 scope=spfile; System altered. sys@ORA10G> startup force ORACLE instance started. Total System Global Area 1593835520 bytes Fixed Size 779316 bytes Variable Size 401611724 bytes Database Buffers 1191182336 bytes Redo Buffers 262144 bytes Database mounted. Database opened. sys@ORA10G> show parameter log_buffer NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_buffer integer 262144 The smallest log buffer I can really have, regardless of my settings, is going to be 256KB on this system.
- 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 182 and 183: CHAPTER 4 ■ MEMORY STRUCTURES 137
- 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
- Page 232 and 233: CHAPTER 6 ■ LOCKING AND LATCHING
140<br />
CHAPTER 4 ■ MEMORY STRUCTURES<br />
Redo Buffer<br />
The redo buffer is where data that needs to be written to the online redo logs will be cached<br />
temporarily, before it is written to disk. Since a memory-to-memory transfer is much faster<br />
then a memory-to-disk transfer, use of the redo log buffer can speed up database operation.<br />
The data will not reside in the redo buffer for very long. In fact, LGWR initiates a flush of this<br />
area in one of the following scenarios:<br />
• Every three seconds<br />
• Whenever someone commits<br />
• When LGWR is asked to switch log files<br />
• When the redo buffer gets one-third full or contains 1MB of cached redo log data<br />
For these reasons, it will be a very rare system that will benefit from a redo buffer of more<br />
than a couple of megabytes in size. A large system with lots of concurrent transactions could<br />
benefit somewhat from large redo log buffers because while LGWR (the process responsible for<br />
flushing the redo log buffer to disk) is writing a portion of the log buffer, other sessions could<br />
be filling it up. In general, a long-running transaction that generates a lot of redo log will benefit<br />
the most from a larger than normal log buffer, as it will be continuously filling up part of the<br />
redo log buffer while LGWR is busy writing out some of it. The larger <strong>and</strong> longer the transaction,<br />
the more benefit it could receive from a generous log buffer.<br />
The default size of the redo buffer, as controlled by the LOG_BUFFER parameter, is whatever<br />
is the greater of 512KB <strong>and</strong> (128 * number of CPUs)KB. The minimum size of this area is OS<br />
dependent. If you would like to find out what that is, just set your LOG_BUFFER to 1 byte <strong>and</strong><br />
restart your database. For example, on my Red Hat Linux instance I see the following:<br />
sys@ORA10G> alter system set log_buffer=1 scope=spfile;<br />
System altered.<br />
sys@ORA10G> startup force<br />
ORACLE instance started.<br />
Total System Global Area 1593835520 bytes<br />
Fixed Size<br />
779316 bytes<br />
Variable Size<br />
401611724 bytes<br />
<strong>Database</strong> Buffers 1191182336 bytes<br />
Redo Buffers<br />
262144 bytes<br />
<strong>Database</strong> mounted.<br />
<strong>Database</strong> opened.<br />
sys@ORA10G> show parameter log_buffer<br />
NAME TYPE VALUE<br />
------------------------------------ ----------- ------------------------------<br />
log_buffer integer 262144<br />
The smallest log buffer I can really have, regardless of my settings, is going to be 256KB on<br />
this system.