Простой подход к настройке экземпляра база данных Oracle - Применение интерфейса OEM Database Control для изучения показателей по производительности базы данных

« Prev
Next »

Применение интерфейса OEM Database Control для изучения показателей по производительности базы данных

Интерфейсы OEM Database Control и OEM Grid Control подробно рассматривались в наших блогах. Знать обо все различных представлениях VS$, касающихся событий ожидания и производительности, несомненно, полезно, но ничто не может сравниться с интерфейсом Database Control по возможности быстрого выяснения того, что конкретно происходит в базе данных в любой момент времени. Ниже я опишу простой подход к использованию различных страниц Database Control, связанных с производительностью.

 

Домашняя страница Database Control

Начинать анализ следует с просмотра трех перечисленных ниже диаграмм производительности на домашней странице Database Control. На рис. 20.2 показано, как выглядит эта страница.

 

Диаграмма Host CPU

Потребление ресурсов ЦП на хост-сервере отображается в виде столбчатой диаграммы Host CPU (ЦП хоста). Эта диаграмма состоит из двух категорий: instance (экземпляр) и other (другие), в которой отображается информация обо всех процессах, не принадлежащих экземпляру базы данных.

 

Диаграмма Active Sessions

Диаграмма Active Sessions (Активные сеансы) является ключевой, поскольку отражает количество связанных с производительностью узких мест в экземпляре базы данных.

Диаграмма Active Sessions (Активные сеансы)

Рис. 2. Диаграмма Active Sessions (Активные сеансы)

 Она состоит из трех компонентов:

  • CPU (ЦП)
  • User I/O (Пользовательский ввод-вывод)
  • Wait (События ожидания)

Другими словами, она отражает потребляемое время в виде трех категорий: CPU, User I/O и Wait. Каждую из этих категорий можно изучить более подробно, щелкнув на соответствующей ссылке. Обратите внимание, что категория Wait включает в себя все события ожидания в экземпляре, кроме тех, которые связаны с пользовательскими операциями ввода-вывода, потому что они отображаются в отдельной категории.

 

Диаграмма SQL Response Time

Диаграмма SQL Response Time (Время отклика SQL) позволяет получать быстрое представление о том, насколько эффективно в экземпляре выполняются SQL-операторы. Если текущий коэффициент отклика SQL превышает коэффициент базовой линии, составляющий 100%, тогда, значит, SQL-операторы выполняются медленнее, чем “обычно”. Низкий процент отклика в диаграмме SQL Response Time свидетельствует о том, что обработка SQL-операторов в экземпляре происходит неэффективно.


На заметку! В базах данных версий, предшествующих Oracle Database 10g, может понадобиться настроить определенные вещи для того, чтобы метрические показатели активности отображались в диаграмме SQL Response Time. Для этого используется мастер Database Configuration, вызвать который можно, щелкнув на кнопке Configure (Настройка) напротив SQL Activity Monitoring (Мониторинг активности SQL) в разделе Diagnostic Summary (Диагностическая сводка).


 

Использование данных анализа ADDM в разделе Performance Analysis

В разделе Performance Analysis (Анализ производительности) домашней страницы Database Control отображаются суммарные данные самого недавнего анализа ADDM.

На рис. 3 показано, как выглядит этот раздел. В этом разделе можно щелкать на любых полученных сведениях и тем самым анализировать любые связанные с производительностью проблемы более детально. Отчеты ADDM, в которых используются статистические данные AWR, позволяют быстро производить нисходящий анализ активности экземпляра.

Performance Analysis (Анализ производительности) в Database Control

Рис. 3. Performance Analysis (Анализ производительности) страницы Database Control

 

Использование страницы Database Performance

Страница Performance (Производительность) является, можно сказать, отправной точкой для проведения анализа производительности экземпляра. Она помогает делать следующие вещи.

  • Выполнять проверку на предмет наличия проблем как в базе данных, так и в системе.
  • Запускать процесс генерации отчета ASH для получения быстрого диагностического отчета по производительности на основании выборочных данных сеансов.
  • Быстро узнавать, какие узкие места существуют в системе.
  • Генерировать отчеты ADDM.
  • Переходить в режим Memory Access Mode (Режим доступа к памяти) в случае замедления или зависания системы.

 

Использование режима Memory Access Mode

Страницу Performance можно просматривать как в предлагаемом по умолчанию режиме SQL Access Mode (Режим доступа к SQL), так и в новом режиме Memory Access Mode. Режим SQL Access Mode подразумевает получение данных по производительности экземпляра за счет применения специальных SQL-операторов, которые по большей части выполняют запросы к динамическому представлению производительности V$. Однако, когда база данных работает чрезвычайно медленно или вообще зависла, применение режима SQL Access Mode накладывает на нее дополнительную нагрузку из-за необходимости дополнительно анализировать и выполнять SQL-операторы интерфейса OEM для диагностики производительности экземпляра. Если в экземпляре уже происходят интенсивные состязания за библиотечный кэш, попытка диагностировать проблему в таком режиме лишь усугубит ситуацию.

Поэтому для проведения диагностики в медленно работающих или зависших системах Oracle рекомендует переключаться в режим Memory Access Mode. При таком режиме база данных получает диагностические сведения прямо из SGA, используя более легкие системные вызовы, а не ресурсоемкие SQL-операторы, которые применяются при режиме SQL Access Mode. Благодаря тому, что в режиме Memory Access Mode выборка данных производится чаще, еще и снижается вероятность упущения событий, которые длятся короткое время. На рис. 4 показано, как можно переключаться в режим Memory Access Mode.

переключение в режим Memory Access Mode

Рис. 4. Переключение в режим Memory Access Mode

В следующих разделах рассматриваются основные диаграммы, отображаемые на странице Performance.

 

Диаграмма Host

Диаграмма Host (Хост) отражает проблемы, связанные с использованием ЦП. Если количество пользователей небольшое, а в этой диаграмме отображается длинная очередь выполнения, значит, пользователи базы данных, скорее всего, являются не главными виновниками высокого потребления ресурсов ЦП. В таком случае потребуется выяснить, что еще может работать в системе и потреблять ресурсы ЦП.

 

Диаграмма Average Active Sessions

Диаграмма Average Active Sessions (Средний объем активных сеансов) отражает имеющиеся в экземпляре проблемы с производительностью, уделяя основное внимание происходящим в экземпляре событиям ожидания. Она является ключевой на странице Performance и должна служить отправной точкой при выполнении анализа производительности с помощью OEM. На рис. 20.5 приведен пример того, как она может выглядеть. В этом примере видно, что она показывает, какие активные сеансы ожидают ресурсов ЦП, а какие ожидают событий.

Диаграмма Average Active Sessions

Для удобства диаграмма Average Active Sessions имеет цветовую кодировку. Зеленый цвет представляет тех пользователей, которые используют ресурсы ЦП, а остальные цвета — пользователей, которые ожидают различных событий, наподобие дискового ввода-вывода, блокировок или сетевых подключений. Определять, что в экземпляре происходит слишком много ожиданий, можно так: если уровень ожиданий в два раза превышает линию Max CPU (Максимальное использование ЦП), значит, в экземпляре возникает слишком много событий ожидания и потому его следует настроить.

Справа от диаграммы Average Active Sessions отображается классификация компонентов, оказывающих влияние на время длительности сеансов. Например, увидев в диаграмме, что больше всего ожиданий происходит из-за пользовательских операций ввода-вывода, можно щелкнуть в этой классификации на компоненте с соответствующим названием и узнать больше об этих ожиданиях. Над классификацией отображаются кнопки (см. рис. 20.5), на которых можно щелкать для запуска ADDM или получения отчета ASH.

Вдобавок можно щелкать на ссылке для перехода на страницу Top Activity (Наибольшая активность) и получать детали по тем сеансам, которые больше всех ответственны за происходящие в экземпляре ожидания в текущий момент. На рис. 6 показан пример того, как может выглядеть страница Top Activity в Database Control. Данные по активности базы отображаются в виде двух разделов: Top SQL (Самые интенсивные SQL-операторы) и Top Sessions (Самые активные сеансы). Из раздела Top SQL можно запускать советника SQL Tuning Advisor и получать рекомендации по настройке самых интенсивных SQL-операторов.

При наличии подозрений в том, что какой-то отдельный сеанс страдает от ожиданий, или при получении от определенных пользователей жалоб о том, что их сеансы выполняются слишком медленно, необходимо изучить страницу Top Sessions. Перейти на эту страницу можно, выполнив на странице Performance щелчок на ссылке Top Sessions в разделе Additional Monitoring Links (Дополнительные ссылки мониторинга). После попадания на страницу Top Sessions нужно щелкнуть на представляющем интерес имени пользователя и идентификаторе сеанса (SID) для отображения страницы Session Details (Детали сеанса) данного сеанса. Перейдя на вкладку Wait Event History (Хронология событий ожидания), можно легко выяснить природу последних ожиданий в этом сеансе. На рис. 7 показан пример страницы Session Details.

страница Top Activity в Database Control

Рис. 6. Страница Top Activity в Database Control

Рис. 7. Пример страницы Session Details

 

Страница Performance Data Report Page

Перейти на страницу Performance Data Report (Отчет по данным о производительности) можно, щелкнув на кнопке Create ASH Report (Создать отчет ASH) в разделе Average Active Sessions на домашней странице Performance в Database Control. Отчеты AWR хорошо подходят для анализа производительности экземпляра, но обычно подразумевают сбор данных за 30-минутные или часовые интервалы времени. Трех- или четырехминутный всплеск в производительности может запросто не попасть в агрегированный отчет AWR. Отчеты ASH предполагают выборку данных сеансов за недавний период времени.

После щелчка на кнопке Create ASH Report предлагается выбрать период времени, за который требуется создать отчет ASH. Выбираемый период не должен выходить за рамки последних семи дней, поскольку именно столько хранятся статистические данные ASH. Не следует забывать о том, что хранятся эти статистические данные ASH в репозитории AWR. На рис. 8 показан пример отчета ASH, созданного на основе представления V$ACTIVE_SESSION_HISTORY.

Отчет ASH по представлению V$ACTIVE_SESSION_HISTORY

Рис. 8. Отчет ASH по представлению V$ACTIVE_SESSION_HISTORY

Он представляет собой точно такой же отчет ASH, который можно создавать с помощью сценария ashrpt.sql. В нем содержится информация о следующих элементах:

  • самые интенсивные события (Top Events);
  • диаграмма загрузки (Load Profile);
  • самые интенсивные SQL-операторы (Top SQL);
  • самые активные сеансы (Top Sessions), в том числе и наиболее страдающие от блокировки (Top Blocking Sessions).
  • другие сущности, вызывающие в экземпляре состязания за ресурсы, а именно — самые интенсивно используемые объекты базы данных (Top Database Objects), самые интенсивно используемые файлы базы данных (Top Database Files) и самые интенсивно используемые защелки (Top Latches).
  • активность за определенный период времени (Activity Over Time).
« Prev
Next »
Войдите чтобы комментировать