The Memory Structures from Tom Kyte's Expert Oracle 10g Edition

Безусловно очень интересная статья про структуры oracle.

В частности интереса тем, что проясняет в часности вопрос, может ли одна сессия использовать более 5% от pga_aggregate_target (если workarea_size_policy=auto)


Насколько я понял, в сессии выполняющей сериальный запрос каждая область сортировки будет не более 5%, в сессии выполняющей параллельный запрос 0.3 * PGA_AGGREGATE_TARGET / (number of parallel processes).

Еще раз, важно каждая область сортировки.

Понятно, что pga_aggregate_target аллокируется не сразу по старту экземпляра, а по мере необходимости.

В случае если число сессией возрастает, oracle старается увличить память pga до PGA_AGGREGATE_TARGET, одновременно зажимая лимиты для сессий. Tom приводит графики, как это происходит.

Что же делать если у нас есть сессия, отдельные области под сортировку которой нам бы хотелось сделать скажем под 100m ?

Tom Kyte
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:47466211228419

показывает что и тут нет проблем.
Почти потому, что заставить делать сортировки в памяти более 200m проблема.



Дон Бурлесон утверждает, что это лимит устанлвиватся недокументированным параметром
_pga_max_size, но Tom показывает, что этот лимит назывется _smm_max_size.

Результирующая фраза:

"
No RAM sort may use more than _smm_max_size, which is expressed in Kilobytes as
a value.
"

Резюме.

Использовать workarea_size_policy=auto полезно, чтобы не приходилось следить за swap'ом.
Если у Вас есть сессии, которым надо много сортировать, лучше (и быстрее будет) для них вручную выставить sort_area_size и workarea_size_policy=manual, скажем в триггере on_logon.
Можете устанавливать недокументированные параметры _pga* и _smm*, но зачем тогда вообще пользоваться автоматическим механизмом ?




Интересно также прочитать Льюиса
http://www.jlcomp.demon.co.uk/untested.html
который как может костерит Дона Бурлесона :)))