Настройка производительности Oracle: резюме
Есть старая пословица - все хорошее когда-нибудь кончается. Это относится и к данной книге. Теперь, когда мы отдали значительную часть последних шести месяцев нашей жизни работе по описанию настройки производительности Oracle и связанных с этим компонентов, самое время опустить занавес, упаковать вещи и двинуться к новым приключениям. Жизнь - это бесконечное путешествие в поисках новых вызовов, и она продолжает оставаться забавной, пока мы учимся по итогам этих вызовов и наращиваем свой жизненный опыт. Написание книги, конечно же, стало для нас во многих аспектах большим жизненным опытом.
У любой хорошей презентации должно быть три компонента: введение,
текст и выводы. Ожидается, что введение ознакомит нас с темой (расскажите, о
чем вы будете текст, как этого и следовало ожидать, предложит отно-
текст и выводы. Ожидается, что введение ознакомит нас с темой (расскажите, о
чем вы будете текст, как этого и следовало ожидать, предложит отно-
сящиеся к разбираемой теме подробности (говорите о вещах, которых от вас а выводы будут содержать самую суть того, что обсуждалось в тексте (повторите то, что вы только что говорили). Для сохранения литературных традиций и норм мы будем придерживаться той же линии поведения. Поэтому сейчас, на последнем круге нашего марафона, подведем итоги каждой главы.
Что такое управление производительностью Oracle?
Это пошаговый процесс итеративного исследования, определения и реализации решений по настройке с использованием проверенной методологии. В процессе настройки системы очень важно знать, когда настраивать, что настраивать, сколько настройки будет в самый раз, а когда приходит время остановиться. Ставятся конкретные цели, и все попытки настройки прекращаются, как только эти цели будут достигнуты.
Метод, стоящий за безумием
Каждое усилие по настройке производительности Oracle потенциально имеет три аспекта: настройка, планирование выполнения и покупка. В конце концов не ставьте на кон свою профессиональную жизнь за настройку
производительности систем Oracle на базе попаданий в кэш. Если следовать процессу постановки достижимых целей, измерять текущие значения производительности, делать преднамеренные и хорошо обдуманные изменения, а затем заново оценивать течение процесса и повторять его, можно быть уверенным, что мы обязательно добьемся прогресса в своих попытках настройки. Использование "вилочного" подхода, когда, с одной стороны, выполняется мониторинг операционной системы на предмет обнаружения узких мест ресурсов, а с другой стороны, используется статистика ожиданий сеансов внутри Oracle для определения точной природы узких мест по производительности, позволяет предпринимать очень эффективные усилия по настройке. Ключевым моментом этого метода является погружение в глубины проблемы. Вот как это делается:
Начните с представления и определите, какой ресурс пользуется наибольшим спросом, например, db file sequential read (последовательное чтение файла базы данных).
Затем погрузитесь на уровень V$SESSION_EVENT и посмотрите, сколько сеансов и какие участвуют в этом событии ожидания.
Далее, взгляните на V$SESSION_WAIT, чтобы познакомиться с деталями конкуренции за ресурс, скажем, какие-то файлы,
таблицы, защелки и т. п.
Проверьте значения Р1-РЗ, чтобы найти взаимосвязи с другими представлениями.
Рассмотрите время ожидания этих и других событий. Работайте не
более, чем с пятью первыми событиями из списка.
6. Продолжайте процесс до тех пор, пока не будут найдены все узкие
места.
В то же самое время определите, какие операторы SQL вносят вклад в возникновение этих узких мест.
Действуя параллельно, соберите и проанализируйте статистику ОС. Не забудьте при этом о среде Oracle. Это значит, что необходимо понимать статистику ОС, поскольку она имеют отношение к Oracle.
После того как определена проблемная область, примите решение,
испытайте его, а затем реализуйте.
10. Контролируйте изменения, чтобы отслеживать изменения и их
влияние.
влияние.
После реализации решения проведите повторную оценку, чтобы проверить, достигнута ли намеченная цель.
Итак, теперь уже, наверное, в последний раз, если коэффициент попаданий
в буферный кэш базы данных имеет малое значение, и мы собираемся поднимать тревогу, нужно остановиться и посмотреть, в чем заключается событие ожидания для системы. Если отсутствуют события ожидания, связанные с вводом/выводом, подозрения относительно проблемы с производительностью беспочвенны. С другой стороны, если коэффициенты попадания в кэш зашкаливают за 90%, еще рано усаживаться в кресло и думать, что все идет самым лучшим образом. Необходимо проверить наличие событий ожидания. Не стоит думать, что значение коэффициента попаданий в кэш, равное 99,999%, означает, что база данных Oracle работает с пиковой эффективностью, поскольку даже при таком значении этого коэффициента может назревать что-то весьма опасное. Нужно настраивать систему Oracle на основании событий ожидания, а не коэффициентов.
< Предыдущая | Следующая > |
---|