Oracle ADDM - автоматическая диагностика базы данных через монитор

 ADDM - монитор диагностики базы данных OracleВ Oracle подчеркивают, что сервер Oracle Database 11g и 12c до такой степени автоматизирует управление, что его можно назвать самоуправляемой (self-managing) базой данных. Как минимум, отчасти это правда, поскольку ряд традиционных трудоемких и чреватых ошибками задач теперь заменены новыми способами управления памятью, транзакциями и ресурсами, а также организации пространства. Вдобавок подверглись усовершенствованию приемы резервирование и восстановления. Однако роль администратора баз данных осталась столь же существенной, как и прежде. Более того, эта роль стала даже еще более важной, поскольку новые средства добавили сложности.

 

Автоматическое управление и онлайновые средства

В этом блоге мы обсудим операционные аспекты работы базы данных Oracle. Несколько компонентов базы требуют постоянного наблюдения и модификаций, и в этой статье вы подробно узнаете о некоторых важнейших средствах управления базой данных Oracle Database 11g и 12c. В некоторых статьях наших блогов частично упоминались темы, которые будут подняты здесь, и настоящая статья свяжет вместе все разнообразные аспекты Oracle Database 11g и 12c, которые облегчают жизнь администратору базы данных. Эта статья охватит две основные области: средства автоматического управления базой данных и онлайновые средства управления.

В версии Oracle Database 11g и 12c появилось революционное средство автоматического управления хранилищем — Automatic Storage Management (ASM), которое помогает Oracle администраторам баз данных управлять дисковым хранилищем с помощью встроенного диспетчера логических томов — Logical Volume Manager (LVM), не требующего участия администратора. Автоматическое управление разделяемой памятью — полезное средство, которое существенно поможет в ежедневном администрировании. Средство онлайнового переопределения таблиц поможет выполнять несколько рутинных задач в онлайновом режиме, без ограничения доступности базы данных. Более того, управляемые Oracle файлы (Oracle Managed Files — OMF) помогут сократить объем задач управления файлами базы данных. В последующих разделах вы узнаете, как эти новые средства облегчают ежедневное управление базой данных Oracle.

 

Автоматический монитор диагностики базы данных 

Традиционно предприятиям приходилось прилагать серьезные усилия для тонкой настройки производительности. Oracle Database 11g предоставляет в ваше распоряжение мощные и точные автоматические средства настройки производительности. В основе этой функциональности лежит новое средство сбора статистики — Automatic Workload Repository (AWR — автоматический репозиторий рабочей нагрузки), который автоматически собирает и сохраняет важнейшую статистику производительности (включая операторы SQL, использующие максимум ресурсов в базе данных), чтобы помочь в обнаружении проблем производительности и автоматической настройке базы данных. AWR сохраняет свои данные в табличном пространстве Sysaux

Вместо запуска множества SQL-сценариев настройки производительности вы просто обращаетесь к автоматическому диагностическому монитору базы данных ( Automatic Database Diagnostic Monitor — ADDM) как к начальной точке всей работы, связанной с настройкой производительности. Поскольку ADDM и выявляет проблемы, и выдает рекомендации в соответствии с ключевой временной статистикой БД (подробнее об этом будет сказано ниже), у вас есть способ количественно оценить эффективность различных мер повышения производительности.


На заметку! В Oracle рекомендуют полагаться на AWR во всем, что касается данных о производительности, необходимых для настройки базы.


Выполняя автоматический анализ данных по производительности, ADDM помогает нести ответственность за своевременное выявление проблем для сбора статистики. По умолчанию AWR собирает новую статистику производительности в форме ежечасных снимков (snapshot) и сохраняет эти снимки в течение восьми дней, прежде чем очистить. Снимок AWR представляет собой коллекцию статистики базы данных на определенный момент времени, включая статистику ресурсоемких операторов SQL. Каждый раз, когда AWR делает новый снимок, ADDM автоматически запускается, выполняет нисходящий анализ системы и сообщает о своих обнаружениях на домашней странице Database Control. Вывод ADDM состоит из описания каждой обнаруженной проблемы производительности, вместе с рекомендациями по ее разрешению. Рекомендации упорядочены по ожидаемому эффекту от их реализации. Увидеть регулярные отчеты ADDM можно в интерфейсе OEM Database Control или же просматривать их в сеансе SQL*Plus с помощью поставляемого Oracle SQL-сценария.

ADDM запускается автоматически, однако этот инструмент можно также запустить вручную, чтобы исследовать проблемы, возникшие между плановыми запусками. Oracle сохраняет результаты анализа ADDM в табличном пространстве Sysaux.

 

Предназначение ADDM

Основное предназначение ADDM состоит в сокращении ключевого показателя базы данных, именуемого временем БД (DB time) в микросекундах, которое тратит база данных на действительную обработку пользовательских запросов.

Время БД включает общий объем времени, потраченного на вызовы базы данных (на уровне пользователя), игнорируя время, потраченное на фоновую обработку. Время БД включает как время ожидания, так и время обработки (время ЦП), но не включает время простоя, связанное с вашей работой. Например, если в течение часа вы были подключены к базе данных, но 58 минут из них простаивали, то время БД составит только 2 минуты.

Если проблема приводит к непропорциональным или чрезмерным затратам времени БД, то ADDM автоматически помечает ее как требующую внимания. Если есть проблема в системе, но она не влияет существенно на время БД, то ADDM просто игнорирует ее. Таким образом, монитор ADDM сосредоточен на единственной цели — сократить время БД. Инструмент ADDM нацелен на повышение пропускной способности базы данных, что позволит обслужить больше пользователей тем же объемом ресурсов.

 

Проблемы, диагностируемые ADDM

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

  • Дорогостоящие операторы SQL.
  • Проблемы производительности ввода-вывода.
  • Проблемы блокировок и параллелизма.
  • Избыточный разбор.
  • Узкие места в ресурсах, включая память и время ЦП.
  • Мелкие выделения памяти.
  • Проблемы управления подключениями вроде чрезмерной активности входов и выходов.

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

  • Экспертная диагностика проблем.
  • Коренная причина проблемы, а не просто симптомы.
  • Упорядоченный список эффектов от проблем.
  • Рекомендации, выстроенные в порядке убывания ожидаемого выигрыша.

В отличие от выполнения некоторых сложных SQL-сценариев, отчеты ADDM несут с собой минимум накладных расходов, поскольку их исходные данные уже сохранены AWR.

ADDM использует в Oracle Database 11g развитые статистические методы временной модели, которые чрезвычайно эффективно определяют, где именно база данных тратит максимум времени. Эти новые временные статистические методы позволяют Oracle сосредоточиться только на наиболее критичных проблемах производительности. Если некоторая проблема пересекает пороговое значение показателя времени БД, то ADDM перемещает ее в вершину списка проблем производительности; в противном случае она остается в непроблемной области. Давайте рассмотрим в следующем разделе эти новые статистические методы временной модели.

 

Статистика временной модели

ADDM основывает большинство своих рекомендаций относительно производительности на статистике временной модели (time-model statistics), наиболее важной частью которой является новая статистика времени БД, о которой мы упомянули выше, в разделе “Предназначение ADDM”. Статистика временной модели представляет собой универсальный способ количественной оценки различных операций базы данных. В дополнение к времени БД существуют и другие временные статистические показатели, такие как время, потраченное на статистику входа (logon statistrics), а также полный и частичный разбор.

Для просмотра временной статистики производительности можно использовать новые представления V$SESS_TIME_MODEL и V$SYS_TIME_MODEL. Представление V$SYS_TIME_MODEL выдает накопленную временную статистику о различных операциях во всей базе данных и показывает количество миллисекунд, потраченных базой данных на определенные операции. Запрос в листинге 1 демонстрирует разновидность операций, для которых представление V$SYS_TIME_MODEL содержит временную статистику.


SQL> SELECT stat_name, value FROM v$sys_time_model;
STAT_NAME VALUE
------------------------------------------------- ----------
DB time 3.8422E+13
время БД 3.8422E+13
DB CPU 9.2726E+12
время ЦП 9.2726E+12
background elaps 2.7506E+12
потраченное фоновое время 2.7506E+12
background cpu time 1.3335E+11
потраченное фоновое время ЦП 1.3335E+11
sequence load elapsed ti 6583934097
потраченное время на последовательную загрузку 6583934097
parse time elapse 3.0984E+11
потраченное время на разбор 3.0984E+11
hard parse elapsed time 4.7280E+10
потраченное время на полный разбор 4.7280E+10
sql execute elapsed time 3.7533E+13
потраченное время на выполнение sql 3.7533E+13
connection management call elapsed time 4.3565E+10
потраченное время на управление подключениями 4.3565E+10
failed parse elapsed time 3350540297
потраченное время на неудачный разбор 3350540297
failed parse (out of shared memory) elapsed time 0
потраченное время на неудачный разбор
(нехватка разделяемой памяти) 0
hard parse (sharing criteria) elapsed time 1770964950
потраченное время на полный разбор
(критерий разделения) 1770964950
hard parse (bind mismatch) elapsed time 706518501
потраченное время на полный разбор
(несовпадение привязок) 706518501
PL/SQL execution elapsed time 7.0339E+11
потраченное время на выполнение PL/SQL 7.0339E+11
inbound PL/SQL rpc elapsed time 7.3869E+12
потраченное время на входящие rpc-вызовы PL/SQL 7.3869E+12
PL/SQL compilation elapsed time 3667675394
потраченное время на компиляцию PL/SQL 3667675394
Java execution elapsed time 1.7993E+11
потраченное время на выполнение Java 1.7993E+11
RMAN cpu time (backup/restore) 0
время ЦП RMAN (резервное копирование/восстановление) 0
17 rows selected.
SQL>

Представление V$SESS_TIME_MODEL подобно представлению V$SYS_TIME_MODEL и дает временную статистику тех же типов, но показывает накопленное время сеанса для различных операций вместо информации обо всей базе данных.

AWR собирает статистику временной модели как часть своих ежедневных снимков. В дополнение AWR собирает статистику объектов, включая статистику их использования, статистику системы и сеанса, статистику высоконагруженных операторов SQL, а также хронологию активности последнего сеанса, именуемую Active Session History (ASH). 

 

Обнаружения (findings) ADDM

Результаты анализа ADDM доступны в форме последовательности обнаружений (findings), которые делятся на три типа: проблема, симптом и информационное. Вот пример:

FINDING 1: 45% impact (11223 seconds)
------------------------------------
SQL statements were not shared due to the usage of literals.
This resulted in additional hard parses which were consuming
significant database time.
ОБНАРУЖЕНИЕ 1: 45% влияния (11223 секунд)
------------------------------------
Операторы SQL не разделены из-за использования литералов.
Это приведет к дополнительным полным разборам, которые отнимут
значительное время базы данных.

Это обнаружение проблемы, потому что сопровождается оценкой влияния (impact), которая измеряется объемом дополнительного времени БД, вызванного проблемой.

Обнаружения представлены в порядке убывания важности (определяемой процентом влияния), и сумма процентов влияния может превышать 100%, как видно в следующем примере: 

FINDING 1: 34% impact (289378 seconds)
FINDING 2: 25% impact (214227 seconds)
FINDING 3: 23% impact (193521 seconds)
FINDING 4: 16% impact (134639 seconds)
FINDING 5: 6.1% impact (51563 seconds)
FINDING 6: 2.1% impact (17753 seconds)

Сумма процентов влияния может превышать 100% времени БД, так как проблемы производительности, связанные с различными обнаружениями, могут перекрываться, и потому составлять одну и ту же часть времени БД.

 

диагностика производительности базы данных Oracle через монитор ADDM

Рекомендации ADDM по повышению производительности и решению проблем

Обычно ADDM в своем анализе предлагает одну или более рекомендаций для каждого обнаружения проблемы. Следовать всем рекомендациям для решения проблемы не обязательно. Каждая рекомендация сопровождается количественной выгодой (benefit), которая должна сопровождать выполнение рекомендации ADDM и измеряется в прогнозируемом сокращении времени БД.

Вот типичная рекомендация ADDM, где предлагается провести анализ логики приложения: 

RECOMMENDATION 1: Application Analysis, 45% benefit (11223 seconds)
РЕКОМЕНДАЦИЯ 1: анализ приложения, 45% выгода (11223 секунд)

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

FINDING 1: 34% impact (289378 seconds)
ОБНАРУЖЕНИЕ 1: 34% влияния (289378 секунд)

Отчет начинается с обнаружения, имеющего 34% влияние на время БД. Это обнаружение сопровождается следующими пятью рекомендациями, каждая со своим ожидаемым выигрышем. Если вы просуммируете выигрыш (в процентах), который является результатом всех пяти рекомендаций, то заметите, что результат будет равен общему влиянию обнаружения (34%): 

RECOMMENDATION 1: Segment Tuning, 13% benefit (112768 seconds)
РЕКОМЕНДАЦИЯ 1: настройка сегментов, 13% выгода (112768 секунд)
RECOMMENDATION 2: Segment Tuning, 6.7% benefit (56805 seconds)
RECOMMENDATION 3: Segment Tuning, 6.1% benefit (51882 seconds)
RECOMMENDATION 4: Segment Tuning, 4.4% benefit (37330 seconds)
RECOMMENDATION 5: Segment Tuning, 3.6% benefit (30594 seconds)

Рекомендации ADDM могут включать следующее.

  • Аппаратные изменения. ADDM может порекомендовать добавить дополнительные процессоры в систему или внести изменения в способ настройки подсистемы ввода-вывода.
  • Изменения базы данных Oracle и приложения. В некоторых случаях, вместо переписывания кода приложения, ADDM может порекомендовать изменить установки некоторых параметров инициализации.
  • Изменения в конфигурации пространства. ADDM может иногда выдать важные (major) рекомендации, вроде использования нового средства Automatic Storage Management для решения некоторых проблем с производительностью.
  • Использование советников производительности. В некоторых случаях ADDM порекомендует воспользоваться советником по производительности, такой как SQL Tuning Advisor или Segment Advisor, чтобы решить существующие проблемы с производительностью.

Рекомендации также могут включать компоненты действий (action) и обоснований (rationale), причем действия показывают различные вещи, которые нужно предпринять для реализации рекомендации, а обоснования детализируют причину рекомендации. Вот часть отчета ADDM, показывающего действие и обоснование для рекомендации, которую вы видели выше в настоящем разделе:

ACTION: Investigate application logic for possible use of bind variables
instead of literals. Alternatively, you may set the parameter
"cursor_sharing" to "force".
RATIONALE: SQL statements with PLAN_HASH_VALUE 2094286255 were found to be
using literals. Look in V$SQL for examples of such SQL statements.
ДЕЙСТВИЕ: Исследуйте логику приложения для возможного использования переменных
привязки вместо литералов. В качестве альтернативы можно установить параметр
cursor_sharing в force.
ОБОСНОВАНИЕ: Найдены операторы SQL с PLAN_HASH_VALUE, равным 2094286255, которые
используют литералы. Обратитесь к V$SQL за примерами таких операторов SQL.

Обратите внимание, что к рекомендации может быть прикреплено одно или более действий. Аналогично, можно получить также одно или более обоснований.

 

Управление ADDM

Oracle управляет ADDM с помощью фонового процесса MMON. Всякий раз, когда AWR делает снимок (по умолчанию ежечасно), процесс MMON указывает ADDM проанализировать интервал между последними двумя снимками AWR. Таким образом, по умолчанию ADDM автоматически запускается каждый раз, когда AWR делает снимок. Как упоминалось ранее, для просмотра аналитики ADDM и рекомендаций относительно действий можно использовать OEM Database Control.

 

Конфигурирование ADDM

Oracle включает средство ADDM по умолчанию, и ваша единственная задача — удостовериться, что параметр инициализации STATISTICS_LEVEL установлен в TYPICAL или ALL, чтобы AWR собирал свою статистику производительности. При установке STATISTICS_LEVEL в BASIC все равно можно будет пользоваться AWR для сбора статистики посредством пакета DBMS_WORKLOAD_REPOSITORY, но нельзя собирать некоторые важные типы статистических показателей производительности.

Управлять объемом собираемой AWR статистики можно, настраивая одну или обе описанных ниже переменных.

  • Snapshot interval (интервал между снимками). По умолчанию этот интервал составляет 60 минут. Oracle предполагает, что ежечасные снимки — достаточно часты для диагностики и недостаточно часты, чтобы существенно повлиять на производительность.
  • Snapshot retention period (период хранения снимков). По умолчанию Oracle хранит все снимки в AWR в течение восьми дней, после чего отбрасывает устаревшие.

Изменить интервал снимков и длительность их хранения можно с помощью параметров INTERVAL и RETENTION процедуры MODIFY_SNAPSHOT_SETTINGS из пакета DBMS_WORKLOAD_REPOSITORY


На заметку! Монитор ADDM запускается автоматически после получения каждого снимка AWR, и его можно запускать в любой момент по своему выбору, например, когда сигнал тревоги рекомендует это сделать. Его также можно запустить вручную, когда нужно провести анализ ADDM по множеству снимков, а не по одному или двум последним, что является интервалом анализа по умолчанию.


Oracle автоматически запускает ADDM после того, как AWR сделает снимок, однако можно также получить специальные отчеты ADDM, запустив его вручную, если необходимо проверить, например, период между 8 часами вечера и 5 часами утра, включающий несколько снимков AWR. Нужно просто указать информацию о начальном и конечном снимках, и ADDM сгенерирует отчет за указанный период.

 

Конфигурирование ADDM под RAC

В случае использования Oracle Real Application Clusters (RAC) запускать ADDM можно в нескольких режимах:

  • режим базы данных — анализирует все экземпляры RAC;
  • режим экземпляра — анализирует единственный экземпляр RAC;
  • частичный режим — анализирует подмножество экземпляров RAC.

Разумеется, в базе данных одного экземпляра доступен только режим анализа экземпляра. В режиме базы данных ADDM анализирует производительность всех экземпляров базы данных. Он рассматривает время БД для базы данных как сумму всех времен БД по всем экземплярам. Отчет об анализе базы данных показывает обнаружения уровня экземпляра, если они затрагивают весь экземпляр. Таким образом, если единственный экземпляр вызвал значительную загрузку процессора, это можно обнаружить в аналитическом отчете по базе данных Oracle.

 

Включение ADDM

По умолчанию средство ADDM включено. Управление выполнением ADDM осуществляется спецификацией инициализационных параметров CONTROL_MANAGEMENT_PACK_ACCESS и STATISTICS_LEVEL. Для включения ADDM потребуется установить параметр CONTROL_MANAGEMENT_PACK_ACCESS либо в DIAGNOSTIC, либо в DIAGNOSTIC+TUNING. Поскольку значение по умолчанию этого параметра равно DIAGNOSTIC+TUNING, ADDM по умолчанию включен. Отключается ADDM установкой этого параметра следующим образом: 

CONTROL_MANAGEMENT_PACK_ACCESS=NONE

 

Три режима ADDM

сейчас мы покажем, как запускать ADDM в трех режимах, описанных ранее. Запустите процедуру DBMS_ADDM.ANALYZE_DB, чтобы запустить ADDM в режиме базы данных:

BEGIN
DBMS_ADDM.ANALYZE_DB (
task_name IN OUT VARCHAR2,
begin_snapshot IN NUMBER,
end_snapshot IN NUMBER,
db_id IN NUMBER := NULL);
END;
/

Значения параметров BEGIN_SNAPSHOT и END_SNAPSHOT определяют границы анализа ADDM. Параметр DB_ID не обязателен, и по умолчанию установлен в идентификатор DBID базы данных, к которой вы подключены.

В следующем примере показано, как выполнить анализ ADDM для базы данных за период между снимками 99 и 120: 

VAR tname VARCHAR2(30);
BEGIN
:tname := 'ADDM for 8 AM to 10 AM'';
DBMS_ADDM.ANALYZE_DB(:tname, 99,120);
END;
/

Запустить ADDM в режиме экземпляра можно с помощью процедуры ANALYZE_INST, как показано ниже:

BEGIN
DBMS_ADDM.ANALYZE_INST (
task_name IN OUT VARCHAR2,
begin_snapshot IN NUMBER,
end_snapshot IN NUMBER,
instance_number IN NUMBER := NULL,
db_id IN NUMBER := NULL);
END;
/ 

Обратите внимание на параметр INSTANCE_NUMBER, который позволяет специфицировать номер экземпляра. Вот пример, показывающий, как задавать разные обязательные параметры: 

VAR tname VARCHAR2(30);
BEGIN
:tname := 'my ADDM for 8 AM to 10 AM';
DBMS_ADDM.ANALYZE_INST(:tname, 99,120, 1);
END;
/

Чтобы запустить ADDM в частичном режиме, понадобится выполнить процедуру ANALYZE_PARTIAL:

BEGIN
DBMS_ADDM.ANALYZE_PARTIAL (
task_name IN OUT VARCHAR2,
instance_numbers IN VARCHAR2,
begin_snapshot IN NUMBER,
end_snapshot IN NUMBER,
db_id IN NUMBER := NULL);
END;
/ 

А вот пример, демонстрирующий запуск частичного анализа ADDM для четырех экземпляров базы данных:

VAR tname VARCHAR2(30);
BEGIN'
:tname := 'my ADDM for 8 AM to 10 AM';
DBMS_ADDM.ANALYZE_PARTIAL(:tname, '1,2,3,4', 99, 101);
END;
/ 

В этом примере ADDM запускается для экземпляров 1, 2, 3 и 4 между снимками 99 и 101.

 

Отображение отчета ADDM

Выполните функцию GET_REPORT для просмотра текстового отчета о завершенной задаче ADDM, как показано ниже: 

SET LONG 1000000 PAGESIZE 0;
SELECT DBMS_ADDM.GET_REPORT(:tname) FROM DUAL;

 

Определение оптимальной производительности ввода-вывода

Если система ввода-вывода работает на определенной скорости, чтение блока базы данных может производиться за определенное количество миллисекунд; параметр DBIO_EXPECTED (который не является параметром инициализации) показывает производительность ввода-вывода, и его значение по умолчанию составляет 10 миллисекунд.

Узнать текущее значение параметра DBIO_EXPECTED можно, опросив представление DBA_ADVISOR_DEF_PARAMETERS следующим образом:

SQL> SELECT parameter_value
FROM dba_advisor_def_parameters
WHERE advisor_name='ADDM'
AND parameter_name='DBIO_EXPECTED';
PARAMETER_VALUE
---------------
10000
SQL>

С помощью процедуры SET_DEFAULT_TASK_PARAMETER пакета DBMS_ADVISOR значение по умолчанию параметра DBIO_EXPECTED можно изменить:

SQL> SHO USER
USER is "SYS"
SQL> EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(-
> 'ADDM', 'DBIO_EXPECTED', 6000);
PL/SQL procedure successfully completed.
SQL> 

 

Запуск ADDM

Фоновый процесс Oracle MMON планирует запуск ADDM каждый раз, когда AWR собирает свои последние снимки. Таким образом, на протяжении дня Oracle автоматически генерирует отчеты ADDM, которые можно просмотреть через Database Control.

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

Также можно запросить у ADDM выполнение анализа производительности последнего экземпляра, просматривая данные снимка AWR, которые попадают между двумя несоседними снимками. Единственными требованиями относительно выбора снимков AWR являются следующие.

  • Снимки не должны содержать ошибок.
  • Между двумя снимками не должно происходить останова базы данных. AWR хранит только накопленную статистику базы данных, и как только вы остановите базу данных, все накопленные данные утратят свое значение.

На заметку! Хотя сценарий addmrpt.sql показывает, что можно специфицировать количество дней снимков, на самом деле такого выбора нет. Сценарий только перечисляет три последних дня завершенных снимков, как видно из следующего вывода:

Specify the number of days of snapshots to choose from
Укажите количество дней для снимков
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing  without
specifying a number lists all completed snapshots.
Ввод количества дней (n) приведет к выводу самых последних (n) дней для снимков.
Нажатие  без ввода числа приведет в выводу всех завершенных снимков.
Listing the last 3 days of Completed Snapshots
Список трех последних дней завершенных снимков 

 

Просмотр детализированных отчетов ADDM

Просматривать аналитические отчеты ADDM можно тремя разными способами.

  • Применить поставляемый Oracle сценарий addmrpt.sql (находящийся в каталоге $ORACLE_HOME/rdbms/admin) для создания внеочередного отчета ADDM за период времени, покрытый любой парой снимков.
  • Воспользоваться пакетом DBMS_ADVISOR и создать отчет ADDM вызовом процедуры CREATE_REPORT.
  • Использовать OEM для просмотра обнаружений о производительности хранимых отчетов ADDM, которые упреждающе создаются каждый час после снимков AWR.

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

 

Чтение отчета ADDM

ADDM представляет результаты своих анализов в стандартном формате, состоящем их следующих компонентов:

  • определение проблемы производительности;
  • корневая причина проблемы производительности;
  • рекомендации по разрешению проблемы;
  • обоснование предложенных рекомендаций.

В листинге 2 показана сжатая версия отчета ADDM. 


DETAILED ADDM REPORT FOR TASK 'TASK_4028' WITH ID 4028
Analysis Period: 01-JUL-2008 from 06:00:11 to 21:00:37
Database ID/Instance: 866170026/1
Database/Instance Names: FINANCE/finance
Host Name: prod5
Database Version: 11.1.0.0.0
Snapshot Range: from 3068 to 3076
Database Time: 687974 seconds
Average Database Load: 23.9 active sessions
FINDING 1: 42% impact (287205 seconds)
Individual database segments responsible for significant physical I/O were found.
RECOMMENDATION 1: Segment Tuning, 15% benefit (102631 seconds)
ACTION: Run "Segment Advisor" on TABLE "FIN.UNIT_REGISTR" with object id 1817.
RELEVANT OBJECT: database object with id 1817
ACTION: Investigate application logic involving I/O
on TABLE "FIN.UNIT_REGIST" with object id 1817.
RELEVANT OBJECT: database object with id 1817
RATIONALE: The SQL statement with SQL_ID "dvycj85pfmb1b" spent
significant time waiting for User I/O on the hot object.
RELEVANT OBJECT: SQL statement with SQL_ID dvycj85pfmb1b
UPDATE UNIT_REGISTR UR SET UR.CARD_PRINTED_FLAG = 'Y'
. . .
RECOMMENDATION 2: Segment Tuning, 6.7% benefit (56805 seconds)
ACTION: Run "Segment Advisor" on TABLE "APPOWNER.CAMP_POS" with object id 1381.
RELEVANT OBJECT: database object with id 1381
ACTION: Investigate application logic involving I/O on TABLE
"APPOWNER.CAMP_POS" with object id 1381.
RELEVANT OBJECT: database object with id 1381
RATIONALE: The SQL statement with SQL_ID "gfjfc1g8t2a64" spent
. . .
FINDING 2: 29% impact (202802 seconds)
Individual database segments responsible for significant user I/O wait were found.
RECOMMENDATION 1: Segment Tuning, 12% benefit (84451 seconds)
ACTION: Run "Segment Advisor" on TABLE "APPOWNER.COM_ORGS" with object id 1412.
RELEVANT OBJECT: database object with id 1412
ACTION: Investigate application logic involving I/O on TABLE
"APPOWNER.COM_ORGS" with object id 1412.
RELEVANT OBJECT: database object with id 1412
FINDING 3: 23% impact (160643 seconds)
The buffer cache was undersized causing significant additional read I/O.
RECOMMENDATION 1: DB Configuration, 23% benefit (160643 seconds)
ACTION: Increase SGA target size by increasing the value of
parameter "sga_target" by 2128 M.
SYMPTOMS THAT LED TO THE FINDING: Wait class "User I/O" was consuming
significant database time.
FINDING 4: 16% impact (134639 seconds)
SQL statements consuming significant database time were found.
RECOMMENDATION 1: SQL Tuning, 4.9% benefit (41134 seconds)
ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
"dvycj85pfmb1b".
FINDING 5: 6.1% impact (51563 seconds)
The throughput of the I/O subsystem was significantly lower than expected.
RECOMMENDATION 1: Host Configuration, 6.1% benefit (51563 seconds)
ACTION: Consider increasing the throughput of the I/O subsystem.
Oracle's recommended solution is to stripe all data file using the
SAME methodology. You might also need to increase the number of disks
for better performance. Alternatively, consider using Oracle's
Automatic Storage Management solution.
SYMPTOMS THAT LED TO THE FINDING:
Wait class "User I/O" was consuming significant database time. (71%
impact [604143 seconds])
. . .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ADDITIONAL INFORMATION
----------------------
Wait class "Administrative" was not consuming significant database time.
Wait class "Application" was not consuming significant database time.
Wait class "Cluster" was not consuming significant database time.
Wait class "Commit" was not consuming significant database time.
Wait class "Configuration" was not consuming significant database time.
CPU was not a bottleneck for the instance.
Wait class "Network" was not consuming significant database time.
Wait class "Scheduler" was not consuming significant database time.
Wait class "Other" was not consuming significant database time.
The analysis of I/O performance is based on the default assumption that the
average read time for one database block is 10000 micro-seconds.
An explanation of the terminology used in this report is available when you
run the report with the 'ALL' level of detail.

В отчете ADDM за каждым обнаружением следует одна или более рекомендаций. Таким образом, под каждым обнаружением (Finding) можно видеть Recomendation 1, Recomendation 2 и т.д. Для любого конкретного обнаружения суммарный выигрыш от реализации всех рекомендаций составляет влияние обнаружения (время БД).

Обратите внимание на следующие моменты в отчете ADDM, показанном в листинге 2:

  • Обнаружения 1 и 2 устанавливают, что найдены индивидуальные сегменты базы данных, ответственные за существенные задержки физического ввода-вывода. ADDM рекомендует запустить Segment Advisor для определения того, возможно ли сократить проблемные сегменты.
  • Обнаружение 3 сообщает о недостаточном размере буферного кэша и рекомендует увеличить параметр SGA_TAGRET на 2 128 Мбайт.
  • Рекомендация для обнаружения 4 состоит в запуске SQL Tuning Advisor для специфического оператора SQL.
  • Для обнаружения 5 предлагается рассмотреть возможность расслоения диска и адаптацию решения Automatic Storage Management, поскольку задержки пользовательского ввода-вывода заметно увеличивают время БД.

На заметку! Анализ производительности ввода-вывода ADDM основан на предположении, что среднее время чтения одного блока базы данных составляет 10 000 микросекунд.


В конце детального отчета ADDM находится раздел под названием “Additional Information” (Дополнительная информация), в котором обычно приводится информация о незначительном ожидании.


Совет. Oracle по умолчанию включает ADDM — до тех пор, пока вы не установите параметр STATISTICS_LEVEL равным TYPICAL или ALL. Установка параметра STATISTICS_LEVEL в BASIC приводит к отключению множества автоматических действий по настройке производительности и сбору статистики, в том числе AWR и ADDM.


 

Использование сценария addmrpt.sql

Создать отчет ADDM можно с использованием сценария addmrpt.sql, находящегося в каталоге $ORACLE_HOME/rdbms/admin. Пример в листинге 3 показывает, как получить отчет ADDM за период между 6 часами утра и 2 часами дня. Для этого был специфицирован номер снимка, соответствующий времени сбора снимков — между 6 часами утра и 2 дня. Сценарий addmrpt.sql позволяет легко сделать это, отображая список номеров снимков и соответствующие им даты и время. (В сценарии легко заметить, что снимок с идентификатором 3068 был получен в 6:00 утра, а c идентификатором 3067 — в 2:00 дня).


$ sqlplus /nolog
SQL*Plus: Release 11.1.0.6.0 - Production on Thu Apr 10 09:21:48 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
SQL> CONNECT sys/syspasswd AS SYSDBA
Connected.
SQL> @/u03/app/oracle/rdbms/admin addmrpt.sql
Current Instance
~~~~~~~~~~~~~~~~
DB Id           DB Name        Inst Num   Instance
-------------   ------------   --------   ------------
877170026       FINANCE               1   finance
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id          Inst Num  DB Name       Instance      Host
-------------  --------  ------------  ------------  ----
866170026             1  FINANCE       finance       prod5
Using 866170026 for database Id
Using 1 for instance number
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing  without
specifying a number lists all completed snapshots.
Listing the last 3 days of Completed Snapshots
                                                           Snap
Instance       DB Name      Snap Id     Snap Started      Level
-------------  -----------  ----------  ----------------  -----
finance        FINANCE      3067        22 Jul 2008 05:00     1
                            3068        22 Jul 2008 06:00     1
                            3069        22 Jul 2008 07:01     1
                            3070        22 Jul 2008 08:00     1
                            3071        22 Jul 2008 09:00     1
                            3072        22 Jul 2008 10:00     1
                            3073        22 Jul 2008 11:00     1
                            3074        22 Jul 2008 12:01     1
                            3075        22 Jul 2008 13:00     1
                            3076        22 Jul 2008 14:00     1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 3068
Begin Snapshot Id specified: 3068
Enter value for end_snap: 3076
End Snapshot Id specified: 3076
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is addmrpt_1_3068_3076.txt.
To use this name, press  to continue, otherwise enter an alternative.
Enter value for report_name:
Using the report name addmrpt_1_3068_3076.txt
Running the ADDM analysis on the specified pair of snapshots . . .
. . .
SQL>

Вы уже видели, как получить отчет ADDM за прошедший период, но представьте, что вы с толкнулись с проблемой производительности в 2:40, а последний снимок был сделан в 2:00 и следующий не появится до 3:00, так что последний отчет ADDM ничем не поможет. В такой ситуации можно создать внеочередной отчет ADDM, создав снимок вручную, как показано ниже: 

SQL> EXECUTE dbms_workload_repository.create_snapshot();
PL/SQL procedure successfully completed.

В течение нескольких секунд после создания снимка AWR Oracle автоматически сгенерирует отчет ADDM (используя период между только что выполненным снимком и предыдущим снимком), который можно просмотреть через интерфейс OEM Database Control.

 

Использование пакета DBMS_ADVISOR

Пакет DBMS_ADVISOR помогает управлять атрибутами ADDM, а также выполнять такие работы, как создание заданий и извлечение отчетов ADDM с использованием SQL. ADDM — часть каркаса советников (advisory framework) в Oracle Database 11g. Пользователи, не являющиеся администраторами баз данных, должны иметь привилегию ADVISOR для использования пакета DBMS_ADVISOR.

Ниже перечислены основные процедуры и функции пакета DBMS_ADVISOR, которые применяются не только ADDM, но также всеми другими советниками базы данных. В рассматриваемом случае, конечно, нас интересует применение этого пакета для управления ADDM.

  • CREATE_TASK — создает новое задание советника;
  • SET_DEFAULT_TASK — помогает модифицировать стандартные значения параметров задания;
  • DELETE_TASK — удаляет определенное задание из репозитория;
  • EXECUTE_TASK — выполняет указанное задание;
  • GET_TASK_REPORT — отображает наиболее свежий отчет ADDM;
  • SET_DEFAULT_TASK_PARAMETER — модифицирует параметр задания по умолчанию.

Получить отчет ADDM, идентичный тому, что был построен с помощью addmrpt.sql в предыдущем разделе, можно с использованием процедуры GET_TASK_REPORT из пакета DBMS_ADVISOR. Процедура GET_TASK_REPORT позволяет получить отчет в формате XML, текста или HTML для указанного задания, включая задание ADDM. Ниже показано, как получить текстовый отчет: 

SQL> SET LONG 1000000
SQL> SELECT dbms_advisor.get_task_report(
2 task_name, 'TEXT', 'ALL')
3 FROM dba_advisor_tasks
4 WHERE task_id=(
5 SELECT max(t.task_id)
6 FROM dba_advisor_tasks t, dba_advisor_log l
7 WHERE t.task_id = l.task_id
8 AND t.advisor_name='ADDM'
9* AND l.status= 'COMPLETED');
SQL>

 

Использование OEM Database Control для просмотра отчетов ADDM

Просматривать отчеты ADDM можно также в интерфейсе OEM, используя либо Database Control, либо Grid Control. Давайте посмотрим, как с помощью Database Control получить обнаружения ADDM.

Для начала перейдите на страницу ADDM, выполнив следующие шаги.

  1. На домашней странице Database Control щелкните на ссылке Advisor Central (Центр советников), находящейся в разделе Related Links (Связанные ссылки) внизу страницы.
  2. В нижней части страницы Advisor Central вы увидите раздел Results (Результаты), показанный на рис. 1. Результаты последнего автоматического запуска ADDM (основанные на двух последних снимках) доступны на этой странице. С этой страницы можно также получить результаты любых других советников, которые могли запускать.

На рис. 1 показана страница Advisor Central с последним отчетом ADDM, отображенным в нижней части страницы в разделе Results. Этот автоматически запущенный отчет ADDM был завершен сразу после 12 часов дня 13 мая 2008 г., используя пару двух последних снимков — 3167 и 3168. Щелкните на ссылке, связанной с именем отчета, для просмотра детального отчета ADDM, как показано на рис. 2. Можно также сохранить результаты ADDM в файле или вывести отчет на печать.


Совет. Обратите внимание, что просматривать отчет ADDM можно также прямо из домашней страницы Database Control. Перейдите в раздел Diagnostic Summary (Диагностическая сводка) и щелкните на ссылке ADDM Findings (Обнаружения ADDM), которая представляет собой количество доступных для просмотра обнаружений ADDM. Если ваш экземпляр не имеет никаких обнаружений проблем ADDM, это число будет равно 0.


Для каждой проблемы, идентифицированной ADDM, его обнаружения производительности отображаются в форме из трех столбцов: Impact (Влияние), Finding (Обнаружение) и столбец Recommendations (Рекомендации). В столбце Impact перечислены проблемы производительности в порядке их влияния на систему.

Рис. 1. Нахождение последнего отчета ADDM на странице Advisor Central
в интерфейсе Grid Control

Рис. 2. Просмотр последнего отчета ADDM в OEM Grid Control

Столбец Impact очень важен, поскольку он позволяет приступить к разрешению наиболее серьезных проблем, влияющих на производительность базы данных. Даже если вы предполагаете, что проблемы анализа SQL в данный момент представляют собой наибольшую головную боль, столбец Impact отдаст приоритет проблемам ввода-вывода, и нужно позаботиться о них в первую очередь. Столбец Finding содержит краткое описание проблемы, а одна или более рекомендаций представлены в столбце Recommendations. Например, обнаружение “SQL statements consuming significant database time was found” (“Найдены операторы SQL, потребляющие существенное время БД”) имеет влияние на время БД, оцениваемое в 48,33%, и в этом случае рекомендуемым действием является настройка SQL.

В дополнение к информации о влиянии, проблеме и рекомендациях детальный отчет включает список симптомов, которые привели к конкретному обнаружению. Для некоторых проблем отчет ADDM также включает раздел Rationale (Обоснование), в котором объясняются причины, на основе которых сформулированы рекомендации. Развернув обнаружение, можно получить обоснование и детализированные рекомендации. Например, на рис. 3 показано обоснование определенной рекомендации.

Рис. 3. Просмотр обоснования рекомендации в отчете ADDM

 

Использование Database Control для запуска ADDM

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

  1. На домашней странице Database Control щелкните на ссылке Advisor Central.
  2. Щелкните на ссылке ADDM.
  3. Вы окажетесь на странице Run ADDM, показанной на рис. 4. Здесь доступны следующие варианты.
  • Можно проанализировать производительность текущего экземпляра, немедленно создать снимок AWR и запустить анализ ADDM по нему и самому последнему снимку.
  • Чтобы проанализировать производительность последнего экземпляра, можно выбрать либо Period Start Time (Время начала периода), либо Period End Time (Время завершения периода) и щелкнуть на одной из пиктограмм снимков под графиком Active Sessions (Активные сеансы).

Рис. 4. Запуск внеочередного отчета ADDM с использованием Database Control

Использование представлений словаря, относящихся к ADDM

Следующие представления словаря данных помогут в управлении ADDM.

  • Представление DBA_ADVISOR_RECOMMENDATIONS покажет все рекомендации в базе данных.
  • Представление DBA_ADVISOR_FINDINGS покажет все обнаружения всех советников в базе данных.
  • Представление DBA_ADVISOR_RATIONALE покажет обоснования всех рекомендаций.
  • Представление DBA_ADVISOR_ACTIONS покажет все действия, которые необходимы для реализации рекомендаций ADDM.

 

Вас заинтересует / Intresting for you:

Создание БД Oracle 12c с макси...
Создание БД Oracle 12c с макси... 4272 просмотров Андрей Васенин Mon, 20 Aug 2018, 13:43:20
Настройка памяти базы данных O...
Настройка памяти базы данных O... 19212 просмотров Stas Belkov Sat, 07 Jul 2018, 15:44:14
Мониторинг Oracle через метрик...
Мониторинг Oracle через метрик... 5060 просмотров sepia Tue, 21 Nov 2017, 13:18:05
Кэши, копии  и управление памя...
Кэши, копии и управление памя... 5881 просмотров Дэн Wed, 03 Jan 2018, 17:03:54
Войдите чтобы комментировать