What percentage of sorting is done in Memory?

Question

DB Version:10g Release 2
When you have a query with a large number of columns in the ORDER BY clause or a query without ORDER BY clause but with a larger number of columns in the SELECT list, the PGA_AGGREGATE_TARGET might not be sufficient to do this job. So, What % of PGA is set aside by Oracle for sorting? When this reserved % is reached in Memory(PGA_AGGREGATE_TARGET), temp tablespace is used,ie Disk sort. Right?

Answer 1

J.Kiechle wrote:
DB Version:10g Release 2
When you have a query with a large number of columns in the ORDER BY clause or a query without ORDER BY clause but with a larger number of columns in the SELECT list, the PGA_AGGREGATE_TARGET might not be sufficient to do this job. So, What % of PGA is set aside by Oracle for sorting? When this reserved % is reached in Memory(PGA_AGGREGATE_TARGET), temp tablespace is used,ie Disk sort. Right?It's probably a bit different and a bit more complex, but in a nutshell the PGA_AGGREGATE_TARGET defines the upper limit that Oracle should use for the PGA areas of the processes used to run the database.
There is a non-tunable part that contributes to the PGA_AGGREGATE_TARGET, that can be significantly influenced e.g. by large PL/SQL collections or Java programs. The memory consumed by these can not be controlled by Oracle and therefore can't be reduced, but will be used in the overall calculation.
The tunable part consists of the SQL workareas that are used to sort, group or hash data as part of the SQL execution.
The value of PGA_AGGREGATE_TARGET determines several internal parameters, among them are pgamax_size, smmmax_size and smmpx_max_size. These internal parameters control the maximum amount of memory that can by used a single process (_pga_max_size), a serial operation resp. "workarea" (_smm_max_size) and the maximum memory available for the operation of a parallel slave in a parallel operation (_smm_px_max_size).
There is a significant difference between 10.2 and previous Oracle releases regarding these internal parameters:
In pre-10.2 databases pgamax_size defaults to 200M, and smmmax_size is the least of 5% of PGA_AGGREGATE_TARGET and 50% of pgamax_size, and 100M (if you set pgamax_size larger than the default value). The smmpx_max_size is 30% of PGA_AGGREGATE_TARGET and is divided by the parallel degree of the parallel operation to determine the upper limit of a workarea size of a single parallel slave together with smmmax_size.
In 10.2 the upper limits are driven by the smmmax_size which is derived from PGA_AGGREGATE_TARGET and can be larger than 100M if you have a PGA_AGGREGATE_TARGET greater than 1GB. The pgamax_size is then two times smmmax_size.
So in pre-10.2 databases the default maximum size of a single sort is 100M, provided you've set PGA_AGGREGATE_TARGET set to 2GB or greater, but a single process - that could have multiple workareas or sorts simultaneously - is not allowed to allocate more than 200MB in total.
In 10.2 and later you can have more than 100M for a single sort if you set your PGA_AGGREGATE_TARGET larger than 1GB, and a process can consume more than 200M in that case, too.
For more information about these parameters, see e.g. these two interesting notes:
http://christianbilien.wordpress.com/2007/05/01/two-useful-hidden-parameters-smmmax_size-and-pgamax-size/
http://www.jlcomp.demon.co.uk/untested.html
The amount of memory that remains after subtracting the non-tunable memory allocated from the PGA_AGGREGATE_TARGET and the number and size of concurrent tunable workareas determine the amount of memory available for newly established workareas, so that Oracle tries to do its best to allocate the available memory to all current workareas while at the same time attempts to stay below the PGA_AGGREGATE_TARGET. Obviously if many workareas are active concurrently the amount of memory available for each workarea will be less than the upper limits outlined above, down to a lower limit which is defined by the internal parameter smm_min_size (the greatest of 128k and 0.1% of PGA_AGGREGATE_TARGET).
Given these constraints it is possible that Oracle consumes more than the PGA_AGGREGATE_TARGET, eg. if the non-tunable part already takes a significant part of the PGA_AGGREGATE_TARGET. You can see this e.g. in V$PGASTAT if the "over allocation count" statistic value is > 0.
The cost based optimizer also uses the information derived from PGA_AGGREGATE_TARGET to calculate the cost of a sort resp. to estimate whether a sort will be in-memory or has to spill to disk.
There are various views available that allow you to monitor the workarea information, among them are V$PGASTAT for an overall information regarding the PGA consumption, V$PGA_TARGET_ADVICE, V$PGA_TARGET_ADVICE_HISTOGRAM and V$SQL_WORKAREA_HISTOGRAM, V$SQL_WORKAREA_ACTIVE and V$SQL_WORKAREA for monitoring individual workareas.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/