05.11.2015 Views

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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

120<br />

CHAPTER 4 ■ MEMORY STRUCTURES<br />

some other amount? This is a trick question, <strong>and</strong> one that you cannot answer unless you know<br />

whether the monitored session with SID 151 was connected to the database via a dedicated<br />

server or a shared server—<strong>and</strong> even then it might be hard to figure out. In dedicated server<br />

mode, the UGA is totally contained within the PGA, in which case we would be consuming<br />

487KB of memory in our process or thread. In shared server, the UGA is allocated from the<br />

SGA, <strong>and</strong> the PGA is in the shared server. So, in shared server mode, by the time we get the last<br />

row from the preceding query, the shared server process may be in use by someone else. That<br />

PGA isn’t “ours” anymore, so technically we are using 149KB of memory (except when we are<br />

actually running the query, at which point we are using 487KB of memory between the combined<br />

PGA <strong>and</strong> UGA). So, let’s now run the first big query in session 151, which is using<br />

manual PGA memory management in dedicated server mode. Note that we are using the<br />

same script from earlier, so the SQL text matches exactly, thus avoiding the hard parse:<br />

■Note Since we haven’t set a SORT_AREA_RETAINED_SIZE, its reported value will be zero, but its used<br />

value will match SORT_AREA_SIZE.<br />

ops$tkyte@ORA10G> alter session set sort_area_size = 65536;<br />

Session altered.<br />

ops$tkyte@ORA10G> set termout off;<br />

query was executed here<br />

ops$tkyte@ORA10G> set termout on;<br />

Now if we run our script again in the second session, we’ll see something like this.<br />

Notice this time that the session xxx memory <strong>and</strong> session xxx memory max values do not<br />

match. The session xxx memory max value represents how much memory we are using right<br />

now. The session xxx memory max value represents the peak value we used at some time<br />

during our session while processing the query.<br />

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

6 rows merged.<br />

NAME VALUE DIFF<br />

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

physical reads direct temporary tablespace 2906 2906<br />

physical writes direct temporary tablespace 2906 2906<br />

session pga memory 498252 0<br />

session pga memory max 563788 65536<br />

session uga memory 152176 0<br />

session uga memory max 217640 65464<br />

6 rows selected.<br />

As you can see, our memory usage went up—we’ve done some sorting of data. Our UGA<br />

temporarily increased from 149KB to 213KB (64KB) during the processing of our query, <strong>and</strong>

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

Saved successfully!

Ooh no, something went wrong!