[Editor's note: This article was corrected and expanded on 23 August 2005 and again on 5 September 2005. Make sure to heed the warning in the text: "These are undocumented parameters and they should not be used unless you are willing to accept full responsibility for any issues."]
[Author's note: In response to this tip, one reader has repeatedly demanded that SearchOracle remove this tip, claiming that my observations are wrong, and citing as evidence a single test case using the MTS. Of course, an artificial test case cannot be generalized to all Oracle databases, and this is why real-world experience is so valuable. The information in this tip was gleaned from my real-world experiences and those of my co-workers and colleagues. Remember, there are hundreds of default installations of Oracle and obviously, your mileage may vary. I have enhanced this tip again, including more clarifications and a 230 page artificial test case to show that my original tip observations were substantially correct. Note that this tip contains unsupported secrets that are not published in the Oracle documentation and you should carefully read the MetaLink references, test them on your own database, and open an iTar before trying any of these powerful techniques. – Donald K. Burleson, 9/5/2005]
Introduction
Almost every Oracle professional agrees that the old-fashioned sort_area_size and hash_area_size parameters imposed a cumbersome one-size-fits-all approach to sorting and hash joins. Different tasks require different RAM areas, and the trick has been to allow "enough" PGA RAM for sorting and hash joins without having any high-resource task "hog" all of the PGA, to the exclusion of other users.
Oracle9i introduced the pga_aggregate_target parameters to fix this resource issue, and by-and-large, pga_aggregate_target works very well for most systems. You can check your overall PGA usage with the v$pga_target_advice advisory uti
To continue reading for free, register below or login
To read more you must become a member of SearchOracle.com
lity or a STATSPACK or AWR report. High values for multi-pass executions, high disk sorts, or low hash join invocation might indicate a low resource usage for PGA regions.
Let's take a look at the issues surrounding the hidden limits of pga_aggregate_target.
The limits of sorting and hashing
There are important limitations of pga_aggregate_target:
These restrictions were made to ensure that no large sorts or hash joins hog the PGA RAM area, but there are some secrets to optimize the PGA. For example, the following set of parameters may be mutually-exclusive:
(Note: there may be some cases where sort_area_size is used in Oracle utilities, but these have not been documented, even with pga_aggregate_target.)
Let's take a closer look at expert tricks for advanced PGA management.
Hidden parameters for Oracle PGA regions
With proper understanding (and knowing that these undocumented parameters are not supported by Oracle), you can adjust your PGA regions to allow for system-specific sorting and hash joins.
We also see these additional undocumented parameters:
[TABLE]
WARNING - These are unsupported parameters and they should not be used unless you have tested their behavior on your own database and you are willing to accept full responsibility for any issues.
Super-size me
For certain Oracle applications the Oracle professional will want to allow individual tasks to exceed the default limits imposed by Oracle. For example, PC-based, 64 bit Oracle servers (1 or 2 CPU's with 8 gigabytes of RAM) will often have unused RAM available. For example, a fully-cached 5 gigabyte database on an 8 gigabyte dedicated Oracle server will have approximately 1 gigabyte available for the PGA (allowing 20% for the OS and other SGA regions):
The system has a pga_aggregate_target setting of 1 gigabyte and the undocumented parameters are at their default settings.
While it is unusual for an online system to require super-sized regions for sorting (because the result sets for online screens are normally small), there can be a benefit to having large RAM regions available for the Oracle optimizer.
The Oracle cost-based optimizer will determine whether a hash join would be beneficial over a nested-loop join, so making more PGA available for hash joins will not have any detrimental effect since the optimizer will only invoke a super-sized hash join if it is better than a nested-loop join. In a system like the example above, the following settings would increase the default sizes for large sorts and hash joins while limiting those for parallel sorts.
With these hidden parameters set we see significant size increase for serial sorts and a throttling effect for parallel queries and sorts. To see a reproducible, artificial test case demonstrating sort throttling, Mike Ault has prepared a 230 page artificial test case: Validation of Sort Sizes in a Linux Oracle10g Database. However, bear in mind that it only valid for a specific release of Oracle10g, on a specific hardware and OS environment, and not using any optional features such as the MTS.
In conclusion, overriding the built-in safeguards of pga_aggregate_target can make more efficient use of RAM resources in cases where large RAM regions are available on the database server. When used with care (and the blessing of Oracle Technical Support) it can often make sense to over-ride these default values to make better use of expensive RAM resources. There is also lots of evidence that changing these parameters will have a positive effect of large, batch-oriented Oracle jobs, but you must be very careful to fully understand the limitations of the PGA parameters:
Important caveats
Success stories
Laurent Schneider notes in Oracle MetaLink that overriding the PGA defaults made a large batch processes run more than 8x faster:
"I set appropriate values for pga_aggregate_target and _pga_max_size...
...and I gave the query some hints "NOREWRITE FULL USE_HASH ORDERED". As a result, it boosted my query performance from 12 hours to 1.5 hour."
References
