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.

122<br />

CHAPTER 4 ■ MEMORY STRUCTURES<br />

Measuring from the other session, we can see the memory used so far:<br />

ops$tkyte@ORA10G> @watch_stat<br />

6 rows merged.<br />

NAME VALUE DIFF<br />

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

physical reads direct temporary tablespace 0 0<br />

physical writes direct temporary tablespace 0 0<br />

session pga memory 498252 0<br />

session pga memory max 7445068 6946816<br />

session uga memory 152176 0<br />

session uga memory max 7091360 6939184<br />

6 rows selected.<br />

We can observe that even though we allowed for up to 1GB of memory to the SORT_AREA_<br />

SIZE, we really only used about 6.6MB. This shows that the SORT_AREA_SIZE setting is an upper<br />

bound, not the default <strong>and</strong> only allocation size. Here notice also that we did only one sort<br />

again, but this time it was entirely in memory; there was no temporary space on disk used, as<br />

evidenced by the lack of physical I/O.<br />

If you run this same test on various versions of <strong>Oracle</strong>, or perhaps even on different operating<br />

systems, you might see different behavior, <strong>and</strong> I would expect that your numbers in all<br />

cases would be a little different from mine. But the general behavior should be the same. In<br />

other words, as you increase the permitted sort area size <strong>and</strong> perform large sorts, the amount<br />

of memory used by your session will increase. You might notice the PGA memory going up<br />

<strong>and</strong> down, or it might remain constant over time, as just shown. For example, if you were to<br />

execute the previous test in <strong>Oracle</strong>8i, I am sure that you would notice that PGA memory does<br />

not shrink back in size (i.e., the SESSION PGA MEMORY equals the SESSION PGA MEMORY MAX in all<br />

cases). This is to be expected, as the PGA is managed as a heap in 8i releases <strong>and</strong> is created via<br />

malloc()-ed memory. In 9i <strong>and</strong> 10g, new methods attach <strong>and</strong> release work areas as needed<br />

using operating system–specific memory allocation calls.<br />

The important things to remember about using the *_AREA_SIZE parameters are as follows:<br />

• These parameters control the maximum amount of memory used by a SORT, HASH,<br />

<strong>and</strong>/or BITMAP MERGE operation.<br />

• A single query may have many operations taking place that use this memory, <strong>and</strong> multiple<br />

sort/hash areas could be created. Remember that you may have many cursors<br />

opened simultaneously, each with their own SORT_AREA_RETAINED needs. So, if you set<br />

the sort area size to 10MB, you could use 10, 100, 1,000 or more megabytes of RAM in<br />

your session. These settings are not session limits; rather, they are limits on a single<br />

operation, <strong>and</strong> your session could have many sorts in a single query or many queries<br />

open that require a sort.

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

Saved successfully!

Ooh no, something went wrong!