How if the configuration of the PGA is appropriate?

Question

how if the configuration of the PGA is appropriate?
The 79.51% of cache hit percentage I want to say that the PGA is not sufficient to reach 100%?
SQL>select * from v$pgastat;
NAME VALUE UNIT
aggregate PGA target parameter 1388314624 bytes
aggregate PGA auto target 806593536 bytes
global memory bound 138823680 bytes
total PGA inuse 493501440 bytes
total PGA allocated 1073356800 bytes
maximum PGA allocated 2282989568 bytes
total freeable PGA memory 53608448 bytes
process count 97
max processes count 211
PGA memory freed back to OS 3.4802E+11 bytes
total PGA used for auto workareas 1146880 bytes
NAME VALUE UNIT
maximum PGA used for auto workareas 759861248 bytes
total PGA used for manual workareas 0 bytes
maximum PGA used for manual workareas 8872960 bytes
over allocation count 0
bytes processed 1.3298E+12 bytes
extra bytes read/written 3.4263E+11 bytes
cache hit percentage                                                  79.51 percent
recompute count (total) 109363
19 rows selected.
Oracle 10g R2
ACS

Answer 1

ACS wrote:
how if the configuration of the PGA is appropriate?
The 79.51% of cache hit percentage I want to say that the PGA is not sufficient to reach 100%?
SQL>select * from v$pgastat;
You really need to look at AWR reports (if you are licensed) or set up Statspack, then look at the details you get in the "PGA Histogram" section of the report. This comes from the v$sql_workarea_histogram and summarises the number of workarea requirements you've had, the number that were met (optimal) the number that dropped to one-pass, and the number that dropped to multipass.
It's possible that your 'hit percentage' is the result of a very small number of very large operations, in which case it may be pointless to increase the pga_aggregate_target very much - and perhaps you need to find out why the small number of very big hitters appeared. Alternatively, you may find that you have a larger number of relatively small (few MB) operations that dropped to one-pass, which may be a better indicator that you need a larger pga_aggregate_target.
Bear in mind, though, that timing can be significant - you may have only one hour in the day where a major load appears and skews the result, and it would be a good idea to find that skew.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.