Метрики базовой линии AWR используются для установки порогов для сигналов тревоги (Oracle alerts), что позволяет осуществлять мониторинг состояния базы данных Oracle. Эти пороги сообщают БД о том, когда следует выдавать сигнал из-за того, что определенная метрика достигла нежелательного значения. Для установки таких порогов необходимо знать, как сообщить, что определенное значение метрики имеет нежелательный уровень.
Базовая линия применяется для фиксации значения метрики за определенный период, а база данных устанавливает пороговые значения для различных метрик. Статическая базовая линия “вручную” вычисляет статистику значений метрик за некоторый период времени. Скользящее окно системы автоматически фиксирует статистику уровня метрики. Метрики базовой линии используются для вычисления пороговых значений сигнала. Доступны три разных метода для сравнения статистических показателей базовой линии с текущей активностью базы данных, что позволяет организовать эффективный мониторинг.
- Уровень важности. Пороги, основанные на уровне важности, используют статистический уровень для определения того, является ли текущий уровень метрики необычным. Например, если для критичного порога установлен уровень важности 0.99, то база данных выдаст сигнал тревоги, когда более 1% текущих значений метрик выходят за указанные пределы метрики.
- Процент от максимума. Это пороги, которые вычисляются на основе максимального значения, зафиксированного базовой линией.
- Фиксированные значения. Значения, установленные администратором баз данных и не зависящие от базовых линий.
Адаптивные пороги, которые используют базовые линии AWR в качестве источника статистических показателей метрик, являются идеальными для создания порогов тревоги. Как только вы выберете группу метрик, представляющих загрузку базы данных, эта база автоматически сконфигурирует и выявит адаптивные пороги, отталкиваясь от базовой линии SYSTEM_MOVING_WINDOW.
Управление сигналами тревоги
Наилучший способ управления сигналами тревоги в базе данных и связанными с ними метриками для мониторинга заключается в применении OEM Database Control. Для управления сигналами тревоги можно использовать пакет DBMS_SERVER_ALERT или же обращаться к очереди сигналов напрямую. Далее речь пойдет о генерируемых сервером по умолчанию сигналах и управлении ими.
Использование Database Control для управления сигналами
Oracle автоматически посылает сообщение сигнала в постоянно хранимую очередь по имени ALERT_QUE, а OEM читает эту очередь и посылает уведомления об отложенных сигналах сервера. Database Control (а равно и Grid Control) отображает сигналы тревоги и может также посылать уведомления о них по электронной почте или на пейджер.
Если вы использовали OEM в Oracle9i, то знакомы с сигналами диспетчера Enterprise Manager. Генерируемые сервером сигналы работают аналогично. В дополнение к отправке сообщений Oracle, теперь можно конфигурировать также и пороговые сигналы тревоги.
Установка порогов
Установить ваши собственные предупреждающие и критичные пороги мониторинга для любой метрики базы данных теперь очень легко. Для этого зайдите на домашнюю страницу Database Control и щелкните на ссылку Manage Metrics (Управление метриками), которая находится в группе Related Links (Связанные ссылки). На странице Manage Metrics щелкните на кнопке Edit Tresholds (Редактировать пороги). После этого отобразится страница Edit Tresholds (Редактирование порогов), показанная на рисунке ниже. Для каждой метрики на этой странице можно установить следующее.
- Предупреждающие и критичные пороги. Можно установить произвольный порог или вычислять его на основе набора показателей базовой линии. Например, можно специфицировать, что база данных должна генерировать пороговый сигнал, если использование определенного ресурса превысит его значение из базовой линии на 15%. Можно также задать несколько порогов.
- Ответное действие. Это действие может быть сценарием SQL или командой операционной системы. Oracle автоматически выполнит это ответное действие немедленно после генерации сигнала. Убедитесь, что предоставили полный путь к сценарию SQL или команде операционной системе, чтобы OEM Agent мог найти их.
Установка правил уведомления
Правила уведомления позволяют управлять условиями, при удовлетворении которых требуется получать сообщения от OEM. Например, вряд ли возникнет желание, чтобы вас будили в 2 часа ночи только потому, что табличное пространство, которому выделено 100 Гбайт пространства, достигло уровня заполнения в 80%. С другой стороны, вам наверняка нужно сразу узнать о том, что табличное пространство размером в 200 Мбайт пересекло уровень использования в 97%.
На странице Preferences (Предпочтения) в OEM Database Control можно определить правила уведомления. На домашней странице Database Control щелкните на ссылке Preferences (в самом низу страницы) и перейдите на страницу Preferences. Затем в разделе Notification (Уведомление) щелкните на ссылке Rules (Правила). Выберите любую метрику, вроде Listener Availability (Доступность слушателя), и щелкните на кнопке Edit (Редактировать). Здесь можно настроить правила уведомления для выбранного события.
Использование пакета DBMS_SERVER_ALERT для управления сигналами
Хотя интерфейс OEM Database Control предлагает очень легкий путь управления сигналами базы данных, могут быть случаи, когда понадобится объединить определенные изменения в программу PL/SQL. При этом для установки и модификации порогов различных метрик базы данных можно использовать поставляемый Oracle пакет DBMS_SERVER_ALERT. Этот пакет включает две главных процедуры: GET_TRESHOLD и SET_TRESHOLD.
Процедура GET_TRESHOLD служит для определения пороговых значений метрики базы данных. В листинге 1 ниже показана структура процедуры SET_TRESHOLD.
SQL> DESC DBMS_SERVER_ALERT.SET_THRESHOLD PROCEDURE dbms_server_alert.set_threshold Argument Name Type In/Out Default? ------------------------- -------------- --------- --------- METRICS_ID BINARY_INTEGER IN WARNING_OPERATOR BINARY_INTEGER IN WARNING_VALUE VARCHAR2 IN CRITICAL_OPERATOR BINARY_INTEGER IN CRITICAL_VALUE VARCHAR2 IN OBSERVATION_PERIOD BINARY_INTEGER IN CONSECUTIVE_OCCURRENCES BINARY_INTEGER IN INSTANCE_NAME VARCHAR2 IN OBJECT_TYPE BINARY_INTEGER IN OBJECT_NAME VARCHAR2 IN
Совет. Основанные на метриках сигналы отключаются установкой значений для предупреждающего и критичного порогов в NULL.
В процедуре SET_TRESHOLD, описанной в листинге 1 выше, WARNING_VALUE и CRITICAL_VALUE ссылаются на предупреждающие и критичные пороговые значения для выдачи сигналов. Чтобы узнать текущие предупреждающие и критичные пороговые значения метрики базы данных, применяется процедура DBMS_ALERT.GET_TRESHOLD.
Использование очереди сигналов напрямую
В дополнение к пакету DBMS_SERVER_ALERT можно также использовать процедуры из пакетов DBMS_AQ и DBMS_AQADM для прямого доступа и чтения сообщений в очереди сигналов. С помощью различных процедур пакета DBMS_AQADM можно подписываться на очереди сообщений, устанавливать пороги и отображать уведомления. Пакет DBMS_AQ позволяет управлять уведомлениями о предупреждениях. Подробную информацию ищите в документации Oracle. Помимо отображения сигналов на домашней странице базы данных, Database Control также будет отправлять сообщения электронной почты, извещая о сигналах, если вы укажете свой адрес через ссылку Setup (Настройка) в Database Control.
Проактивные сигналы табличного пространства
Все табличные пространства Oracle Database 11g имеют встроенные сигналы, которые уведомляют, что объем свободного пространства упал ниже установленного порога. Два порога по умолчанию — это критичный (critical) и предупреждающий (warning). Фоновый процесс MMON отслеживает свободное место в каждом табличном пространстве и при необходимости посылает соответствующие сигналы.
По умолчанию Oracle будет выдавать предупреждающий сигнал, когда табличное пространство окажется заполненным на 85% своей емкости, и критичный сигнал —когда будет достигнут уровень в 97% заполнения. Однако при желании этот механизм сигналов можно отключить. Чтобы увидеть информацию о пороговых значениях, обращайтесь к представлению DBA_TRESHOLD.
Совет. При переходе на Oracle Database 11g механизм сигналов о заполнении табличных пространств по умолчанию отключен. Если необходимо установить пороги сигналов, воспользуйтесь пакетом DBMS_SERVER_ALERT.
Приведем простой пример, демонстрирующий применение пакета DBMS_SERVER_ALERT для установки предупреждающего и критичного порогов, а также выдачи сигналов при пересечении этих порогов. Будет показано, как устанавливать, просматривать и очищать сигнал.
- Создайте маленькое табличное пространство для того, чтобы протестировать механизм сигналов тревоги Oracle:
SQL> CREATE TABLESPACE test DATAFILE 'test01.dbf' size 10M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 3M; Tablespace created.
- Установите пороги сигналов табличного пространства, как показано ниже (предупреждающий сигнал при заполнении на 80% и критичный — при заполнении на 95%):
SQL> EXECUTE DBMS_SERVER_ALERT.SET_THRESHOLD(- > dbms_server_alert.tablespace_pct_full,dbms_server_alert.operator_ge,'80',- > dbms_server_alert.operator_ge,'95',1,1,null,- > dbms_server_alert.object_type_tablespace,'TEST'); PL/SQL procedure successfully completed. SQL>
- Создайте новую таблицу, используя следующий оператор SQL. (Это отключит сигнал, поскольку конструкция MINEXTENTS 3 для новой таблицы заставит табличное пространство пересечь уровень предупреждающего порога в 80% заполнения.)
SQL> CREATE TABLE test_table (name varchar2(30)) TABLESPACE test STORAGE (MINEXTENTS 3); Table created. SQL>
- Проверить сигнал табличного пространства можно, как показано ниже (хотя вы и не увидите его немедленно, потому что процесс MMON должен сначала собрать необходимую информацию для сигнала):
SQL> SELECT reason FROM dba_outstanding_alerts; REASON -------------------------------------- Tablespace [TEST] is [88 percent] full SQL>
- Можете очистить сигнал, увеличив размер файла данных, который является частью табличного пространства, и посмотреть, что случится с сигналом, запросив представление DBA_OUTSTANDING_ALERTS. Вы увидите, что сигнал пропал из представления, поскольку был очищен:
SQL> ALTER TABLESPACE test ADD DATAFILE 'test02.dbf' size 5M; Tablespace altered. SQL> SQL> SELECT reason FROM dba_outstanding_alerts; no rows selected SQL>
- Все очищенные сигналы будут показаны в представлении DBA_ALERT_HISTORY. Удостовериться в том, что сигнал табличного пространства очищен, можно с помощью следующего запроса:
SQL> SELECT reason, resolution FROM dba_alert_history; REASON RESOLUTION -------------------------------------- ----------- Tablespace [TEST] is [88 percent] full cleared SQL>
Использование для целей мониторинга журналов сигналов и файлов трассировки
Для отслеживания ошибок можно использовать журнал сигналов (alert log) и файлы трассировки. Сервер и фоновые процессы записывают информацию об ошибках в файлы трассировки, которые применяются службой поддержки Oracle для оказания помощи в решении проблем. Журнал сигналов содержит информационные сообщения, такие как сообщения об обработке операторов запуска и останова системы, а также операторов создания табличных пространств. Вдобавок журнал сигналов содержит сообщения о внутренних ошибках и повреждениях.
Если необходимо исследовать ошибки фонового процесса, нужно проверить журнал сигналов и файлы трассировки экземпляра. Например, когда процесс-писатель журналов не может выполнить запись в группу журнала, он создает трассировочный файл и одновременно помещает сообщение в журнал сигналов.
Управлением размерами индивидуальных трассировочных файлов осуществляется за счет установки параметра инициализации MAX_DUMP_FILE_SIZE. База данных добавляет новые данные к журналу сигналов. Можно периодически копировать и перемещать журнал сигналов на ленту и удалять его после достижения определенного размера. База данных автоматически создаст новый журнал сигналов вместо удаленного.
Представления словаря данных, касающиеся метрик и сигналов
Есть несколько представлений словаря данных, которые дают информацию о метриках и сигналах базы данных. Ранее в блогах же упоминались представления V$SYSMETRIC, V$SERVICEMETRIC и V$SYSMETRIC_HISTORY. Ниже перечислены некоторые другие ключевые представления.
- V$METRICNAME показывает отображение имен метрик на их идентификаторы.
- V$ALERT_TYPES отображает информацию о типах серверных сигналов.
- DBA_HIST_SYMETRIC_HISTORY содержит снимки V$SYSMETRIC_HISTORY.
- DBA_ALERT_HISTORY предоставляет хронологию уже отправленных сигналов, т.е. сигналов, которые были обработаны.
- DBA_OUTSTANDING_ALERTS содержит все пороговые сигналы, которые пока ждут своей очереди на обработку.
- DBA_THRESHOLDS показывает имена, а также предупреждающие и критичные пороговые значения, установленные в базе данных.
В последующих разделах несколько важнейших представлений рассматриваются более подробно.
V$ALERT_TYPES
Представление V$ALERT_TYPES предоставляет информацию обо всех типах сигналов системы. Ниже описаны его столбцы, достойные упоминания.
STATE — хранит два возможных значения: stateful (с состоянием) или stateless (без состояния). Сигналы с состоянием — это те, что автоматически очищаются вместе с очисткой порога, вызвавшего их. База данных рассматривает все сигналы, не связанные с порогами, как сигналы без состояния. Сигнал с состоянием сначала появляется в представлении DBA_OUTSTANDING_ALERTS и после очистки попадает в представление DBA_ALERT_HISTORY. Сигнал без состояния сразу поступает в DBA_ALERT_HISTORY.
- SCOPE — классифицирует сигналы, как относящиеся к уровню базы данных (database-wide) и относящиеся к уровню экземпляра (instance-wide).
- GROUP_NAME — Oracle собирает различные сигналы базы данных в группы: пространства, производительности и конфигурации.
DBA_TRESHOLDS
Представление DBA_TRESHOLDS содержит текущие установки порогов для генерации сигналов. Это представление удобно, когда необходимо увидеть текущую установку порога для любого сигнала:
SQL> SELECT metrics_name, warning_value, critical_value, consecutive_occurrences FROM DBA_THRESHOLDS WHERE metrics_name LIKE '%CPU Time%';
Совет. Если вы получаете сигнал типа “устаревший снимок”, может понадобиться увеличить размер пространства отмены. В дополнение, возможно, стоит рассмотреть вопрос увеличения длительности периода хранения данных отмены. Обратите внимание, что за любой 24-часовой период будет получен максимум один сигнал, связанный с отменой.
