oracle awr что это
AWR: насколько «экзадатится» работа базы данных?
Этим небольшим постом хотелось бы развеять одно недоразумение, связанное с анализом AWR баз данных, работающих на Oracle Exadata. Почти 10 лет я постоянно сталкиваюсь с вопросом: каков вклад Exadata Software в производительность? Или с использованием новообразованных слов: насколько «экзадатится» работа той или иной базы данных?
Часто на этот правильный вопрос, на мой взгляд, дается неверный ответ со ссылкой на статистику AWR. В ней представлен метод системных ожиданий, трактующий время отклика как сумму времени работы процессоров (DB CPU) и времени ожиданий различных классов.
С появлением Exadata в статистике AWR появились специфичные системные ожидания, связанные с работой Exadata Software. Как правило названия таких ожиданий начинаются со слова “cell” (ячейкой называется Exadata Storage сервер), из них чаще всего встречаются ожидания с говорящими названиями “cell smart table scan”, “cell multiblock physical read” и “cell single block physical read”.
В большинстве случаев доля таких Exadata-ожиданий в общем времени отклика мала, и поэтому они даже не попадают в секцию Top10 Foreground Events by Total Wait Time (в этом случае их нужно искать в разделе Foreground Wait Events). Мы с большим трудом обнаружили у наших заказчиков пример суточного AWR, в котором Exadata-ожидания попали в секцию Top10 и в сумме составили около 5%:
Event
Waits
Total Wait Time (sec)
Avg Wait
% DB time
Wait Class
SQL*Net more data from dblink
cell single block physical read
Sync ASM rebalance
cell multiblock physical read
SQL*Net message from dblink
cell smart table scan
direct path read temp
Из подобной AWR статистики часто делают такие выводы:
1. Вклад магии Exadata в производительность базы данных не высок — не превышает 5 %, а база данных «экзадатится» плохо.
2. Если такую базу перенести с Exadata на классическую архитектуру «сервер + массив», то производительность изменится не сильно. Потому что даже если этот массив окажется втрое медленнее системы хранения Exadata (что едва ли возможно для современных All Flash массивов), то умножив 5% на три мы получим увеличение доли ожиданий ввода-вывода до 15% — такое база данных наверняка переживет!
Оба этих вывода неточные, более того они искажают понимание идеи, заложенной в Exadata Software. Exadata не просто обеспечивает быстрый ввод-вывод, она работает принципиально иначе по сравнению с классической архитектурой «сервер + массив». Если работа базы данных действительно «экзадатится» — то на систему хранения переносится SQL-логика. Storage серверы благодаря ряду специальных механизмов (в первую очередь Exadata Storage Indexes, но не только) сами находят нужные данные и пересылают DB северам. Они делают это достаточно эффективно, поэтому доля характерных Exadata-ожиданий в общем времени отклика мала.
Как изменится эта доля вне Exadata? Как это скажется на производительности базы данных в целом? Лучше всего на эти вопросы ответит тестирование. Например, ожидание “cell smart table scan” вне Exadata может превратиться в такой тяжелый Table Full Scan, что ввод-вывод займет все время отклика и производительность ухудшится драматически. Именно поэтому неправильно при анализе AWR считать суммарный процент ожиданий Exadata вкладом ее магии в производительность и тем более использовать этот процент для прогнозирования производительности вне Exadata. Чтобы понять насколько «экзадатится» работа базы нужно изучать статистики AWR секции “Instance Activity Stats” (там много статистик с говорящими названиями) и сравнивать их между собой.
А чтобы понять, как будет себя чувствовать база данных вне Exadata, лучше всего сделать из бекапа клон базы на целевой архитектуре и проанализировать производительность этого клона под нагрузкой. Такая возможность у обладателей Exadata, как правило, есть.
Автор: Алексей Струченко, руководитель направления БД «Инфосистемы Джет»
Oracle awr что это
� ������� ��� ����� ���������� ������� ��� ������
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:
Instances in this Workload Repository schema srw1inst, srw2inst,
Enter value for num_days:
������ ����� ����������� ����� � ���� � ������� ���. ��������� ������ �������� ��������� ������: 
������ ���� �������� ���������� � ������� Snap shot detail 
Instance Efficiency Percentages(������������� ���������� � ���������) 
��� 5 foreground ��������� �������� ������� ������ ��� ������ ����������� ������� ������������������.
SQL Ordered by CUP Time.
��� �������� �� ������������� �������� ���������� 
Oracle AWR: статистика рабочей нагрузки, snapshot и производительность базы
Динамические представления производительности 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 предоставляет статистику производительности в двух форматах.
MMON — это фоновый процесс, который выполняет большинство связанных с управлением задач, включая генерацию сигналов тревоги базы данных и захват статистики для недавно модифицированных объектов базы данных. Процесс MMON регулярно передает версию статистики AWR, находящуюся в памяти, на диск (в виде снимков).
Администраторы баз данных Oracle традиционно нуждались в поддержке специальных таблиц для сбора хронологических данных о производительности. AWR автоматически собирает статистику по производительности и поддерживает хронологические данные для анализа. Можно просматривать данные снимков с помощью представлений V$ или создавать отчеты для последующего детального изучения. Различные компоненты и средства базы данных используют информацию из этих снимков AWR для мониторинга и диагностики проблем производительности. Например, как было показано в одном из блогов, средство ADDM полагается на эти снимки (snapshots) при диагностике проблем с производительностью. Вдобавок советники SQL Tuning Advisor, Undo Advisor и Segment Advisor также используют данные AWR.
Типы данных, накапливаемых AWR
Средство AWR собирает огромное количество статистики производительности, включая приведенную в следующем списке.
Как объяснялось в этой заметке в блогах, ADDM автоматически запускается после каждого снимка AWR, анализируя период времени между двумя последними снимками. Сравнивая, к примеру, разницу в статистике между снимками, ADDM узнает, какие операторы SQL больше всего нагружают систему. Затем ADDM сосредоточивается на этих операторах.
Обработка данных AWR
Важно понимать, что AWR не является постоянным репозиторием для хранения статистики производительности Oracle. По умолчанию AWR ежечасно фиксирует статистику производительности и сохраняет ее в течение восьми дней. В Oracle оценивают, что примерно за десять сеансов эти установки по умолчанию потребуют около 200 — 300 Мбайт пространства для хранения данных 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, как показано ниже:
Для удаления диапазона снимков служит процедура DROP_SNAPSHOT. При уничтожении набора снимков Oracle автоматически сбрасывает данные AWR, являющиеся частью заданного диапазона. В следующем примере уничтожаются все снимки, идентификаторы которых попадают в диапазон от 40 до 60:
Совет. В случае установки интервала снимков в ноль 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 (Редактирование настроек), где можно модифицировать следующие настройки:
В разделах Manage Snapshots and Baselines главной страницы AWR первая строка показывает общее количество снимков. Эта строка является ссылкой, на которой можно щелкнуть, чтобы попасть на страницу Manage Snapshots (Управление), где перечислены все снимки AWR. Щелчок на индивидуальном снимке приводит к отображению подробных сведений о нем, включая время захвата и уровень сбора. На рисунке 2 ниже показаны подробности об одном снимке AWR. Если установлена базовая линия AWR (репрезентативный период времени), вы также увидите сравнение определенного снимка с этой базовой линией. На странице Manage Snapshots можно выполнять следующие операции.
На заметку! Диапазон снимков, который используется для базовой линии — то же самое, что и зафиксированный (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:
Уничтожается базовая линия с помощью процедуры DROP_BASELINE из пакета DBMS_WORKLOAD_REPOSITORY:
Установка параметра 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:
В 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:
Шаблон однократной базовой линии создаст базовую линию AWR, охватывающую период между 10 вечера 31 декабря 2008 г. и 8 утра 1 января 2009 г. Показанный здесь пример создает шаблон для одиночного периода времени в будущем. По умолчанию базовые линии AWR никогда не устаревают. Однако можно специфицировать параметр EXPIRATION, чтобы установить временной период, на протяжении которого будет действительна базовая линия, т.е. количество дней, в течение которых база данных будет поддерживать эту базовую линию. В примере параметр EXPIRATION имеет значение, равное 30 дням.
Шаблоны повторяемых базовых линий
Шаблон повторяемой базовой линии создает многократно воспроизводимую базовую линию с временным интервалом, который повторяется на протяжении заданного времени, например, каждую пятницу с 10 утра до 12 ночи, на протяжении 2008 г. Вот как можно создать шаблон повторяемой базовой линии:
Опять-таки, с помощью параметра EXPIRATION задается период времени сохранения базовой линии.
Создание отчетов AWR
Oracle предлагает сценарий по имени awrrpt.sql (расположенный в каталоге $ORACLE_HOME/rdbms/admin) для генерации итоговых отчетов о статистике, собранной посредством AWR. Результат запуска сценария awrrpt.sql очень похож на вывод традиционных отчетов Statspack. Чтобы запустить отчет AWR, необходимо иметь привилегии администратора баз данных.
Внимание! Не следует путать отчет AWR с отчетом ADDM, который получается в результате запуска сценария addmrpt.sql. Отчет ADDM также основан на данных снимка AWR, но не только выявляет проблемы в базе данных, но также выдает рекомендации по их разрешению.
При запуске сценария awrrpt.sql потребуется сделать следующие выборы:
Если хотите, можете использовать сценарий awrsqrpt.sql из каталога $ORACLE_HOME/rdbms/admin для генерации отчета, сосредоточенного на производительности единственного оператора SQL на протяжении диапазона идентификаторов снимков. Это может быть подходящий сценарий, если вы пытаетесь анализировать производительность определенного оператора SQL вместо производительности всей базы данных в целом.
Совет. Для получения отчетов AWR в текстовом и HTML-формате также служат, соответственно, функции AWR_REPORT_TEST и AWR_REPORT_HTML (обе принадлежат пакету DBMS_WORKLOAD_REPOSITORY). Однако в Oracle рекомендуют для получения отчета вместо непосредственного вызова этих функций применять сценарий awrrpt.sql (в котором используются две упомянутых функции).
Отчеты AWR содержат объемную информацию, включая следующую:
Вот как можно создать типичный отчет AWR. Сначала запустите сценарий awrrpt.sql, как показано ниже:
На следующем шаге специфицируйте тип отчета, как показано в листинге 2 ниже:
Затем специфицируйте диапазон, который должен охватить отчет AWR, указав начальный и конечный снимки периода времени, который был выбран (см. листинг 3 ниже).
И, наконец, укажите имя отчета, как показано в листинге 4 ниже. Для отчета AWR можно либо выбрать имя по умолчанию, либо задать собственное.
Первая значимая часть отчета AWR показывает размер буферного кэша и разделяемого пула:
Сегмент Load Profile (Профиль загрузки) отчета AWR, показанный в листинге 5 ниже, показывает объем логических и физических чтений в базе данных за период между выбранными двумя снимками, а также количество разборов, выполнений и транзакций. Анализ загрузки показан как по секундам, так и по транзакциям. Этот раздел должен дать краткое представление о загрузке экземпляра, и будет более полезным, если вы имеете некоторую базовую линию за репрезентативный период, чтобы было с чем сравнить.
Сегмент Instance Efficiency (Эффективность экземпляра), показанный ниже, отображает коэффициенты попадания в буферный кэш, библиотечный кэш, а также процент сортировки в памяти. Если это значение низкое, вы должны исследовать, почему значительная часть сортировки происходит на диске.
Раздел Top 5 Timed Events (Пять событий, занявших максимальное время) показывает ситуацию ожидания в вашем экземпляре за указанный период. В следующем примере большая часть случаев ожидания экземпляра связана с пользовательским вводом-выводом:
Раздел Time Model Statistics (Статистика временной модели) показывает, на что тратится время экземпляра, как это видно в листинге 6 ниже:
Просмотреть операторы SQL можно в разделе SQL Ordered by Elapsed Time (Операторы SQL, упорядоченные по времени). Этот раздел отчета (см. листинг 7 ниже) показывает основные операторы SQL, выполненные за период анализа, упорядоченные по общему затраченному времени, времени процессора и проценту общего времени БД.
Ниже показана статистика операционной системы:
Раздел Segments by Physical Reads (Сегментов по физическим чтениям), показанный в листинге 8 ниже, перечисляет объекты базы данных (таблицы и индексы), которые имеют самый высокий процент физических чтений.
На заметку! Выше было описано только несколько категорий информации, содержащейся в типичном отчете AWR. Для получения полной картины производительности вашего экземпляра за определенный период времени запустите сценарий awrrpt.sql. В дополнение к информации, перечисленной выше, вы получите важную информацию об ожидании, а также детальный анализ логических и физических чтений, основанный на операторах SQL, а также по каждому из файлов данных.
Управление статистикой AWR через представления словаря данных
Наилучший способ просмотра данных AWR состоит в использовании OEM Database Control. Разумеется, можно также запустить сценарий awrrpt.sql, как было показано выше, и просмотреть итоговые данные AWR.
При просмотре данных AWR особенно полезны следующие представления словаря данных.