Как читать awr отчет oracle
Обновлено: 04.07.2024
select * from (
select begin_snap, end_snap, timestamp begin_timestamp, inst, a/1000000/60 DBtime from
(
select
e.snap_id end_snap,
lag(e.snap_id) over (order by e.snap_id) begin_snap,
lag(s.end_interval_time) over (order by e.snap_id) timestamp,
s.instance_number inst,
e.value,
nvl(value-lag(value) over (order by e.snap_id),0) a
from dba_hist_sys_time_model e, DBA_HIST_SNAPSHOT s
where s.snap_id = e.snap_id
and e.instance_number = s.instance_number
and to_char(e.instance_number) like to_char(e.instance_number)
and stat_name = 'DB time'
)
where begin_snap between 0 and 99999999
and begin_snap=end_snap-1
order by dbtime desc
)
where rownum < 31
Создаются автоматически:
BEGIN
DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
retention => XXXX, - Сколько времени хранить (в минутах)
interval => XX); - С каким интервалом создавать (в минутах)
END;
/
BEGIN
DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
retention => 43200, -- Minutes (= 30 Дней)
interval => 30); -- Minutes
END;
/
STATISTICS_LEVEL = TYPICAL or ALL
Параметры изменяются так:
select snap_interval
, retention
from dba_hist_wr_control
/
exec dbms_workload_repository.modify_snapshot_settings (retention => 14*24*60) //14 дней
execute dbms_workload_repository.modify_snapshot_settings(interval => 0);
execute dbms_workload_repository.modify_snapshot_settings(interval => 60);
Руками создаются так:
BEGIN DBMS_WORKLOAD_REPOSITORY.create_snapshot('ALL'); END;
select DBMS_STATS.GET_STATS_HISTORY_RETENTION from dual;
begin
DBMS_STATS.ALTER_STATS_HISTORY_RETENTION (7);
end;
begin
DBMS_STATS.PURGE_STATS(to_timestamp_tz('01-09-2007 00:00:00 Europe/Moscow','DD-MM-YYYY HH24:MI:SS TZR'));
end;
Удаляются так:
BEGIN
DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range (
low_snap_id => 22,
high_snap_id => 32);
END;
/
По умолчанию (TYPICAL)
EXECUTE DBMS_WORKLOAD_REPOSITORY.create_snapshot();
Отчеты формируются так:
SELECT
output
FROM
TABLE
(dbms_workload_repository.awr_report_text
(Db_Id, Instance_num, Snap_begin, Snap_end)
);
Например так (в формате html):
План выполнения можно посмотреть так:
select * from TABLE(dbms_xplan.display_awr('8s9npcpzjkzst'));
Отключить сбор снапшотов AWR можно так:
execute dbms_workload_repository.modify_snapshot_settings(interval => 0);
Включить сбор снапшотов AWR с интервалом в 1 час можно так:
execute dbms_workload_repository.modify_snapshot_settings(interval => 60);
Установить политику хранения снапшотов можно так:
exec dbms_workload_repository.modify_snapshot_settings (retention => 14*24*60) //14 дней
Посмотреть текущие значения настроек можно так:
select dbid, snap_interval, retention from sys.wrm$_wr_control
(собирать каждые 15 мин. и хранить один день):
execute dbms_workload_repository.modify_snapshot_settings(interval => 15);
exec dbms_workload_repository.modify_snapshot_settings (retention => 1*24*60)
Many Ways to Disable AWR:
select * from nls_session_parameters
alter session set nls_date_format = 'DD-MM-YYYY';
alter session set nls_date_format='DD-MON-YYYY';
alter session set nls_language=AMERICAN;
ASH - report
select
output
from
table
(dbms_workload_repository.ash_report_html
(4138903833,1,to_date('11-04-2017 08:10:00','DD-MM-YYYY HH24:MI:SS'), to_date('11-04-2017 09:10:00','DD-MM-YYYY HH24:MI:SS')));
ADDM - report
SET LINESIZE 120
COLUMN begin_interval_time FORMAT A30
COLUMN end_interval_time FORMAT A30
COLUMN startup_time FORMAT A30
SELECT snap_id, begin_interval_time, end_interval_time, startup_time
FROM dba_hist_snapshot
WHERE begin_interval_time > TRUNC(SYSTIMESTAMP)
ORDER BY snap_id;
SNAP_ID BEGIN_INTERVAL_TIME END_INTERVAL_TIME STARTUP_TIME
---------- ------------------------------ ------------------------------ ------------------------------
1770 06-JUL-2015 00:00:54.031 06-JUL-2015 01:00:58.011 03-JUL-2015 11:13:51.000
1771 06-JUL-2015 01:00:58.011 06-JUL-2015 02:00:02.167 03-JUL-2015 11:13:51.000
1772 06-JUL-2015 02:00:02.167 06-JUL-2015 03:00:06.332 03-JUL-2015 11:13:51.000
1773 06-JUL-2015 03:00:06.332 06-JUL-2015 04:00:10.573 03-JUL-2015 11:13:51.000
1774 06-JUL-2015 04:00:10.573 06-JUL-2015 05:00:14.648 03-JUL-2015 11:13:51.000
1775 06-JUL-2015 05:00:14.648 06-JUL-2015 06:00:18.690 03-JUL-2015 11:13:51.000
1776 06-JUL-2015 06:00:18.690 06-JUL-2015 07:00:22.717 03-JUL-2015 11:13:51.000
1777 06-JUL-2015 07:00:22.717 06-JUL-2015 08:00:27.209 03-JUL-2015 11:13:51.000
1778 06-JUL-2015 08:00:27.209 06-JUL-2015 09:00:31.694 03-JUL-2015 11:13:51.000
1779 06-JUL-2015 09:00:31.694 06-JUL-2015 10:00:36.238 03-JUL-2015 11:13:51.000
1780 06-JUL-2015 10:00:36.238 06-JUL-2015 11:00:40.915 03-JUL-2015 11:13:51.000
1781 06-JUL-2015 11:00:40.915 06-JUL-2015 12:00:45.594 03-JUL-2015 11:13:51.000
1782 06-JUL-2015 12:00:45.594 06-JUL-2015 13:00:49.954 03-JUL-2015 11:13:51.000
1783 06-JUL-2015 13:00:49.954 06-JUL-2015 14:00:54.322 03-JUL-2015 11:13:51.000
1784 06-JUL-2015 14:00:54.322 06-JUL-2015 15:00:58.984 03-JUL-2015 11:13:51.000
1785 06-JUL-2015 15:00:58.984 06-JUL-2015 16:00:03.464 03-JUL-2015 11:13:51.000
CONN sys@cdb1 AS SYSDBA
DECLARE
l_task_name VARCHAR2(30) := '1783_1785_addm_db';
BEGIN
DBMS_ADDM.analyze_db (
task_name => l_task_name,
begin_snapshot => 1783,
end_snapshot => 1785);
END;
/
ANALYZE_INST
CONN sys@cdb1 AS SYSDBA
DECLARE
l_task_name VARCHAR2(30) := '1783_1785_addm_inst';
BEGIN
DBMS_ADDM.analyze_inst (
task_name => l_task_name,
begin_snapshot => 1783,
end_snapshot => 1785,
instance_number => 1);
END;
/
SET LONG 1000000 LONGCHUNKSIZE 1000000
SET LINESIZE 1000 PAGESIZE 0
SET TRIM ON TRIMSPOOL ON
SET ECHO OFF FEEDBACK OFF
SELECT DBMS_ADDM.get_report('1783_1785_addm_db') FROM dual;
BEGIN
DBMS_ADDM.delete('1783_1785_addm_db');
END;
/
Miscellaneous
INSERT_FINDING_DIRECTIVE : Limit reporting for a specific finding.
INSERT_PARAMETER_DIRECTIVE : Prevent ADDM from creating actions to alter a specific parameter.
INSERT_SEGMENT_DIRECTIVE : Prevent ADDM from creating actions to run the Segment Advisor for specific segments.
INSERT_SQL_DIRECTIVE : Limit reporting of actions on specific SQL.
DELETE_FINDING_DIRECTIVE : Delete a finding directive.
DELETE_PARAMETER_DIRECTIVE : Delete a parameter directive.
DELETE_SEGMENT_DIRECTIVE : Delete a segment directive.
DELETE_SQL_DIRECTIVE : Delete an SQL directive.
1.Что такое AWR отчеты
2. Для чего используются AWR отчеты
3. Построение AWR отчетов
4. Системные представления AWR репозитория отчетов
5. AWR отчет в формате HTML
6. Основные параметры отчетов AWR
7. На что еще следует обратить внимание!
1. Что такое AWR отчеты
Automatic Workload Repository представляет из себя набор внутренних таблиц словаря данных БД Oracle и специальный фоновый процесс MMON, который появился в версии Oracle10g.
Периодически AWR создает статистическую копию (снимок) и сохраняет информацию в таблицах расположенных в табличном пространстве SYSAUX. По умолчанию регулярный период сбора установлен на 60 минут. Это значение может быть уменьшено до 10 минут при желании. Механизм сбора статистической копии (awr snapshot) установлен в базе данных 10G по умолчанию и в отличии от пакета statspack установки на автоматический сбор информации не требуется.
Скрипт формирования AWR заполняет специальный AWR репозиторий набор таблиц и представлений словаря данных Oracle помощью специального системного процесса NMON.
2.Для чего используются AWR отчеты
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 отчетов ,так же можно проанализировать, поведение заданного экземпляра БД Oracle в моменты наибольших нагрузок , при подаче трафика с помощью внешних систем При введении новых компонентов приложения , которые потенциально могут повлиять на влияют на работу экземпляров БД Oracle
3.Построение AWR отчетов.
Для построения AWR отчетов в Oracle используется специальный пакет DBMS_WORKLOAD_REPOSITORY , так же сформировать отчет можно с помощью специальных команд Enterprice Manager console.
процедуры пакета DBMS_WORKLOAD_REPOSITORY
СREATE_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 задают минимальное и максимальное время хранения статистики в базе данных соответственно.
для того, чтобы собрать отчет в формате HTML можно воспользоваться уже готовым скриптом входящим в поставку Oracle СУБД - awrrpt.sql
4.Системные представления, AWR репозитория отчетов
В репозитарии отчетов используются следующие системные представления
Вот несколько запросов на основе данных представлений , наиболее часто использующихся в работе
Запрос, возвращающий текущие настройки AWR:
Запрос, возвращающий информацию о всех снимках;
Запрос, который позволяет узнать средний обьем физических чтений данные группируются по часу , аналогично , можно дополнительно сгруппировать данные по дням:
5.AWR отчеты в формате HTML
Формирование AWR отчета осуществляется на сервере , удобнее всего, для этого воспользоваться утилитой sqlplus
В консоли вам будет предложено выбрать тип отчета
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:
по умолчанию выбирается тип HTML , если вам необходим отчет в текстовом формате вы набираете слово text и нажимаете Ввод (Enter)
На экран будет выведен список экземпляров БД для которых вы хотели сформировать отчеты:
Instances in this Workload Repository schema srw1inst, srw2inst,
далее следует вопрос - статистка за какой день вам нужна, вы вводите день который отчаивается от текущей даты или просто нажмете ввод , тогда будут построены все доступные отчеты, либо последний сформированный снимок статистики
Enter value for num_days:
Далее на экран выводится список доступных снимков , где более всего интересно поле SnapId требуется задать начальный идентификатор снимка и конечный идентификатор снимка базы
Enter value for begin_snap: Enter value for end_snap:
то есть например нам необходимы снимки 101 , 102, 103 мы вводим
begin_snap - 101, end_snap 103 (время и дату формирования данных снимков есть в списке)
Дальше вводится имя отчета Enter value for report_name, если же просто нажать Ввод , то имя отчету присваивается автоматически
Через некоторое время в текущей папке формируется awr или txt отчет c соответствующим расширением
например : AWRRPT_2_1111_1112.HTML MYAWR_23213.txt
Теперь можно скопировать отчет к себе и изучить его. Заголовок отчета содержит следующие данные:
Второй блок содержит информацию о снимках Snap shot detail
Load Profile (Профиль загрузки)
В этом блоке есть немного важной статистики для изучения DBA. Во первых DB CPU(s) в секунду. В первую очередь это позволяет нам понять , как работаю процессоры ЦПУ. Предположим, что у Вас есть в системе 12 ядерный процессор .
Статистика представлена в виде таблицы
так же можно посмотреть следующую статистическую информацию которая распределяется (на секунду , на транзакцию , на запрос, на вызов)
Instance Efficiency Percentages(Эффективность экземпляра в процентах)
В этих статистических данных Вы наиболее важный параметр "% Non-Parse CPU". Если это значение - приближается к 100%, значить большинство ресурсов ЦП, используется в различных операциях, кроме парсинга, что говорил правильной работе базы данных. Top 5 Timed Foreground Events (Топ 5 процессов Foreground)
Топ 5 foreground процессов является хорошей точкой для начала диагностики проблем производительности.
Назначение этого блока отчета - показать наиболее значительные события, связанные с расходованием ресурсов Например максимальный % от DB time был затрачен на ожидание буферов в буферном кэше (buffer busy waits). Дополнительные разделы в отчете AWR содержат более детальную информацию, которая помогает диагностировать проблемы производительности. Во первых, следует обратить внимание на значение Waits(ожидание) в классе user i/o и system i/o , Other (пользовательский ввод вывод и системный ввод вывод, другие) Если вы видите класс Конкуренция(Concurrency) то могут возникать серьезные проблемы.
Во-вторых необходимо, проанализировать время Time(s), оно показывает, сколько времени база данных ожидала в данном классе(other, user I/O..), требуется проанализировать время, которое было затрачено в данных классах , затем проанализировать среднее время ожидания (Avg wait) , если общее время (Time(s)) высокое, а среднее время ожидания (Avg waits) низкое , тогда это нормальные параметры производительности.
Если же оба параметра высоки , тогда требуется дополнительный анализ. На снимке экрана выше большая часть ресурсов - это DB CPU , где время БД (% DB time) = 64%. Что, вообщем, является нормальной ситуацией.
CPU и память использованные экземпляром в заданный для отчета период времени (Тime Model Statistics)
Это детальная расшифровка использования системных ресурсов. Данная статистика включает затраченное время и %DB time
Этот отчет показывает, что система 62 и 70% в режиме ожидания то есть записывает данные на диск, Таким образом, в данном случае,нет никакого дефицита ресурсов на системном уровне. Но если вы обнаружили очень высокий %busy , %user или SYS% и это забрало бы ресурсы у idle%. В этом случае, требуется выяcнить причину такой стaтистики.
SQL statistic (Статистика SQL запросов)
Один из наиболее важных разделов AWR отчета , информация о SQL запросах, наиболее значительных с точки зрения потребляемых ресурсов.
SQL Ordered by CUP Time.
Топ запросов по использованию ресурсов процессора
7.На что еще следует обратить внимание!
Кроме загрузки системных ресурсов обязательно требуется просмотр SQL statistic , какие запросы создают максимальную нагрузку и взывают наибольший расход системных ресурсов.
Oracle Database 11g Настройка производительности.
3. Использование автоматического репозитория нагрузки (AWR)
AWR это инфраструктура, которая предоставляет сервисы СУБД Oracle для сбора, управления и использования статистики в процессе идентификации проблем и их автоматического устранения.
- Сбор статистики в памяти - возможность, которая используется различными компонентами для сбора статистики. Эта статистика хранится в памяти из соображений производительности. Статистика, хранящаяся в памяти доступна через представления производительности V$.
- AWR snapshot - снимки памяти, позволяющие анализировать что происходило раньше. AWR снэпшоты доступны через представления словаря данных (DBA) и в Enterprise Manager Database Control.
- Статистика должна сохраниться в случае отказа экземпляра.
- Исторические данные для сравнения опорных линий необходимы для определенных типов аналитики
- Защита от переполнения памяти: Когда старая статистика заменяется новой ввиду малого объема памяти, замещаемые данные могут быть сохранены для дальнейшего использования.
Данные, хранящиеся в автоматическом репозитории нагрузки (AWR)
AWR собирает разные типы статистики. AWR хранит базовую статистику, то есть, счетчики и значения статистики (например отметку о переключении журналов и процесс выделения памяти). AWR собирает SQL статистику такую как чтение дисков в SQL выражении. Метрики, такие как количество физических чтений в минуту также собираются AWR.
Active Session History (ASH) сначала захватываются из памяти с интервалом в секунду только для в настоящее время активных сессий. Затем данные ASH сокращаются в десятки раз, сохраняя на диск случайную выборку данных из оперативной памяти. Данные ASH активно используются компонентом Automatic Database Diagnostic Monitor (ADDM) для выявления причин падения производительности.
Отчеты, сгенерированные ADDM, Segment Advisor, и другими также хранятся в AWR для дальнейшего использования.
Статистика, хранящаясяв AWR делится на 2 типа: статистика хранящаяся в памяти, которой можно получить доступ через представления V$ и историческая или постоянная статистика, доступ к которой можно получить через представления DBA_*.
- Репозиторий нагрузки - это постоянный набор статистики производительности, собирающийся за определенный период времени и принадлежащий пользователю SYS. Репозиторий нагрузки хранится в табличном пространстве SYSAUX и занимает в нем одно из самых главных мест.
- Снимок (Snapshot) - это набор статистики производительности собраный в определенный период времени. Снимки используются для подсчета рейтингов и отслеживания на их основе изменений в производительности экземпляра в течение какого то времени. Каждый Снимок помечается номером, выделяемым последовательностью (snap_id), который является уникальным в рамках репозитория нагрузки.
- По умолчанию снимки создаются каждые 60 минут. Вы можете уменьшить частоту создания снимков изменив параметр INTERVAL. Поскольку внутренние процессы advisor используют эти снимки помните, что увеличение интервала между снимками может повлиять на точность измерений при диагностике. Например установив интервал в 4 часа, можно пропустить всплески на графике, которые будут заметны при интервале в 1 час.
- В Real Application Clusters окружении каждый снимок охватывает все экземпляры БД в кластере. Снимки на каждом узле кластера используют один snap_id и идентифицируются по Instance ID.
- Вы можете сделать снимок вручную используя Database Control. Ручное создание снимка поддерживается в связке с автоматическими снимками, генерируемыми системой. Наиболее распространенное применение ручных снимков - ситуация, когда вам необходимо получить снимок состояния системы между двумя специфическими точками во времени, которые не совпадают с временем в автоматически сгенерированных снимках.
Используя Database Control, вы можете сконфигурировать параметры RETENTION и INTERVAL.
Вы контролируете количество исторических данных в AWR установкой периода хранения и интервала снимков. По умолчанию, снимки удаляются автоматически в хронологическом порядке. Снимки, относящиеся к опорным линиям сохраняются до тех пор пока опорная линия не будет удалена или устареет. В системе с 10-ю активными пользователями требуется 200-300 МБ пространства в файле данных для хранения недельных снимков статистики. Потребление дискового пространства зависит напрямую от количества активных сессий в системе. Скрипт utlsyxsz.sql анализирует множество факторов таких например как, размер объектов, расположенных в табличном пространстве SYSAUX, количество активных сессий, частоту создания снимков и время отклика. Скрипт awrinfo.sql генерирует отчет содержащий данные о прогнозируемом размере занятого дискового пространства в SYSAUX. Оба скрипта расположены в директории $ORACLE_HOME/rdbms/admin.
AWR управляет хранением снимков. Каждую ночь процесс MMON очищает снимки, которые старше периода хранения. Если AWR зафиксирует, что закончилось место в табличном пространстве SYSAUX, он автоматически удалит наиболее старые снимки для того, чтобы разместить новые. При этом администратору БД будет направлено уведомление об окончании свободного пространства в SYSAUX.
Параметры снимков устанавливаются и меняются при помощи процедуры MODIFY_SNAPSHOT_SETTINGS. Ниже перечислены параметры, которые можно изменить:
- Период хранения: RETENTION указывается в минутах. Значение по умолчанию - 8 дней.
- INTERVAL между снимками. Минимальное значение - 10 минут, максимальное - 100 лет, Значение по умолчанию - 60 минут.
- Количество SQL, для которых необходимо собирать данные о производительности. Разрешается устанавливать следующие значения: DEFAULT, MAXIMUM, n , где n - это количество SQL выражений, которое можно вычистить при соответствии определенным условиям, таким как время выполнения или CPU time. При указании значения DEFAULT захватывается топ 30, при установке значения параметра STATISTICS_LEVEL = TYPICAL и топ 100 при установке значения ALL для STATISTICS_LEVEL. При указании значения MAXIMUM в снимок AWR захватываются все SQL, хранящиеся в кэше курсоров.
Пакет DBMS_WORKLOAD_REPOSITORY содержит процедуры для управления снимками и опорными линиями. Большинство из процедур, содержащихся в пакете используются Enterprise manager для управления автоматическим репозиторием нагрузки и редко приходится пользоваться ими вручную.
AWR может сгенерировать сводный отчет за весь период, по которому хранятся снимки статистики. Отчет содержит полный снимок поведения системы в период времени, который можно установить, указав начальный и конечный снимок статистики.
Вне зависимости от того, где был создан отчет в SQL*Plus или в EM, он содержит одну и ту же информацию. Скрипт awrrpt.sql, запущенный в SQL*Plus из директории $ORACLE_HOME/rdbms/admin сгенерирует AWR отчет. Для запуска скрипта пользователь должен иметь привилегию SELECT_CATALOG_ROLE. В процессе запуска скрипт запрашивает следуюйщие дополнительные опции:
- Тип отчета: HTML или текстовый
- Число дней з которого нужно выбрать снимки. Указание количества дней показывает наиболее свежие снимки относительно заданного периода времени. Вы также можете определить Snap_id требуемого снимка, запросив соответствующие столбцы таблицы DBA_HIST_SNAPSHOT, содержащие SNAP_ID и временную метку.
- SNAP_ID начального и конечного снимков: Пара снимков, которая определяет период отчета.
- Имя файла: Файл указанный пользователем в который будет записан отчет.
Первая секция AWR отчета представляет следующие диагностические данные:
- Время снимков
- Использование памяти
- Профиль загрузки
- Эффективность экземпляра в процентах
- Топ 5 foreground процессов
- Статистика операционной системы, CPU и память использованные экземпляром в заданный для отчета период времени
Дополнительные разделы в отчете AWR содержат более детальную информацию, которая помогает диагностировать проблемы производительности, указанные в первой секции.
Операция сравнения периодов позволяет указать 2 периода и сравнить исторические показатели производительности в эти периоды между собой.
Вы можете использовать отчет сравнения периодов из репозитория нагрузки для сравнения двух периодов. Если AWR отчет показывает AWR данные между двумя снимками (две точки во времени), то отчет сравнения периодов показывает разницу между двумя периодами (или двумя AWR отчетами, что эквивалентно четырем снимкам).
Использование сравнения периодов позволяет определить детали изменения атрибутов производительности и изменения в конфигурации между двумя периодами во времени. Например, если нагрузка на приложение стабильна в рабочее время, но производительность во вторник резко упала между 10:00 и 11:00 утра, генерация отчета сравнения периодов позволит сравнить период с 10:00 до 11:00 в понедельник и во вторник и тем самым выявить изменения конфигурации, профиля нагрузки и статистики между двумя периодами. Два периода, выбранные для сравнения могут быть разными по продолжительности. Если продолжительность периодов разная, отчеты перед сравнением приводятся к одному значению DB time.
На рисунке выше показана часть отчета сравнения периодов, которая определяет статистику изменений между периодами. Этот отчет сравнивает одну и ту же нагрузку, выполненную на по разному сконфигурированных табличных пространствах. Сравнение может быть основано на показателях за одну секунду и за одну транзакцию. Поскольку нагрузка в разные периоды не отличалась, использование сравнения по транзакциям является наиболее предпочтительным. На данном графике видно, то что в первый период транзакции потребляли значительно больше DB time, чем во второй период. Также отчет сравнения периодов можно сгенерировать запустив скрипт awrddrpt.sql, расположенный в директории $ORACLE_HOME/rdbms/admin.
Секция : Профиль нагрузки
Секция отчета "Профиль нагрузки" очень полезна при сравнении двух периодов. Эта секция позволяет изолировать изменения нагрузки, которые могут вносить в свой вклад в разницу в производительности. В отчете приведенном выше нагрузка одинаковая в оба периода. Изменились только настройки БД. Здесь видно, что показатель DB time за секунду и за транзакцию уменьшился. Показатель количества транзакций в секунду говорит о том что больше задач было выполнено базой данных в один и тот же промежуток времени. В примере приведенном выше явно виден прирост производительности. В большинстве случаев прирост в одной области вызывает простой в другой области и необходимо искать баланс.
Каждый экземпляр, в том числе и хорошо настроенный имеет набор событий ожидания. Эти события ожидания являются потенциальными областями для настройки производительности. В данном случае беспокойство вызывает событие ожидания buffer busy waits, находящееся в верху списка. Это событие ожидания затмевает все остальные события в списке. Во второй период мы можем видеть что событие ожидания buffer busy waits больше не является первым в списке событий ожидания. По предыдущим секциям отчета мы уже знаем что производительность экземпляра была увеличена. Во второй период появилось событие ожидания free buffer waits, а также увеличилось количество событий log file sync, что отразилось на общем времени и DB time. Это наблюдение позволяет провести дальнейшее исследование причин возникновения событий ожидания. Следующим шагом будет просмотр секций, содержащих детальную информацию относительно этих событий ожидания.
В последнее время из-за очень высокой загрузки ЦП базы данных VCS часто переключается автоматически, вызывая много проблем.
Недавно изучал отчет об анализе базы данных и анализ производительности базы данных. Следующее объяснит изначально:
1. Сначала войдите в базу данных и создайте отчет awr. 。
> sqlplus '/as sysdba'
SQL*Plus: Release 11.1.0.6.0 - Production on Sun Apr 7 14:02:38 2013
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
2. Введите команду анализа
SQL> @?/rdbms/admin/awrrpt
DB Id DB Name Inst Num Instance
----------- ------------ -------- ------------
2045388596 UTF8 1 utf8
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: html
3. Введите формат файла отчета, который будет создан
Type Specified: html
Instances in this Workload Repository schema
DB Id Inst Num DB Name Instance Host
------------ -------- ------------ ------------ ------------
* 2045388596 1 UTF8 utf8 linux
Using 2045388596 for database Id
Using 1 for instance number
Specify the number of days of snapshots to choose from
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing <return> without
specifying a number lists all completed snapshots.
4. Введите количество дней между генерируемыми отчетами.
Enter value for num_days: 1
Listing the last day's Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
utf8 UTF8 2809 26 Oct 2014 00:00 1
2810 26 Oct 2014 01:00 1
2811 26 Oct 2014 02:00 1
2812 26 Oct 2014 03:00 1
2813 26 Oct 2014 04:00 1
2814 26 Oct 2014 05:00 1
2815 26 Oct 2014 06:00 1
2816 26 Oct 2014 07:00 1
2817 26 Oct 2014 08:00 1
2818 26 Oct 2014 09:00 1
2819 26 Oct 2014 10:00 1
2820 26 Oct 2014 11:00 1
2821 26 Oct 2014 12:00 1
5. Введите начальный номер Snap Id и конечный номер между разделенными снимками
Specify the Begin and End Snapshot Ids
Enter value for begin_snap: 2809
Enter value for end_snap: 2821
End Snapshot Id specified: 2821
Specify the Report Name
The default report file name is awrrpt_1_2809_2821.html. To use this name,
press <return> to continue, otherwise enter an alternative.
6. Введите имя сгенерированного отчета ：
Enter value for report_name: 20130407awr.html
После получения отчета 20130407awr.html проанализируйте производительность оператора SQL базы данных. Ниже приведено объяснение концепции awr и основного имени анализа (информация, скопированная онлайн, не обязательно верна):
Нашел несколько хороших статей в интернете:
Для объяснения параметров awr, более полная статья
Научитесь использовать функции ORACLE_AWR и ASH
Автоматический репозиторий рабочей нагрузки (AWR) является важным компонентом, представленным 10g. Здесь хранится подробная информация о состоянии активности базы данных за последний период (по умолчанию 7 дней).
1. Генерация отчетов AWR
Войдите в систему как пользователь оракула
sqlplus / as sysdba
@?/rdbms/admin/awrrpt.sql
2. Анализ отчета
SQL ordered by Elapsed Time
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 Time （s）CPU Time （s）Executions Elap per Exec （s） % Total DB TimeSQL IdSQL ModuleSQL Text
Истекшее время (S): общая продолжительность выполнения оператора SQL, эта сортировка выполняется в соответствии с этим полем. Обратите внимание, что это время не времени для отдельного запуска SQL, а общее время выполнения SQL в пределах диапазона мониторинга. Единица времени - секунды. Истекшее время = время процессора + время ожидания
CPU Time (s): это общее время, затрачиваемое CPU на выполнение инструкции SQL. Это время будет меньше или равно истекшему времени. Единица времени - секунды.
Выполнения: общее количество выполнений операторов SQL в диапазоне мониторинга.
Elap per Exec (s): среднее время выполнения SQL один раз. Единица времени - секунды.
% общего времени БД: истекшее время для SQL - это процент от общего времени базы данных.
SQL ID: идентификационный номер оператора SQL. После нажатия вы можете перейти к подробному списку SQL ниже. Нажмите «Вернуться к IE», чтобы вернуться к текущему SQL-идентификатору.
Модуль SQL: Показывает, как SQL подключен к базе данных для выполнения. Если он подключен с помощью SQL * Plus или PL / SQL, в основном это кто-то отлаживает программу. Как правило, расположение sql, выполняемого и связанного приложением переднего плана, пусто.
Текст SQL: простая подсказка SQL, вам нужно щелкнуть SQL ID для подробностей.
SQL ordered by CPU Time
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
CPU Time （s）Elapsed Time （s）Executions CPU per Exec （s）% Total DB TimeSQL IdSQL ModuleSQL Text
записывает TOP SQL с наибольшим общим временем выполнения процессорного времени (обратите внимание, что выполнение этого SQL в пределах диапазона мониторинга занимает общее время процессора, а не время выполнения одного SQL).
SQL ordered by Gets
Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
Total Buffer Gets: 964,486
Captured SQL account for 103.6% of Total
Buffer Gets Executions Gets per Exec %TotalCPU Time （s）Elapsed Time （s）SQL IdSQL ModuleSQL Text
записывает TOP SQL, который выполняет общий буфер, получает (логический IO) (обратите внимание, что выполнение SQL в пределах диапазона мониторинга учитывает сумму Gets, а не Gets, которые заняты одним выполнением SQL).
SQL ordered by Reads
Total Disk Reads: 5,606
Captured SQL account for 168.4% of Total
Physical ReadsExecutionsReads per Exec %TotalCPU Time （s）Elapsed Time （s）SQL IdSQL ModuleSQL Text[nextpage]
записывает TOP SQL, который выполняет общее физическое чтение диска (физический ввод-вывод) (обратите внимание, что выполнение SQL в пределах диапазона мониторинга учитывает общее физическое чтение диска, а не одно выполнение SQL Физический диск прочитан).
SQL ordered by Executions
Total Executions: 20,124
Captured SQL account for 59.3% of Total
Executions Rows ProcessedRows per ExecCPU per Exec （s）Elap per Exec （s） SQL IdSQL ModuleSQL Text
записывает TOP SQL, отсортированный по количеству выполнений SQL. Эта сортировка показывает количество выполнений SQL в пределах диапазона мониторинга.
SQL ordered by Parse Calls
Total Parse Calls: 14,635
Captured SQL account for 69.0% of Total
Parse CallsExecutions % Total ParsesSQL IdSQL ModuleSQL Text
TOP SQL, который записывает количество мягкого анализа SQL.
SQL ordered by Sharable Memory
Only Statements with Sharable Memory greater than 1048576 are displayed
Sharable Mem （b）Executions % TotalSQL IdSQL ModuleSQL Text
. TOP SQL, который записывает размер библиотечного кэша, занимаемого SQL.
Sharable Mem (b): принимает размер кэша библиотеки. Единица байтовая.
SQL ordered by Version Count
Only Statements with Version Count greater than 20 are displayed
Version Count Executions SQL IdSQL ModuleSQL Text
записывает TOP SQL открытого под-курсора SQL.
Вручную изменить план выполнения awr и вручную создавать отчеты
SQL> @? / Rdbms / admin / awrrpt.sql (вы можете перейти к отчету awr между двумя снимками)
Примечание. AWR по умолчанию сохраняет 7-дневный снимок базы данных и генерирует снимок каждый час.
1. Вручную изменить план выполнения AWR
Настройте частоту и стратегию хранения снимков, созданных AWR, например, изменив интервал сбора до 30 минут. И держите это в течение 5 дней (единицы все в минутах):
Во-вторых, тестовая система:
1. Вручную создать снимок в базе данных
2. Откройте производственную систему и нажмите «Сводная информация по одной скважине» более 20 секунд, прежде чем появится страница
3. Сделайте еще один снимок
4. Согласно приведенному выше отчету awr, выясните план выполнения одного SQL-оператора, который занимает много времени
Например: sql id c0yffdyps8uk9 заняло 26 секунд
Entervalueforbegin_snap:1679
BeginSnapshotIdspecified:1679
Entervalueforend_snap:1680
EndSnapshotIdspecified:1680
SpecifytheSQLId
Entervalueforsql_id: (введите c0yffdyps8uk9)
1. Введение в AWR
AWR(Automatic Workload Repository) Это встроенный инструмент, предоставляемый Oracle 10g, который собирает статистику, связанную с производительностью БД, именует таблицы в формате WRM $ _ * и WRH_ *, все таблицы хранятся в режиме SYS в табличном пространстве SYSAUX; отчет AWR - это DBA Важным средством для оценки производительности базы данных и обнаружения проблем SQL.
По умолчанию AWR сохраняет статистику данных за одну неделю, а частоту и время хранения снимков можно настроить вручную.
2. Этапы генерации отчетов AWR
2.1 Используйте инструмент Toad для подключения к интерфейсу генерации отчетов AWR
Database->monitor->ADDM/AWRReports(OEM)
2.2 Выберите период времени для создания снимка и нажмите зеленую кнопку, чтобы выполнить отчет AWR
2.3 Сгенерировать отчет AWR через файл скрипта базы данных, выполнить следующий скрипт
3. Анализ отчета AWR
3.1 Информация заголовка отчета AWR
Elapsed: период времени выборки
Время БД: время, потраченное пользовательскими операциями
DB Time Гораздо меньше, чем прошедшее время База данных простаивает
3.2 AWR загрузить сводную информацию
Размер повтора: указывает на занятость базы данных
Разборы: Менее 300 означает нормально
Жесткий анализ: жесткий анализ, менее 100 означает нормальный
Из приведенных выше данных можно изначально заявить, что пропускная способность и загрузка этой базы данных являются нормальными
3.3 Эффективность экземпляра AWR
Buffer Nowait%: доля ожидаемых данных в памяти
% Попаданий в буфер: менее 80%, вам нужно добавить память
Попадание в библиотеку%: если оно меньше 90%, вам нужно увеличить общий пул
In-memory sort%: коэффициент сортировки памяти, слишком низкая сортировка будет выполняться во временной таблице, вам нужно увеличить PGA
Soft Parse%: убедитесь, что он больше 99%, в противном случае это означает конфликт защелок в пуле общих ресурсов
Приведенные выше данные могут указывать, что частота попаданий экземпляра базы данных находится в нормальном состоянии
3.4 AWR TOP ожидание события
В базе данных без проблем, процессорное время Всегда указан первым
Последовательное чтение файла БД: это событие ожидания является проблемой с порядком объединения нескольких таблиц, базовая таблица может использоваться неправильно или индекс может использоваться без разбора
Чтение разбросанного файла БД: это событие ожидания более очевидно, так как имеется большое количество полных сканирований таблиц или не созданы подходящие индексы
ARCH wait на SENDERQ: удаленная передача событий архива журнала ожидания
Oracle Примерно 100 Несколько событий ожидания в режиме ожидания и события ожидания в режиме ожидания,
Top 5 Timed Events БД Первые пять ожидающих событий, которые оказывают большее влияние на систему,
CPU Time Время ожидания простоя, Во-первых, БД относительно свободна,
Db file sequentail read С разбросанным прочитанным Это показывает, что выбор индекса не очень разумен,
3.5 AWR TOP SQL Tuning
При включении top sql, Top sql order by object имеет следующее
SQL, упорядоченный по истекшему времени: отсортировано по сумме времени выполнения SQL
SQL, упорядоченный по времени ЦП: отсортировано по сумме времени ЦП, потребляемого SQL
SQL, упорядоченный по типу Gets: отсортирован по сумме логического ввода-вывода потребления SQL
SQL, упорядоченный по чтению: сортировка по сумме физического ввода-вывода, потребляемого SQL
SQL, упорядоченный по исполнениям: отсортировано по количеству выполнений SQL
SQL, заказанный Parse Calls: в соответствии с временем мягкого синтаксического анализа sql
В основном наблюдайте и настраивайте три верхних SQL, упорядоченных по истекшему времени, упорядоченных по времени ЦП, упорядоченных при получении, упорядоченных по чтению
Шаги Oracle для обработки SQL:
1. Проверка грамматики (проверьте правильность написания грамматики SQL)
2. Семантическая проверка (проверьте, существует ли объект доступа в SQL и имеет ли он соответствующие разрешения)
3. parse (анализ SQL с использованием внутренних алгоритмов для генерации parsetree и плана выполнения) à в этом процессе выполняется мягкий и жесткий синтаксический анализ
Читайте также: