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

Updates!  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:

• pga_aggregate_target Examples

• The limitations of the pga_aggregate_target parameter

• Oracle 10g release 2 changes pga_aggregate_target limits

• Monitoring Oracle SGA & PGA Memory Changes

• Oracle hash joins tips

• Tuning large oracle batch jobs

Get the Complete Oracle SQL Tuning Information  The landmark book "Advanced Oracle SQL Tuning  The Definitive Reference"  is filled with valuable information on Oracle SQL Tuning. This book includes scripts and tools to hypercharge Oracle 11g performance and you can buy it for 30% off directly from the publisher.