Динамические представления производительности 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.
Скользящее окно базовой линии
База данных всегда поддерживает определенное системой скользящее окно базовой линии. Размер окна соответствует текущему периоду базовой линии 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 показывает базовые линии с их идентификаторами начального и конечного снимков.
