DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

А теперь сделаем красивую обертку


Настройка производительности 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 на основании событий ожидания, а не коэффициентов.
 









jAntivirus