Oracle Sorting Enhancements
Oracle Tips by Burleson Consulting
July 29, 2003, revised 1/1/2008
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
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 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:
Get the Complete
Oracle SQL Tuning Information
The landmark book
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
for 30% off directly from the publisher.