Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 4 ■ MEMORY STRUCTURES 129 sort they were all requesting, just did not fit into the 256MB of RAM I had targeted. It simply could not be done. Each session, therefore used as little memory as possible, but had to allocate as much memory as it needed. By the time I finished this test, 500 active sessions were using a total of 467MB of PGA memory—as little as they could. You should, however, consider what Table 4-1 would look like under a manual memory management situation. Suppose the SORT_AREA_SIZE had been set to 5MB. The math is very straightforward: each session would be able to perform the sort in RAM (or virtual memory as the machine ran out of real RAM), and thus would consume 6 to 7MB of RAM per session (the amount used without sorting to disk in the previous single-user case). I ran the preceding test again with SORT_AREA_SIZE set to 5MB, and as I went from 1 user to adding 25 at a time, the numbers remained consistent, as shown in Table 4-2. Table 4-2. PGA Memory Allocation Behavior with Increasing Numbers of Active Sessions, with SORT_AREA_SIZE Set to 5MB (Manual Memory Management) Active PGA Used by PGA in Use Writes to Temp by Reads from Temp Sessions Single Session by System Single Session by Single Session 1 6.4 5 728 728 26 6.4 137 728 728 51 6.4 283 728 728 76 6.4 391 728 728 102 6.4 574 728 728 126 6.4 674 728 728 151 6.4 758 728 728 176 6.4 987 728 728 202 6.4 995 728 728 226 6.4 1227 728 728 251 6.4 1383 728 728 277 6.4 1475 728 728 302 6.4 1548 728 728 Had I been able to complete the test (I have 2GB of real memory on this server and my SGA was 600MB; by the time I got to 325 users, the machine was paging and swapping to the point where it was impossible to continue), at 500 users I would have allocated around 2,750MB of RAM! So, the DBA would probably not set the SORT_AREA_SIZE to 5MB on this system, but rather to about 0.5MB, in an attempt to keep the maximum PGA usage at a bearable level at peak. Now at 500 users I would have had about 500MB of PGA allocated, perhaps similar to what we observed with automatic memory management—but at times when there were fewer users, we would have still written to temp rather than performing the sort in memory. In fact, when running the preceding test with a SORT_AREA_SIZE of .5MB, we would observe the data in Table 4-3.
130 CHAPTER 4 ■ MEMORY STRUCTURES Table 4-3. PGA Memory Allocation Behavior with Increasing Numbers of Active Sessions, with SORT_AREA_SIZE Set to 0.5MB (Manual Memory Management) Active PGA Used by PGA in Use Writes to Temp by Reads from Temp Sessions Single Session by System Single Session by Single Session 1 1.2 1 728 728 26 1.2 29 728 728 51 1.2 57 728 728 76 1.2 84 728 728 101 1.2 112 728 728 126 1.2 140 728 728 151 1.2 167 728 728 176 1.2 194 728 728 201 1.2 222 728 728 226 1.2 250 728 728 This represents a very predicable—but suboptimal—use of memory as the workload increases or decreases over time. Automatic PGA memory management was designed exactly to allow the small community of users to use as much RAM as possible when it was available and back off on this allocation over time as the load increased, and increase the amount of RAM allocated for individual operations over time as the load decreased. Using PGA_AGGREGATE_TARGET to Control Memory Allocation Earlier, I wrote that “in theory” we can use the PGA_AGGREGATE_TARGET to control the overall amount of PGA memory used by the instance. We saw in the last example that this is not a hard limit, however. The instance will attempt to stay within the bounds of the PGA_AGGREGATE_ TARGET, but if it cannot, it will not stop processing; rather, it will just be forced to exceed that threshold. Another reason this limit is “in theory” is because the work areas, while a large contributor to PGA memory, are not the only contributor to PGA memory. Many things contribute to your PGA memory allocation, and only the work areas are under the control of the database instance. If you create and execute a PL/SQL block of code that fills in a large array with data in dedicated server mode where the UGA is in the PGA, Oracle cannot do anything but allow you to do it. Consider the following quick example. We’ll create a package that can hold some persistent (global) data in the server: ops$tkyte@ORA10G> create or replace package demo_pkg 2 as 3 type array is table of char(2000) index by binary_integer; 4 g_data array; 5 end; 6 / Package created.
- Page 124 and 125: CHAPTER 3 ■ FILES 79 • Resource
- Page 126 and 127: CHAPTER 3 ■ FILES 81 3 l_dummy nu
- Page 128 and 129: CHAPTER 3 ■ FILES 83 Trace Files
- Page 130 and 131: CHAPTER 3 ■ FILES 85 _qerixAlloca
- 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 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 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
CHAPTER 4 ■ MEMORY STRUCTURES 129<br />
sort they were all requesting, just did not fit into the 256MB of RAM I had targeted. It simply<br />
could not be done. Each session, therefore used as little memory as possible, but had to allocate<br />
as much memory as it needed. By the time I finished this test, 500 active sessions were<br />
using a total of 467MB of PGA memory—as little as they could.<br />
You should, however, consider what Table 4-1 would look like under a manual memory<br />
management situation. Suppose the SORT_AREA_SIZE had been set to 5MB. The math is very<br />
straightforward: each session would be able to perform the sort in RAM (or virtual memory as<br />
the machine ran out of real RAM), <strong>and</strong> thus would consume 6 to 7MB of RAM per session (the<br />
amount used without sorting to disk in the previous single-user case). I ran the preceding test<br />
again with SORT_AREA_SIZE set to 5MB, <strong>and</strong> as I went from 1 user to adding 25 at a time, the<br />
numbers remained consistent, as shown in Table 4-2.<br />
Table 4-2. PGA Memory Allocation Behavior with Increasing Numbers of Active Sessions, with<br />
SORT_AREA_SIZE Set to 5MB (Manual Memory Management)<br />
Active PGA Used by PGA in Use Writes to Temp by Reads from Temp<br />
Sessions Single Session by System Single Session by Single Session<br />
1 6.4 5 728 728<br />
26 6.4 137 728 728<br />
51 6.4 283 728 728<br />
76 6.4 391 728 728<br />
102 6.4 574 728 728<br />
126 6.4 674 728 728<br />
151 6.4 758 728 728<br />
176 6.4 987 728 728<br />
202 6.4 995 728 728<br />
226 6.4 1227 728 728<br />
251 6.4 1383 728 728<br />
277 6.4 1475 728 728<br />
302 6.4 1548 728 728<br />
Had I been able to complete the test (I have 2GB of real memory on this server <strong>and</strong> my<br />
SGA was 600MB; by the time I got to 325 users, the machine was paging <strong>and</strong> swapping to<br />
the point where it was impossible to continue), at 500 users I would have allocated around<br />
2,750MB of RAM! So, the DBA would probably not set the SORT_AREA_SIZE to 5MB on this system,<br />
but rather to about 0.5MB, in an attempt to keep the maximum PGA usage at a bearable<br />
level at peak. Now at 500 users I would have had about 500MB of PGA allocated, perhaps similar<br />
to what we observed with automatic memory management—but at times when there were<br />
fewer users, we would have still written to temp rather than performing the sort in memory.<br />
In fact, when running the preceding test with a SORT_AREA_SIZE of .5MB, we would observe the<br />
data in Table 4-3.
Change language