25июн
Использование представления v$db_cache_advice
В СУБД Oracle9i появилась консультативная справка по кешу буферов (Buffer Cache Advisory). Данные этой справки (представление V$DB_CACHE_ADVICE ) - это результат внутреннего моделирования, основанного на текущей рабочей нагрузке. Справка предсказывает частоту неудачных обращений к кешу для различных размеров кеша буферов в диапазоне от 10% до 200% текущего размера кеша. При этом параметр STATISTICS_LEVEL должен принимать значения TYPICAL или ALL. Или можно установить в параметре db_cache_advice файла init.ora значение "on" или "ready".
Выполним запрос:
Select size_for_estimate, buffers_for_estimate, estd_physical_read_factor, estd_physical_reads from v$db_cache_advice
where name = 'DEFAULT' and block_size = (SELECT value FROM V$PARAMETER WHERE name = 'db_block_size')
and advice_status = 'ON';
SIZE_FOR_ESTIMATE BUFFERS_FOR_ESTIMATE ESTD_PHYSICAL_READ_FACTOR ESTD_PHYSICAL_READS
-------------------------------------- -------------------------------------- -------------------------------------- --------------------------------------
48 6006 1,0742 422119
96 12012 1,0356 406952
144 18018 1,0303 404872
192 24024 1,0208 401147
240 30030 1,0168 399558
288 36036 1,0136 398291
336 42042 1,0107 397175
384 48048 1,0059 395265
432 54054 1,004 394528
480 60060 1,002 393752
504 63063 1 392958
528 66066 0,9997 392845
576 72072 0,9975 391994
624 78078 0,996 391369
672 84084 0,9947 390859
720 90090 0,9924 389989
768 96096 0,992 389800
816 102102 0,9915 389630
864 108108 0,9912 389497
912 114114 0,991 389403
960 120120 0,9908 389327
По приведенному примеру можно сделать вывод, что никаких пиковых изменений дискового ввода-вывода не предвидится при увеличении буферного кеша. То есть нельзя найти оптимального размеров – сколько оракл ни корми, он все съест и ещё захочет. Таким образом изменение размера буферного кэша в сторону увеличения не приведет к существенному повышению производительности.
В принципе, нужно настраивать размер буферного кэша таким, чтобы дальнейшее увеличение количества буферов блоков данных не приводило к значительному увеличению коэффициента попадания в кеш буферов. Также важно, чтобы многократно используемые блоки постоянно находились в кэше, а блоки, используемые единожды, быстро его покидали.
Заметки.
- Для сбора статистик в представлении v$db_cache_advice требуется дополнительные ресурсы, поэтому нужно оценить целесообразность одноразового включения сбора статистик для определения оптимального размера кеша буферов. Тем более, что для сбора аналогичной информации всегда можно использовать коэффициент попаданий в кеш буферов данных.
-
- Желательно устанавливать db_cache_advice в значение ready, а не on. В этом случае Oracle будет выделять память во время запуска экземпляра.
- Есть и негативные стороны в использовании очень большого буферного кэша. Поскольку прямой доступ к данным производится с использованием механизма хэширования (hashing), через определенные промежутки времени база данных должна обследовать все блоки в кэше. Это в частности происходит по причине удаления больших объемов данных, использования временных таблиц. Также большой кэш является причиной большой нагрузки на процесс записи DBWR.
Литература
http://citforum.univ.kiev.ua/database/oracle/kyte/02.shtml
http://www.praetoriate.com/t_oracle_data_block_caching_sga.htm
http://citforum.univ.kiev.ua/database/oracle/kyte/02.shtml
www.dcopeland.net/files/IT453chapter02buffercache.ppt
http://advait.wordpress.com/2007/06/13/tuning-buffer-cache-oracle-database-10g/
http://www.praetoriate.com/t_%20tuning_data_buffer_hit_ratio.htm
http://www.interface.ru/oracle/isan.htm