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
который как может костерит Дона Бурлесона :)))
Читать дальше...
Сообщения
