Oracle Sorting Enhancements

Oracle Tips by Burleson Consulting
July 29, 2003, revised 1/1/2008

2008 Update: See my 10g & 11g sorting tips and my article on super-sizing the Oracle PGA for experts only.

A serious problem in Oracle8i was the requirement that all dedicated connections use a one-size-fits-all sort_area_size . Oracle 9i and beyond now has the option of running automatic PGA memory management .

Oracle has introduced a new Oracle parameter called pga_aggregate_target . When the pga_aggregate_target parameter is set and you are using dedicated Oracle connections, Oracle9i will ignore all of the PGA parameters in the Oracle file, including sort_area_size, hash_area_size and sort_area_retained_size . Oracle recommends that the value of pga_aggregate_target be set to the amount of remaining memory (less a 10 percent overhead for other UNIX tasks) on the UNIX server after the instance has been started.

Once the pga_aggregate_target has been set, Oracle will automatically manage PGA memory allocation based upon the individual needs of each Oracle connection. Oracle9i allows the pga_aggregate_target parameter to be modified at the instance level with the alter system command, thereby allowing the DBA to dynamically adjust the total RAM region available to Oracle9i.

Oracle9i also introduces a new parameter called workarea_size_policy . When this parameter is set to automatic, all Oracle connections will benefit from the shared PGA memory. When workarea_size_policy is set to manual, connections will allocate memory according to the values for the sort_area_size parameter. Under the automatic mode, Oracle tries to maximize the number of work areas that are using optimal memory and uses one-pass memory for the others.

In addition to increasing the amount of memory devoted to sorting, you should also hunt down inefficient SQL that cause needless sorts. For example, union all does not cause a sort, whereas union does in a SQL query (to eliminate duplicate rows). The distinct keyword is oftentimes coded inappropriately (especially by folks transferring from Microsoft Access, which used to use distinct for nearly every query).

The Limits of sorting and hashing

Many Oracle professionals do not know the important limitations of pga_aggregate_target:

The total work area cannot exceed 200 megabytes of RAM because of the default setting for _pga_max_size.
No RAM sort may use more than 5% of pga_aggegate_target or _pga_max_size, whichever is smaller. This means that no task may use more than 10 megabytes for sorting or hash joins.

The following settings would increase the default sizes for large sorts and hash joins.

pga_aggregate_target = 1000m
_pga_max_size = 1000m
_smm_px_max_size = 333m

With these hidden parameters set we see a 5x large size increase for parallel queries and sorts:

A RAM sort or hash join may now have up to 50 megabytes (5% of pga_aggegate_target) a 5x increase.
Parallel queries may now have up to 330 megabytes of RAM (30% of pga_aggegate_target), such that a DEGREE=4 parallel query would have 83 megabytes (333 meg/4).

See my related notes on Oracle sorting:

If you like Oracle tuning, you might enjoy my book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts.

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.

Need an Oracle Health Check?

Do you have bad performance after an upgrade?
Need to certify that your database follows best practices?

BC Oracle performance gurus can quickly certify every aspect of your Oracle database and provide a complete verification that your database is fully optimized.