05.11.2015 Views

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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

128<br />

CHAPTER 4 ■ MEMORY STRUCTURES<br />

Table 4-1. Continued<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 />

201 1.3 218 728 728<br />

226 1.3 211 728 728<br />

251 1.3 237 728 728<br />

276 1.3 251 728 728<br />

301 1.3 281 728 728<br />

326 1.3 302 728 728<br />

351 1.3 324 728 728<br />

376 1.3 350 728 728<br />

402 1.3 367 728 728<br />

426 1.3 392 728 728<br />

452 1.3 417 728 728<br />

476 1.3 439 728 728<br />

501 1.3 467 728 728<br />

■Note You might wonder why only 2MB of RAM is reported in use by the system with one active user. It<br />

has to do with the way I measured. The simulation would snapshot the single session’s of interest’s statistics.<br />

Next, I would run the big query in the single session of interest <strong>and</strong> then snapshot that session’s<br />

statistics again. Finally, I would measure how much PGA was used by the system. By the time I measured,<br />

the single session of interest would have already completed <strong>and</strong> given back some of the PGA it was using to<br />

sort. So, the number for PGA used by the system is an accurate measurement of the system’s PGA memory<br />

at the time it was measured.<br />

As you can see, when I had few active sessions, my sorts were performed entirely in memory.<br />

For an active session count of 1 to somewhere less than 50, I was allowed to sort entirely<br />

in memory. However, by the time I got 50 users logged in, actively sorting, the database started<br />

reining in the amount of memory I was allowed to use at a time. It took a couple of minutes<br />

before the amount of PGA being used fell back within acceptable limits (the 256MB request),<br />

but it eventually did. The amount of PGA memory allocated to the session dropped from<br />

7.5MB to 4MB to 3.2MB, <strong>and</strong> eventually down to the area of 1.7 to 1.3MB (remember, parts of<br />

that PGA are not for sorting, but are for other operations—just the act of logging in created a<br />

.5MB PGA). The total PGA in use by the system remained within tolerable limits until somewhere<br />

around 300 to 351 users. There I started to exceed on a regular basis the PGA_AGGREGATE_<br />

TARGET <strong>and</strong> continued to do so until the end of the test. I gave the database instance in this<br />

case an impossible task—the very act of having 350 users, most executing a PL/SQL, plus the

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

Saved successfully!

Ooh no, something went wrong!