Oracle AWR: статистика рабочей нагрузки, snapshot и производительность базы

Oracle AWR собирает статистику производительности базы Oracle через snapshots и выдает отчетыДинамические представления производительности V$SYSSTAT и V$SESSSTAT содержат большой объем кумулятивной статистики базы данных Oracle. Динамические представления производительности очень полезны для оценки производительности базы данных, но, к сожалению, когда вы останавливаете базу, данные из этих динамических представлениях исчезают полностью! Если необходимо отслеживать изменения производительности базы данных Oracle во времени или увидеть эффект, оказываемый на производительность изменениями базы данных, то придется сохранять данные о производительности в репозитории, и здесь на помощь приходит автоматический репозиторий рабочей нагрузки (Automatic Workload Repository — AWR).

AWR автоматически накапливает и сохраняет статистику производительности базы данных, связанную с обнаружением проблемы и настройкой, и лежит в основе всех новых механизмов автоматической настройки базы данных. AWR был спроектирован Oracle в качестве замены традиционной утилиты Statspack, которая помогала собирать статистику производительности базы данных (утилита Statspack все еще доступна, но Oracle настоятельно рекомендует вместо нее применять AWR). Обратите внимание на необходимость оплаты дополнительной лицензии на использование AWR.

AWR генерирует снимки ключевых данных производительности, таких как статистика системы и сеанса, статистика использования сегментов, статистика временной модели и статистика максимальной нагрузки SQL, сохраняя снимки в табличном пространстве Sysaux. По умолчанию база данных генерирует снимок (snapshot) статистики каждый час. Интервал между снимками, типы статистики, собираемой AWR, а также длительность хранения снимков в AWR поддается настройке. AWR предоставляет статистику производительности в двух форматах.

  • Временная коллекция статистики в памяти SGA, доступная через динамические представления производительности (V$) или в интерфейсе OEM.
  • Постоянный тип данных о производительности в форме регулярных снимков AWR, к которым можно обращаться либо через представления словаря данных (DBA_*), либо через OEM Data Control. Постоянные данные в снимках AWR помогают выполнять хронологические сравнения показателей производительности.

MMON — это фоновый процесс, который выполняет большинство связанных с управлением задач, включая генерацию сигналов тревоги базы данных и захват статистики для недавно модифицированных объектов базы данных. Процесс MMON регулярно передает версию статистики AWR, находящуюся в памяти, на диск (в виде снимков).

Администраторы баз данных Oracle традиционно нуждались в поддержке специальных таблиц для сбора хронологических данных о производительности. AWR автоматически собирает статистику по производительности и поддерживает хронологические данные для анализа. Можно просматривать данные снимков с помощью представлений V$ или создавать отчеты для последующего детального изучения. Различные компоненты и средства базы данных используют информацию из этих снимков AWR для мониторинга и диагностики проблем производительности. Например, как было показано в одном из блогов, средство ADDM полагается на эти снимки (snapshots) при диагностике проблем с производительностью. Вдобавок советники SQL Tuning Advisor, Undo Advisor и Segment Advisor также используют данные AWR.

 

Типы данных, накапливаемых AWR

Средство AWR собирает огромное количество статистики производительности, включая приведенную в следующем списке.

  • Базовая статистика, которая является также частью представлений V$SYSSTAT и V$SESSSTAT.
  • Статистика SQL, служащая для идентификации ресурсоемких операторов SQL.
  • Статистика использования базы данных, информирующая о том, как база данных в конкретный момент обращается к различным объектам.
  • Статистика временной модели, которая сообщает о том, сколько времени потребовало каждое действие в базе данных.
  • Статистика ожидания, представляющая информацию об ожиданиях сеанса (в предыдущих версиях для сбора информации об ожидании сеанса нужно было соединять представление V$SESSION с представлением V$SESSION_WAIT; теперь в представление V$SESSION появилось несколько новых столбцов, так что можно запрашивать его напрямую).
  • Статистика ASH, которая регулярно сбрасывается в AWR.
  • Статистика использования базы данных, которая сообщает, насколько интенсивно база использует различные средства.
  • Результаты различных сеансов советников по управлению, таких как Segment Advisor и SQL Access Advisor.
  • Статистика операционной системы, вроде использования базой данных дискового ввода-вывода и памяти.

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

 

Обработка данных AWR

Важно понимать, что AWR не является постоянным репозиторием для хранения статистики производительности Oracle. По умолчанию AWR ежечасно фиксирует статистику производительности и сохраняет ее в течение восьми дней. В Oracle оценивают, что примерно за десять сеансов эти установки по умолчанию потребуют около 200 — 300 Мбайт пространства для хранения данных AWR. Место, используемое AWR, зависит от следующих факторов.

  • Период сохранения данных — чем дольше этот период, тем больше пространства понадобится.
  • Интервал между снимками — чем чаще делаются снимки статистики, тем больше места необходимо.
  • Количество активных сеансов — чем больше количество пользовательских сеансов, тем больше данных собирается AWR.

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

 

Управление AWR

Снимки предоставляют значения ключевых статистических показателей на определенный момент времени. Сравнивая снимки за разные периоды, можно вычислить степень изменения статистики производительности. Большинство инструментов-советников Oracle при формировании своих рекомендаций полагаются именно на снимки AWR.

Управление AWR по существу включает управление регулярными снимками, которые AWR собирает из базы данных. Интервал между снимками по умолчанию составляет 60 минут, а минимальный интервал — 10 минут. Если вы полагаете, что этот период не подходит для конкретных целей, значение интервала по умолчанию легко изменить, модифицировав параметр INTERVAL.


На заметку! Снимки системы можно делать вручную в любое время по своему усмотрению.


Чтобы правильно использовать средство AWR, нужно выбрать некоторую репрезентативную базовую линию, которая представляет собой пару или диапазон снимков AWR. Когда производительность базы данных низка, можно сравнить oracle snapshot (снимок) базовой линии со снимком статистики по текущей производительности и найти источник проблем.

Управляются снимки AWR либо с помощью OEM Database Control, либо с помощью поставляемого Oracle пакета DBMS_WORKLOAD_REPOSITORY, который позволяет управлять снимками и базовыми линиями. Давайте сначала рассмотрим использование этого пакета.

 

Использование пакета DBMS_WORKLOAD_REPOSITORY для управления снимками AWR

Пакет DBMS_WORKLOAD_REPOSITORY служит для создания, уничтожения и модификации снимков, а также создания и уничтожения снимков базовых линий.

Чтобы создать снимок snapshot вручную, воспользуйтесь процедурой CREATE_SNAPSHOT, как показано ниже: 

SQL> BEGIN
Dbms_workload_repository.create_snapshot();
END;

Для удаления диапазона снимков служит процедура DROP_SNAPSHOT. При уничтожении набора снимков Oracle автоматически сбрасывает данные AWR, являющиеся частью заданного диапазона. В следующем примере уничтожаются все снимки, идентификаторы которых попадают в диапазон от 40 до 60

SQL> BEGIN
dbms_workload_repository,drop_snapshot_range(
low_snap_id => 40,
high_snap_id => 60, dbid => 2210828132);
END;

Совет. В случае установки интервала снимков в ноль AWR прекратит собирать данные снимков. Разумеется, это пагубно скажется на работе ADDM, SQL Tunung Advisor, Undo Advisor и Segment Advisor, поскольку все они зависят от данных AWR.


 

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

Управлять снимками AWR можно на странице Automatic Workload Repository (Автоматический репозиторий рабочей нагрузки) в интерфейсе OEM Data Control, которая показана на рисунке 1 ниже:

Чтобы добраться до этой страницы, зайдите на домашнюю страницу Database Control, щелкните на ссылке Administration (Администрирование), а затем — на ссылке Automatic Workload Repository в группе Statistics Management (Управление статистикой). Эта страница имеет два основных раздела: General (Общие) и Manage Snapshots and Baselines (Управление снимками и базовыми линиями).

Изменять общие настройки AWR можно, щелкнув на кнопке Edit (Редактировать) в разделе General. Это перенесет на страницу Edit Settings (Редактирование настроек), где можно модифицировать следующие настройки:

  • интервалы хранения снимков;
  • интервалы сбора снимков;
  • уровень сбора снимков (Typical (Обычный) или All (Все)).

В разделах Manage Snapshots and Baselines главной страницы AWR первая строка показывает общее количество снимков. Эта строка является ссылкой, на которой можно щелкнуть, чтобы попасть на страницу Manage Snapshots (Управление), где перечислены все снимки AWR. Щелчок на индивидуальном снимке приводит к отображению подробных сведений о нем, включая время захвата и уровень сбора. На рисунке 2 ниже показаны подробности об одном снимке AWR. Если установлена базовая линия AWR (репрезентативный период времени), вы также увидите сравнение определенного снимка с этой базовой линией. На странице Manage Snapshots можно выполнять следующие операции.

  • Спонтанно создавать снимки (используя кнопку Create (Создать)).
  • Просматривать список снимков, собранных за определенный период.
  • Устанавливать диапазон снимков для использования в качестве базовой линии (кнопкой Create Preserved Snapshot Set (Создать зафиксированный набор снимков)).
  • Удалять определенный диапазон снимков из списка снимков, собранных за некоторый период времени (с помощью кнопки Delete Snapshot Range (Удалить диапазон снимков)).


На заметку! Диапазон снимков, который используется для базовой линии — то же самое, что и зафиксированный (preserved) набор снимков.


 

Создание и удаление базовых линий снимков AWR

Базовые линии AWR позволяют выполнять сравнительный анализ производительности между двумя периодами. Базовая линия AWR состоит из набора снимков AWR за определенный период. Назначение базовой линии — служить измеренным критерием приемлемой производительности базы данных, а также отправной точкой для сбора различной статистики системы. Когда говорят, что производительность базы данных плохая, следует уточнять, что она плоха по сравнению с чем-то, что можно считать хорошей производительностью. Если база данных обрабатывает определенное количество транзакций за репрезентативный период (базовой линии), то становится легко определить, является текущая производительность нормальной или нет. Базовые линии AWR определяются по умолчанию до тех пор, пока параметр инициализации STATISTICS_LEVEL установлен в TYPICAL или ALL. Базовая линия AWR определяется на паре снимков, полученных за период, который считается представляющим типичную хорошую производительность базы данных. Базовая линия затем служит репрезентативной выборкой для сравнения с текущей производительностью базы данных. После создания базовой линии AWR хранит ее снимки бесконечно долго (и не удаляет их после периода по умолчанию в семь дней), если только вы не решите удалить саму базовую линию.

Новая базовая линия создается с использованием процедуры CREATE_BASELINE из пакета DBMS_WORKLOAD_REPOSITORY. Снимки идентифицируете идентификаторами (snap ID), которые уникально и последовательно определяют каждый снимок. Получить идентификаторы снимков для создания базовой линии можно из представления DBA_HIST_SNAPSHOT. В следующем примере создает snapshot снимок базовой линии по имени PEAK_TIME:

SQL> BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE
(START_SNAP_ID => 125,
END_SNAP_ID => 185,
BASELINE_NAME => 'peak_time baseline',
DBID => 2210828132);
END;

Уничтожается базовая линия с помощью процедуры DROP_BASELINE из пакета DBMS_WORKLOAD_REPOSITORY

SQL> BEGIN
DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(BASELINE_NAME => 'peak_time
baseline',
CASCADE => FALSE, DBID => 2210828132);
END;

Установка параметра CASCADE в TRUE приводит к удалению также и самих снимков.

 

Очистка статистики AWR

Как должно быть известно, AWR по умолчанию запускается каждый час, и статистика AWR сохраняется по умолчанию в течение восьми дней. После истечения этого периода Oracle удаляет снимки, начиная с самого старого (за исключением снимков базовой линии). В Oracle оценивают, что если имеется десять параллельных сеансов, это потребует от 200 до 300 Мбайт дискового пространства для хранения данных за семидневный период по умолчанию. Поэтому необходимо убедиться в том, что в табличном пространстве Sysaux есть как минимум столько свободного места. Количество пользовательских сеансов — ключевой фактор, определяющий пространство, необходимое для статистики AWR.


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


Как упоминалось ранее, в дополнение к количеству активных пользовательских сеансов, ключевыми факторами объема хранимой в табличном пространстве Sysaux статистики являются также период времени хранения данных AWR и интервал между снимками. Период времени хранения можно изменить параметром RETENTION, а интервал между снимками — параметром INTERVAL. Вот некоторые подробности относительно влияния этих двух важных параметров на создание и обслуживание снимков.

RETENTION. Как вам известно, период хранения данных статистики AWR по умолчанию составляет восемь дней. Минимальный период хранения — один день. Чем дольше период хранения, тем больше места понадобится AWR в табличном пространстве Sysaux. Однако если в табличном пространстве Sysaux не хватает места, этот фактор перевешивает прочие установки периода хранения. В этом случае Oracle начнет удалять снимки, записывая новые данные поверх самых старых.

INTERVAL. По умолчанию AWR собирает данные каждые 60 минут, а минимальное значение интервала составляет 10 минут. Чем чаще выполняются снимки AWR, тем больше данных собирает AWR; чем реже делаются снимки, тем выше шанс, что вы не заметите кратковременных всплесков использования дисков и памяти, которые могут случиться в базе данных.

Для модификации настроек снимков служит пакет DBMS_WORKLOAD_REPOSITORY:

SQL> BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(
RETENTION => 43200,
INTERVAL => 30,
DBID => 3310949047);
END;

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


На заметку! Установка параметра RETENTION в 0 отключает автоматическую очистку AWR. Если установить в 0 параметр INTERVAL, отключится сбор снимков AWR.


Отчеты Oracle AWR по статистике снимков  snapshots оценят производительность базы данных Oracle

 

Скользящее окно базовой линии

База данных всегда поддерживает определенное системой скользящее окно базовой линии. Размер окна соответствует текущему периоду базовой линии AWR — по умолчанию 8 дней. Этот размер окна можно изменить, установив количество дней в окне равным или меньшим периоду хранения AWR. Прежде чем можно будет изменить размер скользящего окна базовой линии, понадобится увеличить период хранения AWR.

 

Шаблоны базовых линий AWR

Возможности использования базовых линий AWR не ограничиваются существующими снимками, с которыми можно сравнивать. Можно также создавать шаблоны того, как наборы данных будут формировать базовые линии за временные периоды в будущем. Например, если известно, что выходные совпадают с праздником, можно использовать одиночный шаблон для планирования создания базовой линии за этот период. Или же можно применить многократно повторяющийся шаблон для создания базовой линии, к примеру, каждую пятницу после обеда — с 3 до 5 часов. Фоновый процесс MMON создает базовые линии на основе всех созданных вами шаблонов.

Базовые линии AWR можно создавать в среде Enterprise Manager. В последующих разделах блога будут даны соответствующие пояснения.

 

Шаблоны одиночных базовых линий

Шаблон одиночной базовой линии создает одиночную базовую линию с фиксированным временным интервалом, например, с 10 часов утра 1 января 2008 г. до 12 часов ночи 1 января 2009 г. Ниже показано, как создается шаблон одиночной базовой линии с использованием процедуры CREATE_BASELINE_TEMPLATE

SQL> begin
2 dbms_workload_repository.create_baseline_template (
3 start_time => '2008-12-31 22:00:00 CST',
4 end_time => '2009-01-01 08:00:00 CST',
5 baseline_name => 'test_baseline1',
6 template_name => 'test_template1',
7 expiration => 30);
8* end;
SQL> /

Шаблон однократной базовой линии создаст базовую линию AWR, охватывающую период между 10 вечера 31 декабря 2008 г. и 8 утра 1 января 2009 г. Показанный здесь пример создает шаблон для одиночного периода времени в будущем. По умолчанию базовые линии AWR никогда не устаревают. Однако можно специфицировать параметр EXPIRATION, чтобы установить временной период, на протяжении которого будет действительна базовая линия, т.е. количество дней, в течение которых база данных будет поддерживать эту базовую линию. В примере параметр EXPIRATION имеет значение, равное 30 дням.

 

Шаблоны повторяемых базовых линий

Шаблон повторяемой базовой линии создает многократно воспроизводимую базовую линию с временным интервалом, который повторяется на протяжении заданного времени, например, каждую пятницу с 10 утра до 12 ночи, на протяжении 2008 г. Вот как можно создать шаблон повторяемой базовой линии: 

SQL> begin
dbms_workload_repository.create_baseline_template(
day_of_week          => 'Friday',
hour_in_day          => 15,
duration             => 4,
expiration           => 30,
start_time           => '2008-10-01 22:00:00 PST'.
end_time             => '2007812-31 22:00:00 PST',
baseline_name_prefix => 'Friday_Baseline',
template_name        => Friday_Template',
dbid => 1234567899);
end;
SQL> /

Опять-таки, с помощью параметра EXPIRATION задается период времени сохранения базовой линии.

 

Создание отчетов AWR

Oracle предлагает сценарий по имени awrrpt.sql (расположенный в каталоге $ORACLE_HOME/rdbms/admin) для генерации итоговых отчетов о статистике, собранной посредством AWR. Результат запуска сценария awrrpt.sql очень похож на вывод традиционных отчетов Statspack. Чтобы запустить отчет AWR, необходимо иметь привилегии администратора баз данных.


Внимание! Не следует путать отчет AWR с отчетом ADDM, который получается в результате запуска сценария addmrpt.sql. Отчет ADDM также основан на данных снимка AWR, но не только выявляет проблемы в базе данных, но также выдает рекомендации по их разрешению.


При запуске сценария awrrpt.sql потребуется сделать следующие выборы:

  • между HTML и простым текстовым отчетом;
  • указать ID начального и конечного снимков.

Если хотите, можете использовать сценарий awrsqrpt.sql из каталога $ORACLE_HOME/rdbms/admin для генерации отчета, сосредоточенного на производительности единственного оператора SQL на протяжении диапазона идентификаторов снимков. Это может быть подходящий сценарий, если вы пытаетесь анализировать производительность определенного оператора SQL вместо производительности всей базы данных в целом.


Совет. Для получения отчетов AWR в текстовом и HTML-формате также служат, соответственно, функции AWR_REPORT_TEST и AWR_REPORT_HTML (обе принадлежат пакету DBMS_WORKLOAD_REPOSITORY). Однако в Oracle рекомендуют для получения отчета вместо непосредственного вызова этих функций применять сценарий awrrpt.sql (в котором используются две упомянутых функции).


Отчеты AWR содержат объемную информацию, включая следующую:

  • профиль загрузки;
  • пять событий, занявших максимальное время;
  • события ожидания и активность защелок;
  • статистика временной модели;
  • статистика операционной системы;
  • операторы SQL, упорядоченные по времени;
  • статистика табличных пространств и ввода-вывода;
  • статистика PGA и советников.

Вот как можно создать типичный отчет AWR. Сначала запустите сценарий awrrpt.sql, как показано ниже: 

SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql
Current Instance
~~~~~~~~~~~~~~~~
DB Id        DB Name   Inst Num  Instance
-----------  --------  --------  ------------
877170029    ORCL         1         orcl

На следующем шаге специфицируйте тип отчета, как показано в листинге 2 ниже:


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'
Enter value for report_type: text
Type Specified: text
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id          Inst Num   DB Name        Instance       Host
------------   --------   ------------   ------------   ------------
* 877170029           1   ORCL           orcl           prod5
Using 877170029 for database Id
Using 1 for instance number 

Затем специфицируйте диапазон, который должен охватить отчет AWR, указав начальный и конечный снимки периода времени, который был выбран (см. листинг 3 ниже). 


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
Instance       DB Name    Snap Id       Snap Started         Snap Level
-----------  -----------  --------  -----------------------  ----------
orcl            ORCL      3254        30 Mar 2008 00:00           1
                          3307        01 Apr 2008 05:00           1
                          3308        01 Apr 2008 06:00           1
                          3309        01 Apr 2008 07:00           1
                          3310        01 Apr 2008 08:01           1
                          3311        01 Apr 2008 09:00           1
                          3312        01 Apr 2008 10:00           1
                          3313        01 Apr 2008 11:00           1
Specify the Begin and End Snapshot Ids
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 3309
Begin Snapshot Id specified: 3309
Enter value for end_snap: 3313
End Snapshot Id specified: 3313
Specify the Report Name

И, наконец, укажите имя отчета, как показано в листинге 4 ниже. Для отчета AWR можно либо выбрать имя по умолчанию, либо задать собственное.


The default report file name is awrrpt_1_3309_3313.txt. To use this name,
press  to continue, otherwise enter an alternative.
Enter value for report_name:
Using the report name awrrpt_1_3309_3313.txt
WORKLOAD REPOSITORY report for
DB Name       DB Id       Instance     Inst Num    Release     Cluster   Host
---------   ---------   ------------   --------   ----------   -------   ---------
ORCL        877170026       orcl          1       11.1.0.6.0     NO      prod2
Snap Id              Snap     Time                    Sessions           Curs/Sess
                ---------     -------------------     --------       -------------
Begin Snap:          3309     01-Apr-08 07:00:28           480             7,795.3
End Snap:            3313     01-Apr-08 11:00:58         1,179             3,239.7
Elapsed:                          240.49 (mins)
DB Time:                        7,999.88 (mins) 

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

Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache:       2,304M          Std Block Size:      8K
Shared Pool Size:   1,424M          Log Buffer:      4,096K 

Сегмент Load Profile (Профиль загрузки) отчета AWR, показанный в листинге 5 ниже, показывает объем логических и физических чтений в базе данных за период между выбранными двумя снимками, а также количество разборов, выполнений и транзакций. Анализ загрузки показан как по секундам, так и по транзакциям. Этот раздел должен дать краткое представление о загрузке экземпляра, и будет более полезным, если вы имеете некоторую базовую линию за репрезентативный период, чтобы было с чем сравнить. 


Load Profile            Per Second   Per Transaction
---------------------  -----------  ----------------
Redo size:              209,042.04         19,549.50
Logical reads:          181,753.19         16,997.46
Block changes:            1,470.90            137.56
Physical reads:           6,473.32            605.38
Physical writes:             46.45              4.34
User calls:               2,189.05            204.72
Parses:                     225.36             21.08
Hard parses:                  1.93              0.18
Sorts:                    2,462.09            230.25 
Logons:                       0.91              0.09
Executes:                 2,224.24            208.01

Сегмент Instance Efficiency (Эффективность экземпляра), показанный ниже, отображает коэффициенты попадания в буферный кэш, библиотечный кэш, а также процент сортировки в памяти. Если это значение низкое, вы должны исследовать, почему значительная часть сортировки происходит на диске. 

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %: 99.91         Redo NoWait %: 100.00
               Buffer Hit %: 96.44      In-memory Sort %: 100.00
              Library Hit %: 99.81          Soft Parse %: 99.14
         Execute to Parse %: 89.87           Latch Hit %: 99.55
Parse CPU to Parse Elapsd %: 29.23 %       Non-Parse CPU: 99.04

Раздел Top 5 Timed Events (Пять событий, занявших максимальное время) показывает ситуацию ожидания в вашем экземпляре за указанный период. В следующем примере большая часть случаев ожидания экземпляра связана с пользовательским вводом-выводом:

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                              % Total
Event                                Waits         Time (s)     DB Time   Wait Class
-----------------------------   ----------    -------------   ---------   ----------
db file sequential read         30,650,078          308,185       64.21     User I/O
CPU time                                             63,520       13.23
db file scattered read           3,641,607           34,740        7.24     User I/O
read by other session            2,256,127           15,262        3.18     User I/O
wait for SGA component shrink       14,012           14,079        2.93        Other

Раздел Time Model Statistics (Статистика временной модели) показывает, на что тратится время экземпляра, как это видно в листинге 6 ниже:


Time Model Statistics DB/Inst: ORCL/orcl Snaps: 3309-3313
-> ordered by Time (seconds) desc
                                                  Time %       Total
Statistic Name                                 (seconds)     DB Time
----------------------------------------- -------------- -----------
DB time                                        10,860.27      100.00
sql execute elapsed time                        9,989.24       91.98
DB CPU                                          6,605.53       60.82
background elapsed time                         1,693.64       15.59
parse time elapsed                                991.06        9.13
hard parse elapsed time                           977.66        9.00
background cpu time                               837.48        7.71
PL/SQL compilation elapsed time                   385.77        3.55
Java execution elapsed time                       268.49        2.47
PL/SQL execution elapsed time                     246.51        2.27
failed parse elapsed time                          84.06         .77
inbound PL/SQL rpc elapsed time                    43.14         .40
connection management call elapsed time            17.47         .16
hard parse (sharing criteria) elapsed time          4.25         .04
hard parse (bind mismatch) elapsed time              .50         .00 

Просмотреть операторы SQL можно в разделе SQL Ordered by Elapsed Time (Операторы SQL, упорядоченные по времени). Этот раздел отчета (см. листинг 7 ниже) показывает основные операторы SQL, выполненные за период анализа, упорядоченные по общему затраченному времени, времени процессора и проценту общего времени БД. 


SQL ordered by Elapsed Time DB/Inst: ORCL/orcl Snaps: 3309-3313
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> % Total DB Time is the Elapsed Time of the SQL statement divided
into the Total Database Time multiplied by 100
Elapsed       CPU                  Elap per % Total
Time (s)    Time (s)  Executions   Exec (s) DB Time     SQL Id
---------- --------- ------------ --------- ------- -------------
15,970       3,769        24         665.4    3.3   dvycj85pfmb1b
Module: PRNTREPORT
UPDATE UNIT_USERS UR SET UR.CARD_PRINTED_FLAG = 'Y' WHERE UR.CHARTER_ID IN
(SELECT DISTINCT CHARTER_ID FROM PS_LASER_CARDS WHERE BATCH_ID = :B1 ) AND UR.P
OSNTYP_CODE IN ('V','M','O') AND UR.POSN_CODE NOT IN ('AP','IH') AND UR.REGISTRA
NT_STATUS IN ('X','R','N') AND UR.CARD_PRINTED_FLAG = 'N'

Ниже показана статистика операционной системы:

Operating System Statistics
Statistic Name                                    Value
-----------------------------------  ------------------
AVG_BUSY_TICKS                                  989,293
AVG_IDLE_TICKS                                1,971,976
AVG_IOWAIT_TICKS                                125,186
AVG_SYS_TICKS                                   447,993
AVG_USER_TICKS                                  540,353
BUSY_TICKS                                   15,845,441
IDLE_TICKS                                   31,567,835 

Раздел Segments by Physical Reads (Сегментов по физическим чтениям), показанный в листинге 8 ниже, перечисляет объекты базы данных (таблицы и индексы), которые имеют самый высокий процент физических чтений.


На заметку! Выше было описано только несколько категорий информации, содержащейся в типичном отчете AWR. Для получения полной картины производительности вашего экземпляра за определенный период времени запустите сценарий awrrpt.sql. В дополнение к информации, перечисленной выше, вы получите важную информацию об ожидании, а также детальный анализ логических и физических чтений, основанный на операторах SQL, а также по каждому из файлов данных.


 


Segments by Physical Reads DB/Inst: ORCL/orcl Snaps: 3309-3313
         Tablespace                          Subobject    Obj.      Physical
Owner    Name         Object Name            Name         Type         Reads   %Total
------   ----------   --------------------   ----------   -----   ----------   ------
PAS      UNIT_REGIS   UNIT_REGISTRANTS                    TABLE   18,003,616    21.08
PAS      CAMPAIGN_P   CAMPAIGN_POSITIONS                  TABLE   15,319,556    17.94
PAS      OT_D01       PAYMENT_CATEGORY_BAT                TABLE   11,799,007    13.81
PAS      PERSONNEL_D PERSONNEL                            TABLE    7,189,914     8.42
           ---------------------------------------------------------------------
. . .
End of Report

 

Управление статистикой AWR через представления словаря данных

Наилучший способ просмотра данных AWR состоит в использовании OEM Database Control. Разумеется, можно также запустить сценарий awrrpt.sql, как было показано выше, и просмотреть итоговые данные AWR.

При просмотре данных AWR особенно полезны следующие представления словаря данных.

  • Представление DBA_HIST_SNAPSHOT показывает все снимки, сохраненные в AWR.
  • Представление DBA_HIST_WR_CONTROL показывает все управляющие настройки AWR.
  • Представление DBA_HOST_BASELINE показывает базовые линии с их идентификаторами начального и конечного снимков.

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

Настройка производительности э...
Настройка производительности э... 3012 просмотров Antoniy Mon, 29 Jan 2018, 17:37:48
Создаем отчет Oracle AWR и про...
Создаем отчет Oracle AWR и про... 2836 просмотров Antoniy Tue, 21 Nov 2017, 13:17:28
Настройка памяти базы данных O...
Настройка памяти базы данных O... 10082 просмотров Stas Belkov Sat, 07 Jul 2018, 15:44:14
Настройка производительности б...
Настройка производительности б... 2744 просмотров Александров Попков Fri, 19 Jan 2018, 08:41:00
Войдите чтобы комментировать

1dz аватар
1dz ответил в теме #8894 28 янв 2018 08:30
Отчеты AWR - непревзойденное средство для анализа при настройки производительности баз данных Oracle. В обязательном порядке применяем его при анализа нагрузки, оптимизации и настройке базы.