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.

CHAPTER 4 ■ MEMORY STRUCTURES 125<br />

We can make some observations based on some information from MetaLink note<br />

147806.1:<br />

• The PGA_AGGREGATE_TARGET is a goal of an upper limit. It is not a value that is pre-allocated<br />

when the database is started up. You can observe this by setting the PGA_AGGREGATE_<br />

TARGET to a value much higher than the amount of physical memory you have available<br />

on your server. You will not see any large allocation of memory as a result.<br />

• A serial (nonparallel query) session will use a small percentage of the PGA_AGGREGATE_<br />

TARGET, about 5 percent or less. So, if you have set the PGA_AGGREGATE_TARGET to 100MB,<br />

you would expect to use no more than about 5MB per work area (e.g., the sort or hash<br />

work area). You may well have multiple work areas in your session for multiple queries,<br />

or more than one sort/hash operation in a single query, but each work area will be<br />

about 5 percent or less of the PGA_AGGREGATE_TARGET.<br />

• As the workload on you server goes up (more concurrent queries, concurrent users), the<br />

amount of PGA memory allocated to your work areas will go down. The database will<br />

try to keep the sum of all PGA allocations under the threshold set by PGA_AGGREGATE_<br />

TARGET. It would be analogous to having a DBA sit at a console all day, setting the<br />

SORT_AREA_SIZE <strong>and</strong> HASH_AREA_SIZE parameters based on the amount of work being<br />

performed in the database. We will directly observe this behavior shortly in a test.<br />

• A parallel query may use up to 30 percent of the PGA_AGGREGATE_TARGET, with each parallel<br />

process getting its slice of that 30 percent. That is, each parallel process would be<br />

able to use about 0.3 * PGA_AGGREGATE_TARGET / (number of parallel processes).<br />

OK, so how can we observe the different work area sizes being allocated to our session? By<br />

applying the same technique we used earlier in the manual memory management section, to<br />

observe the memory used by our session <strong>and</strong> the amount of I/O to temp we performed. The<br />

following test was performed on a Red Hat Advanced Server 3.0 Linux machine using <strong>Oracle</strong><br />

10.1.0.3 <strong>and</strong> dedicated server connections. This was a two-CPU Dell PowerEdge with hyperthreading<br />

enabled, so it was as if there were four CPUs available. Using reset_stat.sql <strong>and</strong> a<br />

slightly modified version of watch_stat.sql from earlier, I captured the session statistics for a<br />

session as well as the total statistics for the instance. The slightly modified watch_stat.sql<br />

script captured this information via the MERGE statement:<br />

merge into sess_stats<br />

using<br />

(<br />

select a.name, b.value<br />

from v$statname a, v$sesstat b<br />

where a.statistic# = b.statistic#<br />

<strong>and</strong> b.sid = &1<br />

<strong>and</strong> (a.name like '%ga %'<br />

or a.name like '%direct temp%')<br />

union all<br />

select 'total: ' || a.name, sum(b.value)<br />

from v$statname a, v$sesstat b, v$session c<br />

where a.statistic# = b.statistic#<br />

<strong>and</strong> (a.name like '%ga %'

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

Saved successfully!

Ooh no, something went wrong!