Настройка экземпляра главным образом производится администраторами баз данных в ответ на снижение производительности базы данных Oracle. В этой статье блога будет описано, как приступить к анализу экземпляра для выяснения того, где скрывается проблема.
Перед этим, однако, необходимо проанализировать показатели по использованию всех главных ресурсов, наподобие памяти, ЦП и подсистемы хранения, получив уверенность в том, что база данных работает медленно не из-за образования узких мест в этих критически важных областях.
На заметку! Сбор данных базовой линии по статистическим показателям базы данных, в том числе и событиям ожидания, очень важен для выявления и устранения проблем с производительностью. Наличие данных базовой линии позволяет сразу же проверить, соответствуют ли текущие схемы использования ресурсов объему нагрузки на систему.
Анализ происходящего в базе данных Oracle
Нередко SQL-запрос одного единственного пользователя способен вызывать ухудшение производительности в масштабах всего экземпляра, если он довольно плохо составлен. SQL-операторы исполняют центральную роль во всей работе базы данных, поэтому сначала следует проанализировать, что происходит в базе данных прямо в текущий момент. Ниже перечислены некоторые ключевые вопросы, на которые потребуется получить ответы.
- Какие пользователи идут первыми в списке Top Sessions?
- Какие точно SQL-операторы выполняют эти пользователи?
- Не является ли количество пользователей необычно большим по сравнению с показателями базовой линии за такой же период времени?
- Не является ли нагрузка на базу данных выше той, что должна быть согласно показателям базовой линии за такое же время дня, недели или месяца?
- Какие важные события ожидания отображаются в представлении V$SESSION или V$SESSION_WAIT. Эти работающие в режиме реального времени представления отображают события ожидания, которые либо происходят в экземпляре прямо сейчас, либо только что произошли. Способы выявления фактических пользователей, ответственных за те или иные события ожидания, посредством других представлений V$ рассматривались ранее в этой статье.
Другой важный вопрос состоит в том, возникла ли испытываемая сейчас проблема с производительностью внезапно безо всяких предварительных предпосылок или же постепенно в результате усугубления определенных факторов. Под такими факторами подразумеваются вещи наподобие разрастания базы данных, увеличения количества пользователей и повышения числа DML-операций обновления по сравнению с тем, на которые изначально рассчитывалась система. Проблемы подобного рода могут требовать перепроектирования, как минимум, некоторых таблиц и индексов с использованием для них других параметров хранения и прочих параметров, вроде списков свободных блоков (freelists). Если же, с другой стороны, работа базы данных замедлилась внезапно, тогда внимание понадобится сфокусировать на отдельном ряде элементов.
Лучший способ для проведения анализа того, что происходит в базе данных в текущий момент, предусматривает применение ASH. С помощью запроса к представлению V$ACTIVE_SESSION_HISTORY, о котором более подробно рассказывалось в блоге, в разделе “Использование представления V$ACTIVE_SESSION_HISTORY”, легко выяснить, какие пользователи, объекты и SQL-операторы вызывают в экземпляре ожидания. Можно также сгенерировать быстрый отчет ASH, охватывающий лишь последние несколько минут, и узнать, где в системе могут присутствовать узкие места и по чьей вине.
Совет. В OEM Database Control предлагается мастер Gather Statistics Wizard (Мастер сбора статистики), которым можно пользоваться в случае появления проблем с производительностью из-за устаревших статистических данных по фиксированным и словарным объектам.
