Professional Documents
Culture Documents
Essentially, how a work area is sized determines the efficiency and speed of the query. For
the best results the work area for, say, a large query with a lot of sorting should be large
enough that all its input data and auxiliary memory structures created by its SQL operators
will fit inside that work area. Oracle terms this the optimal size of a work area.
So, what happens when the work area's size is exceeded? Response time increases because
the server process has to make an extra pass over the input data (termed the one-pass size
of the work area). Moreover, if the work area is exceedingly small, the server process has to
make multiple passes over the work area (termed the multi-pass size of the work area).
Tuning the work areas in the PGA so that the query runs within the optimal size of the work
area eliminates these additional passes over the input data, insuring the query runs faster
and uses PGA resources more efficiently.
80% of the total memory available for the database instance to allow enough memory for
other non-Oracle applications running on the server.
In my case, my server had 8GB available memory for the instance. For an OLTP-based
server, Oracle recommends allocating 20% to the PGA, so PGA_AGGREGATE_TARGET would
be set to approximately 1310MB ((8192 MB x 80%) x 20%). For a DSS-based server, Oracle
recommends a factor of at least 50%, or approximately 3276MB (8192MB x 80%) x 50%).
During my testing, I hedged my bet by quite a bit, knowing that my database server is
almost totally dedicated to OLTP, and initially allocated 400MB for
PGA_AGGREGATE_TARGET.
After applying the change to my database's INIT.ORA file and restarting the database, I
confirmed the results by querying V$PGASTAT. This is a new dynamic view available with
Oracle 9i and is useful for obtaining instance-level statistics about PGA memory usage and
how well automatic memory management is working:
SQL> SELECT NAME, VALUE FROM v$pgastat;
NAME
VALUE
---------------------------------------------aggregate PGA target parameter
419430400
aggregate PGA auto target
361433088
global memory bound
20971520
total PGA inuse
17833984
total PGA allocated
34810880
maximum PGA allocated
124318720
total freeable PGA memory
0
PGA memory freed back to OS
0
total PGA used for auto workareas 0
maximum PGA used for auto workareas
60204032
total PGA used for manual workareas
0
maximum PGA used for manual workareas 246784
over allocation count
0
total bytes processed
5866293248
extra bytes read/written
720095232
cache hit percentage
89.06
The statistics returned explain what's going on inside the PGA. Here is a breakout of the
more important ones, according to Oracle:
aggregate PGA target parameter shows the actual value set for
PGA_AGGREGATE_TARGET (in this case, 400MB). This parameter confirms if
automatic PGA memory management has been activated--if it hasn't been, then this
value will be zero.
The Oracle DBMS dynamically derives the value for aggregate PGA auto target from
the value set for PGA_AGGREGATE_TARGET and is continuously adjusted by Oracle.
It is the amount of memory that can be used for work areas running in automatic
mode. If this value is small, it generally indicates that other components of the
system--for example, PL/SQL or Java memory--are using a lot of PGA, leaving little
behind for work areas to be managed in automatic mode.
global memory bound shows the maximum size of a work area executed in automatic
mode. The value is constantly adjusted by Oracle based on the current state of the
work area workload and generally decreases when the number of active work areas
increase. Oracle recommends that this value should never reach 1MB; if it does, it's
probably an indicator that PGA_AGGREGATE_TARGET should be increased.
total PGA allocated yields the total amount of PGA memory that Oracle has allocated
for the instance, while total PGA used for auto workareas tells how much memory is
in use by other processes like PL/SQL or Java. Subtracting the second number from
the first yields the total PGA memory used by these other processes.
over allocation count tells how much PGA memory has been over-allocated
cumulatively since the instance was started. If the value returned is anything over
zero, it is an indication that the size of PGA_AGGREGATE_TARGET should be
increased because it means that Oracle could not honor at least one request for
additional PGA work areas.
total bytes processed represents how many bytes were processed since instance
startup, while extra bytes read/written represents how many bytes were processed
via one-pass or multi-pass processing. These two values are used to calculate the
cache hit percentage based on the following formula: (100 * total bytes processed) /
(total bytes processed + extra bytes read/written).
----------
The results from this query show that almost all of the PGA work areas are sized optimally,
except for a few in the 64K to 128K range, and a handful of larger queries in the 32M to
128M range.
Yet another query against this view summarizes the number of times work areas were
executed in optimal, one-pass, and multi-pass modes since the instance was started. Note
that this query looks at all work areas; smaller work areas can be screened out by adding
the appropriate selection criteria:
SELECT
optimal_count "Optimal",
round(optimal_count * 100 / total,2) "Optimal %",
onepass_count "OnePass",
round(onepass_count * 100 / total,2) "Onepass %",
multipass_count "MultiPass",
round(multipass_count * 100 / total,2) "Multipass %"
FROM (
SELECT
DECODE (SUM(total_executions), 0, 1, SUM(total_executions)) total,
SUM(optimal_executions) optimal_count,
SUM(onepass_executions) onepass_count,
SUM(multipasses_executions) multipass_count
FROM v$sql_workarea_histogram
-- Limits consideration of queries with LOW_OPTIMAL_SIZE limit <64K
-- WHERE low_optimal_size > 64*1024);
OPERATION_TYPE
-------------------SORT
SORT
SORT
GROUP BY (SORT)
SORT
GROUP BY (SORT)
GROUP BY (SORT)
SORT
SORT
SORT
GROUP BY (SORT)
GROUP BY (SORT)
GROUP BY (SORT)
BUFFER
GROUP BY (SORT)
BUFFER
GROUP BY (SORT)
GROUP BY (SORT)
SORT
SORT
POLICY
ESTIMATED_OPTIMAL_SIZE
---------- ---------------------AUTO
19456
AUTO
19456
AUTO
19456
MANUAL
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
AUTO
19456
Once a baseline has been established, PGA sizing can be tuned by consulting another useful
view, V$PGA_TARGET_ADVICE. This view shows how the current setting for the PGA
compares to its optimal usage historical usage, and offers advice on what would happen if
the PGA was increased or decreased in size by looking at PGA statistics since the instance
was last started. Here is a sample query:
SELECT
ROUND(pga_target_for_estimate /(1024*1024)) "Target (M)",
estd_pga_cache_hit_percentage "Est. Cache Hit %",
estd_overalloc_count "Est. Over-Alloc"
FROM V$PGA_TARGET_ADVICE;
Target (M) Est. Cache Hit % Est. Over-Alloc
---------- ---------------- --------------50
62
36
100
85
3
200
86
0
300
87
0
400
88
0
480
88
0
560
88
0
640
88
0
720
88
0
800
88
0
1200
93
0
1600
100
0
2400
100
0
3200
100
0
This result set shows that by increasing the size of PGA_AGGREGATE_TARGET beyond my
initial estimate of 400MB to 1200MB, the database would eventually improve its
performance significantly beyond the estimated cache hit ratio. This is not surprising, since
the original allocation formula suggested a value of approximately 1310MB for OLTP
database usage. Of more interest, however, is that there is very little additional gain in
allocating more than 1200MB to PGA_AGGREGATE_TARGET.
Oracle acknowledges that there is a point of diminishing return when almost all work areas
are executed in optimal or one-pass mode. Therefore, Oracle recommends concentrating
any tuning efforts upon first insuring that PGA_AGGREGATE has been set high enough that
there is no memory over-allocation (see the previous V$PGASTAT query for more
information).
Finally, be sure that the STATISTICS_LEVEL initialization parameter has been set to either
TYPICAL (the default) or ALL. If this parameter is set to BASIC, the V$PGA_TARGET_ADVICE
view is disabled.