Oracle предоставляет множество инструментов для сборки информации о базе данных и предоставления отчетов на ее основании. Изначально были скрипты UTLBSTAT/UTLESTAT, которые использовались для мониторинга метрик производительности. В Oracle 8i был представлен STATPACK, его функциональность была расширена в Oracle 9i. В версии Oracle Database 10g statpack эволюционировал в Automatic Workload Repository (AWR). AWR лицензируется как часть пакета диагностики. Прежде чем его использовать убедитесь, лицензирована ли у вас эта опция. Но, в версии 10G осталась возможность использовать statpack, его функционал так же был расширен.

AWR (Автоматический репозиторий рабочей нагрузки) основывается на похожих принципах сбора статистической информации в копии, как statspack и estat/bstat. Разница заключается в приёмах и методологии сбора информации, а также в количестве дополнительной информации.

Схема работы AWR

Automatic Workload Repository представляет из себя набор внутренних таблиц словаря данных БД Oracle и специальный фоновый процесс MMON, который появился в Oracle10g.

Периодически AWR создает статистическую копию (снимок) и сохраняет информацию в таблицах расположенных в табличном пространстве SYSAUX. По умолчанию регулярный период сбора установлен на 60 минут. Это значение может быть уменьшено до 10 минут при желании. Механизм сбора статистической копии (awr snapshot) установлен в базе данных 10G по умолчанию и в отличии от пакета statspack установки на автоматический сбор информации не требуется.

Как говорилось выше, для исполнения сбора статистики был введён новый фоновый процесс (MMON). За сбор информации для статистической копии отвечает подчинённый процесс (slave process) M001. В виду того, что MMON является фоновым процессом, влияние на производительность системы во время сбора информации сведено к минимуму путём доступа к структурам памяти (SGA) на прямую, минуя уровень SQL запросов.

Ниже, на рисунке, схематично показана архитектура AWR и его взаимодействие с другими компонентами Oracle:

Как видно из схемы, фоновый процесс MMON периодически опрашивает динамические представления V$ и таблицы X$ и переносит статистическую информацию в свои внутренние таблицы словаря данных с префиксом WRH$. По умолчанию, сбор статистики процессом MMON выполняется каждый час. Процесс MMON также ответственен за удаление устаревшей информации из репозитария AWR. В отличие от утилиты STATSPACK, AWR может хранить статистические данные в виде ‘скользящего окна’. Например, AWR хранит по умолчанию статистику только за последние семь дней, хотя его можно настроить так, что статистика будет удаляться только вручную, как это предусмотрено в STATSPACK. MMON также собирает статистику ожиданий для новой компоненты Active Session History (ASH), которая позволяет просматривать историю работы каждого активного сеанса базы данных.

Репозиторий AWR

Репозиторий представляет набор таблиц и представлений словаря данных Oracle. Владельцем репозитория является пользователь SYS, объекты репозитория размещены в табличном пространстве SYSAUX. Все данные размещаются в наборе таблиц с префиксом WR.

Статистическая информация, которая хранится в хранилище данных AWR активно используется, как внутренними, так и внешними компонентами Oracle, в то время как в STATPACK информация не использовалась, и дожидалась действий DBA. К внутренним компонентам, использующим статистику AWR, можно отнести такие новые компоненты, как Automatic Database Diagnostic Monitor (ADDM), SQL Tuning Advisor, SQL Access Advisor, Automatic Segment Advisor, Undo Advisor, Segment Advisorи т.д. Все эти компоненты впервые представлены в Oracle10g и служат для автоматизации и выработки рекомендаций по настройке производительности различных подсистем базы данных Oracle. Например, компонента ADDM автоматически выполняет анализ текущих данных в AWR после каждого нового снимка и показывает возможные узкие места в базе данных, а также предлагает свои рекомендации по возможным путям их решения. Внешними компонентами, использующими статистику AWR, являются Oracle Enterprise Manager, Statspack Viewer и т.д.

Хранилище данных механизма AWR содержит таблицы следующих типов:

• Таблицы с префиксом WRM$ хранят метаданные AWR. Например, таблица WRM$_SNAPSHOT хранит информацию обо всех снимках, которые хранятся в репозитории
• Таблицы с префиксом WRH$ хранят собственно статистическую историю. Напрмер, таблица WRH$_SYSSTAT содержит снимки динамического представления V$SYSSTAT
• Таблицы с префиксом WRI$ содержат служебную информацию различных компонент Oracle типа SQL Tuning Advisor, которые используют информацию AWR. Например, таблица WRI$_ADV_TASKS содержит историю о всех запусках advisory компонент, использующих данные AWR

Ниже представлен запрос для получения списка этих таблиц:

SELECT TABLE_NAME
FROM DBA_TABLES
WHERE TABLESPACE_NAME = 'SYSAUX'
AND SUBSTR(TABLE_NAME, 1,2) = 'WR'
AND ROWNUM <= 20
ORDER BY 1;

Результаты запроса:

TABLE_NAME
——————————
WRH$_ACTIVE_SESSION_HISTORY_BL
WRH$_BG_EVENT_SUMMARY
WRH$_BUFFER_POOL_STATISTICS
WRH$_CLASS_CACHE_TRANSFER_BL
WRH$_CR_BLOCK_SERVER
WRH$_CURRENT_BLOCK_SERVER
WRH$_DATAFILE
WRH$_DB_CACHE_ADVICE_BL
WRH$_DLM_MISC_BL
WRH$_ENQUEUE_STAT
WRI$_OPTSTAT_HISTGRM_HISTORY
WRI$_OPTSTAT_HISTHEAD_HISTORY
WRI$_OPTSTAT_IND_HISTORY
WRI$_OPTSTAT_OPR
WRI$_OPTSTAT_TAB_HISTORY
WRI$_SCH_CONTROL
WRI$_SCH_VOTES
WRI$_SQLSET_BINDS
WRI$_SQLSET_DEFINITIONS
WRM$_BASELINE

Как видно, по именам таблиц легко догадаться о данных, которые в них размещены.

Возможности AWR

Можно разделить статистические данные собираемые AWR на два больших класса:

• События ожидания (wait event) - ситуация при которой сеанс ожидает завершения определённого события, например завершения запроса к диску (I/O request)
• Распределение рабочего времени (time model statistics ) - в то время, как статистки класса ожидания описывают, где происходили главные простои системы, статистки класса распределения рабочего времени описывают на что было потрачено время во время работы, например сколько времени ушло на синтаксический анализ

Automatic Workload Repository (AWR) используется для сбора статистики производительности, включая:

• Время ожидания ресурсов базы данных (foreground и background wait events). Эту статистическую информацию можно использовать для первоначального определения ‘узких’ мест в производительности базы данных
• Метрики, характеризующие скорость доступа к различным ресурсам базы данных. Например, процессорное время на вызов пользователя (CPU Tome Per User Call) или число логических чтений в секунду (Consistent Read Gets Per Sec). Этот вид статистики появился в Oracle10g и представляет собой набор автоматически вычисляемых процессом MMON статистик, которые раньше надо было вычислять вручную
• Временные статистики, описывающие распределение использования процессорного времени (Time model). Этот вид статистик также является новшеством 10 версии и характеризует использование процессорного времени для выполнения определенных задач. Например, метрика sql execute elapsed time характеризует фактическое время выполнения запросов SQL. Наибольший интерес представляет собой метрика DB time, которая описывает общее процессорное время, затраченное Oracle для обслуживания всех пользовательских операций. Эту метрику можно использовать для мониторинга общей загрузки БД
• Системные статистики, описывающие производительность экземпляра Oracle и операции ввода/вывода в табличные пространства/файлы данных базы
• Статистика работы операционной системы. В 10 версии появилась возможность отслеживать основные параметры производительности операционной системы
• Статистическая информация по SQL-запросам. Данный вид статистики позволяет DBA отслеживать ресурсоемкие SQL-запросы, используя различные критерии. Например, выбирать SQL-запросы, сделавшие наибольшее число операций ввода/вывода в файлы данных
• Статистика по истории доступа к сегментам данных. Данный вид статистики позволяет выявить “горячие” сегменты данных, используя различные критерии, например, число логических или физических чтений данных сегмента

Управление AWR

Для управления настройками AWR можно использовать стандартный пакет PL/SQL DBMS_WORKLOAD_REPOSITORY и графический интерфейс Oracle Enterprise Manager. Пакет DBMS_WORKLOAD_REPOSITORY содержит следующие вызовы:

MODIFY_SNAPSHOT_SETTINGS - процедура позволяет настраивать частоту, с которой процесс MMON будет сохранять в хранилище AWR новый снимок статистик, а также временной интервал хранения этого снимка в базе данных. Текущие значения этих настроек можно посмотреть, выполнив SQL-запрос:

SELECT
 EXTRACT( DAY FROM SNAP_INTERVAL) * 24 * 60 +
 EXTRACT( HOUR FROM SNAP_INTERVAL) * 60 +
 EXTRACT( MINUTE FROM SNAP_INTERVAL ) "SNAPSHOT INTERVAL (MIN)",
 EXTRACT( DAY FROM RETENTION) * 24 * 60 +
 EXTRACT( HOUR FROM RETENTION) * 60 +
 EXTRACT( MINUTE FROM RETENTION ) "RETENTION INTERVAL (MIN)"
FROM DBA_HIST_WR_CONTROL;

CREATE_SNAPSHOT - процедура позволяет вручную сохранить в репозитории AWR новый статистический снимок. Единственный параметр этой процедуры задает детализацию статистической информации, сохраняемой в БД. Значение по умолчанию для этого параметра задается параметром инициализации экземпляра Oracle STATISTICS_LEVEL. Допустимые значения этого параметра - TYPICAL и ALL. Обычно рекомендуется использовать уровень статистики TYPICAL, который достаточен для мониторинга производительности базы данных.

DROP_SNAPSHOT_RANGE - процедура позволяет вручную удалять статистические данные для заданного набора снимков.

CREATE_BASELINE - процедура позволяет создавать именованные наборы снимков для последующего сравнения производительности базы данных для различных временных интервалов.

AWR_REPORT_TEXT и AWR_REPORT_HTML - функции позволяют вручную строить отчеты для заданных временных интервалов.

Константы пакета DBMS_WORKLOAD_REPOSITORY MIN_INTEVAL и MAX_INTERVAL задают допустимые минимальные и максимальные значения для интервала сбора статистики в минутах соответственно, а MIN_RETENTION и MAX_RETENTION задают минимальное и максимальное время хранения статистики в базе данных соответственно.

Моментальные снимки (Snapshots)

По умолчанию, снимки делаются каждый час и хранятся в течении 7 дней. Для определения установленных значений выполняется запрос:

SELECT SNAP_INTERVAL,
 RETENTION
FROM DBA_HIST_WR_CONTROL;

SNAP_INTERVAL      RETENTION
—————–  —————–
+00000 01:00:00.0  +00007 00:00:00:0

Результаты запроса показывают, что интервал создания снимков равен 1 часу и хранятся снимки 7 дней, т.е. выставлены значения, используемые по умолчанию.

Автоматическая сборка статистики возможна при значении параметра STATISTICS_LEVEL равным ALL или TYPICAL. Если значение равно BASIC, выполняется ручное управление снимками. Узнать текущее значение параметра можно выполнив запрос:

SELECT NAME,
 VALUE
FROM GV$PARAMETER
WHERE NAME LIKE 'stat%';

statistics_level    TYPICAL

Изменить значение параметра STATISTICS_LEVEL  можно конструкцией  ALTER SYSTEM или ALTER SESSION.

Создание моментальных снимков

По умолчанию, снимки создаются автоматически, но бывают ситуации, когда требуется ручное создание снимка. Для этого выполняется команда:

BEGIN
 DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();
END;

Как видно, функция CREATE_SNAPSHOT не имеет параметров. Все необходимые параметры берутся из системы.

Изменение настроек моментальных снимков

Значения, предлагаемые Oracle по умолчанию, могут быть изменены. Для этого выполняется такой запрос:

BEGIN
 DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(
 -- Продолжительность хранения. Значение в минутах (установлено 30 дней).
 retention => 43200,
 -- Как часто делать снимок. Значение в минутах.
 interval => 30):
END;
/

• Значение параметра RETENTION устанавливается в минутах, и должно быть в интервале от 1 440 (один день) до 52 596 000 (100 лет)
• Значение параметра INTERVAL устанавливается в минутах, и должно быть в интервале от 10 до 525 600 (один год)

Внесенные изменения и настройки отражаются в представлении DBA_HIST_WR_CONTROL. При установке значения интервал (interval) равное 0, снимки не делаются. Делать это не рекомендуется.

Удаление снимков

Для удаления снимков из репозитория используется процедура DROP_SNAPSHOT_RANGE:

BEGIN
 DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (
 low_snap_id => 42,
 high_snap_id => 52);
END;
/

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

COL INSTART_FMT NOPRINT;
COL INST_NAME FORMAT A12 HEADING 'Instance';
COL DB_NAME FORMAT A12 HEADING 'DB Name';
COL SNAP_ID FORMAT 99999990 HEADING 'Snap Id';
COL SNAPDAT FORMAT A18 HEADING 'Snap Started' JUST C;
COL LVL FORMAT 99 HEADING 'Snap/Level';
SET HEADING ON;
BREAK ON INST_NAME ON DB_NAME ON HOST ON INSTART_FMT SKIP 1;
TTITLE OFF;
SELECT
 TO_CHAR(S.STARTUP_TIME,' DD MON "at" HH24:MI:SS') INSTART_FMT,
 DI.INSTANCE_NAME INST_NAME,
 DI.DB_NAME DB_NAME,
 S.SNAP_ID SNAP_ID,
 TO_CHAR(S.END_INTERVAL_TIME,'DD MON YYYY HH24:MI') SNAPDAT,
 S.SNAP_LEVEL LVL
FROM DBA_HIST_SNAPSHOT S,
 DBA_HIST_DATABASE_INSTANCE DI
WHERE DI.DBID = S.DBID
 AND DI.INSTANCE_NUMBER = S.INSTANCE_NUMBER
 AND DI.STARTUP_TIME = S.STARTUP_TIME
ORDER BY SNAP_ID;

Базовые линии

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

BEGIN
 DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (
 start_snap_id => 210,
 end_snap_id => 220,
 baseline_name => 'first_baseline');
END;
/

Пара снимков, ассоциированные с базовой линией сохраняется до тех пор, пока базовая линия не будет явно удалена:

BEGIN
 DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (
 baseline_name => 'first_baseline',
 cascade => FALSE); --Если значениеTRUE, то удаляются связанные снимки.
END;
/

Для параметра CASCADE значение по умолчанию берется равным FALSE.

Если вы создали базовые линии для периода времени, то можно обратиться к представлению DBA_HIST_SNAPSHOT для определения идентификаторов снимков - SNAP_ID, вошедших в этот период:

SELECT SNAP_ID,
 BEGIN_INTERVAL_TIME,
 END_INTERVAL_TIME
FROM DBA_HIST_SNAPSHOT
ORDER BY 1;

SNAP_ID BEGIN_INTERVAL_TIME       END_INTERVAL_TIME
——- ————————- ———————-
380     14-OCT-09 11.00.37.796 AM 14-OCT-09 12.00.11.515 PM
381     14-OCT-09 12.00.11.515 PM 14-OCT-09 01.00.54.109 PM
382     14-OCT-09 01.00.54.109 PM 14-OCT-09 02.00.34.906 PM
383     14-OCT-09 02.00.34.906 PM 14-OCT-09 03.01.07.062 PM
384     14-OCT-09 03.01.07.062 PM 14-OCT-09 04.00.41.343 PM
385     14-OCT-09 04.00.41.343 PM 14-OCT-09 05.00.19.546 PM
386     14-OCT-09 05.00.19.546 PM 14-OCT-09 06.00.57.187 PM
387     14-OCT-09 06.00.57.187 PM 14-OCT-09 07.00.35.734 PM
388     14-OCT-09 07.00.35.734 PM 14-OCT-09 08.00.13.734 PM
389     14-OCT-09 08.00.13.734 PM 14-OCT-09 09.00.51.812 PM
390     14-OCT-09 09.00.51.812 PM 14-OCT-09 10.00.30.234 PM

Запуск отчета AWR

В отличие от механизма statspack при использовании AWR нет надобности настраивать автоматический механизм сбора копий (snapshots). Эта функция работает по умолчанию в любой базе 10-ой версии. Пользователю остается лишь получить отчёт, который основывается на выбранных копиях.

Для получения отчетов, Oracle предоставляет два скрипта awrrpt.sql и awrrpti.sql. Для генерации отчета выполните скрипты:

@$ORACLE_HOME/rdbms/admin/awrrpt.sql
@$ORACLE_HOME/rdbms/admin/awrrpti.sql

Запуск из SQLPlus осуществляется как показано ниже:

SQL> @?/rdbms/admin/awrrpt.sql
SQL> @?/rdbms/admin/ awrrpti.sql

После запуска на исполнение, будет предложено выбрать формат отчета -  текстовый вариант или HTML. Указать идентификаторы начального и конечного снимков и месторасположение отчета. После того, как отчет сформирован, его можно просмотреть в браузере или любом текстовом редакторе. Пример исполнения отчета:

SQL> @$ORACLE_HOME/rdbms/admin/awrrpti.sql
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
Would you like an HTML report, or a plain text report?
Enter ‘html’ for an HTML report, or ‘text’ for plain text
Defaults to ‘html’

На этом шаге запрашивается формат отчета, для получения в HTML введите html, для получения текстового варианта укажите text. По умолчанию используется HTML, в приведенном примере указан HTML:

Enter value for report_type: html
Type Specified: html
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id        Inst Num DB Name      Instance     Host
———— ——– ———— ———— ———–
* 268115148         1 ALL_ORACLE   ALL_ORACLE   TEST

Enter value for dbid: 268115148
Using 268115148 for database Id
Enter value for inst_num: 1
Using 1 for instance number
Using the Automatic Workload Repository (AWR) 273
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
———— ———— ——— —————— —-
lnx1         LNX1               290 20 Oct 2009 00:00     1
291                                 20 Oct 2009 01:00     1
292                                 20 Oct 2009 02:00     1
293                                 20 Oct 2009 03:00     1
294                                 20 Oct 2009 04:00     1
295                                 20 Oct 2009 05:00     1

Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

На этом шаге будут запрошены идентификаторы начального и конечного снимков

Enter value for begin_snap: 290
Begin Snapshot Id specified: 290
Enter value for end_snap: 295
End Snapshot Id specified: 295
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is awrrpt_1_290_345.html. To use this name,
press to continue, otherwise enter an alternative.

И на последнем шаге будет предложено указать имя отчета или использовать предложенное системой:

Enter value for report_name: report.html
Using the report_name report.html

Главное отличие от statspack заключается в том, что в простом отчёте AWR текст SQL команд представлен полностью, а не частично как это было раньше. Также можно использовать $ORACLE_HOME/rdbms/admin/awrsqrpt.sql для получения детального отчёта по определённому SQL.

Примеры использования информации AWR

Как было сказано выше, хранилище данных AWR служит источником данных о работе сервера баз данных для различных компонент сервера. Описание настройки других подсистем сервера, которые используют хранилище AWR для выработки своих рекомендаций, остается за рамками этой статьи. Ниже приведено несколько примеров того, как можно использовать информацию AWR для анализа тенденций в работе сервера Oracle. Анализ тенденций, или трендов, позволяет увидеть картину того, какие характеристики производительности имеет база данных по часам в течение дня или по дням недели. Обычно такая усредненная картина достаточно точно описывает поведение базы данных для конкретного набора приложений и конечных пользователей. Это позволяет более эффективно определять узкие места в работе и моменты времени, когда возможен спад производительности сервера.

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

SET PAGES 999
SET PAGESIZE 1000
BREAK ON SNAP_TIME SKIP 2
COL SNAP_TIME FORMAT A19 HEADING 'Day Hour'
COL AVG_VALUE FORMAT 999,999,999 HEADING 'Avg Physical Reads'
SELECT TO_CHAR(BEGIN_INTERVAL_TIME,'hh24') SNAP_TIME,
 AVG(VALUE) AVG_VALUE
FROM DBA_HIST_SYSSTAT
NATURAL JOIN
 DBA_HIST_SNAPSHOT
WHERE STAT_NAME = 'physical reads'
GROUP BY TO_CHAR(BEGIN_INTERVAL_TIME,'hh24')
ORDER BY TO_CHAR(BEGIN_INTERVAL_TIME,'hh24');

Пример результата работы этого скрипта может выглядеть следующим образом:

Hour         Avg Physical Reads
———— ——————-
00                        76,120
01                        90,200
02                       150,395
03                       170,028
04                       176,677
05                       175,874
06                       172,680
07                       177,164
08                       278,073
09                       281,816
10                       482,518
11                       781,793
12                       986,012
13                       863,357
14                       471,752
15                       367,471
16                       274,219
17                       273,576
18                       269,362
19                       174,765
20                       174,083
21                       169,860
22                       75,2070
23                       74,5340

Из приведенного выше отчета видно, что наибольший объем операций физического чтения приходится в среднем на период времени с 11 до 13 часов, что может вызвать нежелательные задержки в работе пользователей. Знание подобного рода информации позволяет DBA более точно локализовать причины подобного рода проблем. Если скопировать полученные данные в Excel и построив график, можно получить графическое представление ситуации, как показано на нижеприведенном рисунке:

Тот же отчет, но по дням недели выглядит следующим образом:

SET PAGES 999
SET PAGESIZE 1000
BREAK ON SNAP_TIME SKIP 2
COL SNAP_TIME FORMAT A19 HEADING 'Week Day'
COL AVG_VALUE FORMAT 999,999,999 HEADING 'Avg Physical Reads'
SELECT TO_CHAR(BEGIN_INTERVAL_TIME,'day') SNAP_TIME,
 AVG(VALUE) AVG_VALUE
FROM DBA_HIST_SYSSTAT
NATURAL JOIN
 DBA_HIST_SNAPSHOT
WHERE STAT_NAME = 'physical reads'
GROUP BY TO_CHAR(BEGIN_INTERVAL_TIME,'day')
ORDER BY 2 DESC;

Week Day            Avg Physical Reads
——————- ——————
wednesday                      569,687
monday                         515,349
tuesday                        493,313
thursday                       305,815
friday                         297,250
sunday                         190,185
saturday                       170,332

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

SELECT TO_CHAR(H.SAMPLE_TIME,'HH24') "Hour",
 SUM(H.WAIT_TIME/100) "Total Wait Time (Sec)"
FROM V$ACTIVE_SESSION_HISTORY H,
 V$EVENT_NAME N
WHERE H.SESSION_STATE = 'ON CPU'
 AND H.SESSION_TYPE = 'FOREGROUND'
 AND H.EVENT_ID = N.EVENT_ID
 AND N.WAIT_CLASS <> 'Idle'
GROUP BY
 TO_CHAR(H.SAMPLE_TIME,'HH24');

Hour Total Wait Time (Sec)
—- ———————
11                     219
12                 302,998
13                  60,982
14                 169,716
15                  39,593
16                 299,953
17                 122,933
18                   5,147

Таким образом, механизм AWR наряду со стандартным набором отчетов предоставляет широкие возможности по более детальному анализу производительности в различных временных срезах. Использование AWR совместно с такими новыми технологиями Oracle, такими как Active Session History, улучшенный Wait Event Interface и набором встроенных утилит ADDM, SQL Tuning Advisor и других значительно облегчает задачи администрирования, мониторинга и поддержания производительности больших систем Oracle на необходимом уровне.

На этом позвольте завершить эту обзорную статью посвященную AWR. Удачи.