Базы данных Oracle - статьи
Общая методология
Оптимизация производительности – это не одноразовая задача, а постоянный процесс. Для эффективной настройки систем баз данных требуются хорошие методы и инструментальные средства. В комплексный процесс оптимизации производительности должны входить следующие шаги:
- Регулярный сбор полного набора статистических показателей операционной системы, экземпляров СУБД и приложений.
АБД всегда должны иметь набор статистических показателей, собранных в конкретный момент времени, которые они должны использовать как базовый набор для сравнения. Когда они будут пытаться определить причину деградации производительности или пытаться повысить производительность, сравнение текущих статистических показателей с базовыми статистическими показателями поможет АБД быстро определить главную область приложения усилий. Это даже более важно в случае перехода на новую версию СУБД. Статистические показатели всегда следует собирать перед и после перехода на новую версию СУБД, что может позволить АБД в случае неожидаемого поведения системы определить, настолько быстро, насколько возможно, причину проблемы. Для этих целей в СУБД Oracle предусмотрена утилита StatsPack. StatsPack – это инструментальное средство для комплексного диагностирования проблем производительности на уровне СУБД и приложений. Эта утилита может быть настроена для снятия "моментальных копий" данных производительности и сохранения их в постоянных таблицах базы данных. Пользователь может задать интервал снятия моментальных копий, т.е. частоту сбора данных, а также количество собираемых статистических показателей. Более подробно об инсталляции и использовании утилиты StatsPack см. в технических документах "Diagnosing Performance Using StatsPack, Part I and II" (диагностирование производительности с помощью пакета StatsPack, части I и II) (http://otn.Oracle.com/deploy/performance/content.html).
Главная цель сбора статистических показателей – определить проблемы производительности сервера базы данных. Утилита StatsPack выдает легкочитаемый отчет, который указывает на потенциальные области проблем производительности. Итоговая страница типового отчета утилиты StatsPack показана на рис. 2. Этот отчет наиболее полезен, когда для сравнения с текущими показателями производительности системы имеются базовые показатели, поскольку это позволяет АБД обнаружить, что действительно изменилось в системе. Например, если бы процент использования разделяемого пула существенно увеличился, это указало бы на возможное использование в приложениях литеральных значений, приводящее к дополнительному разбору операторов SQL и, следовательно, к замедлению работы системы.
Рис. 2. На первой странице типового отчета утилиты StatsPack на первом плане размещаются ключевые данные о системе.
Как только проблемные области будут идентифицированы, определение потенциальных решений будет относительно простой задачей. Например предположим, на шаге (ii) мы обнаружили, что причиной появления узких мест в системе является использование в хранимых процедурах литеральных значений. Очевидным решением этой проблемы является замена в хранимых процедурах литеральных значений на переменные связывания. Если приложение очень большое, такое, как большинство ERP-приложений, это решение может оказаться нежизнеспособным. В таком случае лучшим решением было бы включение принудительного разделение курсоров с помощью установки параметра инициализации CURSOR_SHARING=FORCE. Таким способом следует наметить в общих чертах одно или более решений для каждой идентифицированной проблемной области.
Золотое правило настройки системы – одновременное внесение одного изменения, а затем измерение возникших различий. Давайте предположим, что на шаге (ii) мы идентифицировали несколько проблемных областей, а на следующем шаге определили потенциальные способы решения проблем. Рекомендуемое правило заключается в реализации каждого способа по отдельности, а затем в измерении его влияния на систему. Однако требования к времени простоя системы могут не позволить воспользоваться таким правилом. В этом случае нужно попытаться реализовать только такой набор способов, которые можно проверить независимо.
Как только способ решения проблем реализован, его необходимо проверить. Проверку следует осуществлять на уровне пользовательского восприятия производительности, а также повторением шага (i) и сбора дополнительных статистических показателей, позволяющих оценить, имеет ли данный способ желательное влияние или нет. Кроме того, если нагрузка на систему со временем изменяется или модифицируются приложения, весь процесс настройки следует повторить.
