В этой статье хотел бы описать мои, которые запускаются из Oracle Sql developer.
Выгрузка всех отчетов находится по ссылке github
Для работы необходимо наличие лицензии "Diagnostic and Tuning Pack"
![](http://skahin.ru/blog/img/ash/image001.png)
Большинство из них вспомогательные и нужны для определения параметров запуска отчета "ash" с более детальными параметрами
Вспомогательные отчеты
-
Buffer Cache hit ratio - строит график с этим показателем.
Необходим для определения периода времени на котором были провалы по % буферных чтений.
-
Graph top - топ sql запросов по продолжительности в разрезе времени.
Может быть использован для наглядного определения наиболее долгих запросов в промежуток времени.
-
Reads per sec - график логических или физических чтений в разрезе времени
Используется для определения проблемного промежутка времени в который было повышенное число чтений -
Table top reads - гистограмма со списком топовых таблица по чтениям в указанный период
Используется как детализация отчета "Reads per sec" за указанный период, чтобы узнать какая именно таблица вызвала повышенные чтения. -
Нагрузка ash - график числа sample ash в разрезе времени
Наглядное определение периода времени, в который была наибольшая активность запросов. По проблемному периоду дальше строится детализирующий отчета "ash" -
Нагрузка по неделям - график числа sample ash в разрезе дня недели и номера недели
Удобно для анализа динамики нагрузки на бд. -
Obj top read - топ запросов по чтениям на заданной таблице.
Используется как детализация отчетов "Reads per sec" -> "Table top reads", чтобы узнать какие именно запросы вызвали повышенные чтения на указанной таблице. -
Query on obj - топ запросов по времени на заданной таблице.
Схож с отчетом "Obj top read", но запросы отсортированы по времени работы. Отчет удобен для определения проблемных по времени работы запросов на таблице. -
Таблицы в кэше - таблицы, которые сейчас в буферном кэше находятся в представлении v$bh
Чтобы иметь историю представление материализуется в таблицу каждый час запросом, а потом строится график:insert into stat$bh(snap_date, objd, obj_owner, obj_type, obj_name, obj_blocks, blocks, pct, dirty_blocks) select sysdate as snap_date, objd, obj_owner, obj_type, obj_name, obj_blocks, blocks, pct, dirty_blocks from ( select objd, o.owner as obj_owner, o.object_type as obj_type, o.object_name as obj_name, max(NVL(t.blocks, i.LEAF_BLOCKS)) as obj_blocks, count(*) blocks, ROUND(count(*) / SUM( COUNT(*) ) OVER() * 100,2) pct, count(case when s.dirty = 'Y' then 1 end) dirty_blocks from GV$BH s join dba_objects o on o.object_id = s.objd left join dba_tables t on t.table_name = o.object_name and t.owner = o.owner left join dba_indexes i on i.index_name = o.object_name and i.owner = o.owner group by inst_id, objd, o.object_type, o.object_name, o.owner ) where pct > 0.5 order by pct desc;
Постоянный большой объем таблицы в кэше говорит о неоптимальности запросов на ней, т.к. вычитывается большой объем данных.
По dirty_blocks можно косвенно оценить объем изменений. -
Query ash now - список сейчас работающих запросов.
Есть возможность наложить фильтр по клиенту, программе, sql_id, id сессии, тексту запроса. -
Plan diff date - поиск изменившихся планов между 2 датами.
Удобно при анализе изменившихся планов после установки патчей на бд. - SQL id plans, Table plans - устаревшие отчеты, которые стали частью других: "ash" и "Query on obj" соответственно.
Основной детализирующий отчет ASH
При запуске нужно минимум указать 2 параметра:- f - дата-время С целиком или часть (dd.mm.yyyy hh24:mi:ss)
- t - дата-время ПО целиком или часть (dd.mm.yyyy hh24:mi:ss)
![](http://skahin.ru/blog/img/ash/image002.png)
- module - программа (возможно задание маской %%)
- client - пользователь/client_id (возможно задание маской %%)
- sql_id - id запроса (точное совпадение)
- hsh - hash плана запроса (точное совпадение)
- st_hr - начальный час анализа (точное совпадение)
- ed_hr - конечный час анализа (точное совпадение) - когда нужно проанализировать определенный часовой промежуток, но за несколько дней (к примеру только запросы в рабочее время 8-18)
- event - запросы содержащие это событие (точное совпадение)
- sid - запросы от указанного id сессии (точное совпадение)
- user_id - запросы от указанного id пользователя (точное совпадение)
- smpl - 0 - сортировать запросы по времени работы. 1 - по числу sample в ash.
Топ в зависимости от настройки может отличаться, т.к. параллельные запросы работают по времени меньше, чем создают samples от параллельных потоков в истории.
После задания параметров открывается главная форма отчета:
![](http://skahin.ru/blog/img/ash/image004.png)
Форма собирается из 3 таблиц: gv$active_session_history - недавняя история ASH, dba_hist_active_sess_history - давняя история и DBA_HIST_SQLSTAT - количественные показатели (число выполнений, время работы, число строк)
Кроме столбцов, которые известы из параметров отчета, добавляются:
* st_dt/ed_dt - период, на котором наблюдался запрос
* execs - число выполнений
* gb - объем считанных данных в ГБ
* av_sec - среднее время работы
* sec - суммарное время работы
* smpl - суммарное число sample в ash
* dop - степень параллелизма, с которой работал запрос
* rws - числ отбираемых/изменяемых строк
* prc - % времени запроса от общей
* txt - текст запроса
Если поставить фокус на определенной строчке отчета, то активируются детализирующие отчеты:
* sql_id plans - список планов на этом запросе за все время существования.
+ Характеристики каждого плана: когда он выполнялся, число выполнений, объем физических и логических чтений, число строк, среднее время и отклонение времени работы от среднего.
Данный детализирующий отчет удобен для выбора плана для последующей фиксации по средствам baseline.
![](http://skahin.ru/blog/img/ash/image005.png)
* ash now - сейчас исполняющиеся запросы:
![](http://skahin.ru/blog/img/ash/image006.png)
* plan - максимально детальный план запроса:
![](http://skahin.ru/blog/img/ash/image007.png)
* binds - историй биндов запроса
* v$sql - информация о запросе из v$sql:
Список child планов, наличие профиля или baseline и все количественные характеристики child планов:
![](http://skahin.ru/blog/img/ash/image008.png)
* awr - количественные характеристики плана в разрезе снапшотом без агрегации
![](http://skahin.ru/blog/img/ash/image009.png)
* text - полный текст запроса:
![](http://skahin.ru/blog/img/ash/image010.png)
* plan real - детализация плана запроса:
** план запроса
** предикаты доступа к объекту (если план сейчас в кэше)
** полный список колонок используемого индекса (для анализа эффективности индекса на месте)
** event - список событий этой строчки плана с процентным распределением от общего времени запроса
** prc - % времени работы этой строчки плана.
Удобно для быстрого определения неоптимальной части запроса, которую требуется оптимизировать в первую очередь.
![](http://skahin.ru/blog/img/ash/image011.png)
* graph - график суммарного времени работы запроса в разрезе часов.
![](http://skahin.ru/blog/img/ash/image012.png)
* awr wk - аналог отчета awr, но с группировкой до недели.
Удобно для определения тренда времени запроса и определения времени, когда сменился план.
![](http://skahin.ru/blog/img/ash/image013.png)
* objects - топ таблиц по времени обращения к ним от этого запроса
![](http://skahin.ru/blog/img/ash/image014.png)
* v$bh - история объема таблиц запроса в буферном кэше (источник: отчет "Таблицы в кэше")
* module - топ программ, которые взывают этот запрос
* graph_exe - график, аналогично отчету "graph", но по числу выполнений запроса.
Удобно сравнивать graph и graph_exe между собой, чтобы визуально видеть, растет ли число выполнений запроса вместе с общим временем.
Если число выполнений не растет, а общее время растет, то вероятная причина - рост среднего времени запроса.
* список сессий, которые блокировки работу выделенного запроса
** Событие блокировки
** клиент, который блокировал работу
** id сессии блокировки
** current_* - блок и строка в блоке, на которой происходила блокировка.
** obj_name - Объект, на котором блокировка
** cnt - количество sample во время которых длилась блокировка.
** sql_text - текст запроса, для определения строчки, на которой висела блокировка (на основании current_* столбцов)
Данный отчет удобно использовать для определения горячих строк, к которым пытаются получить блокировку несколько процессов.
![](http://skahin.ru/blog/img/ash/image015.png)
* plan real tbs - на каком tablespace были основные чтения у строк плана запроса.
Данный отчет удобен для понимания причин замедления запроса, у которого не поменялся план
Скорей всего замедление связано с ростом числа чтений сегментом отката UNDO из-за интенсивной вставки/обновления одной из таблиц запроса ранее.
![](http://skahin.ru/blog/img/ash/image016.png)
* text_bnd - Запрос с подставленным параметрами на место биндов.
Удобно для проверки влияния биндов на план запроса. Если с подставленными значениями получается хороший план, то вероятная причина в перекосе данных или отсутствующих гистограммах.
![](http://skahin.ru/blog/img/ash/image017.png)
Выгрузка всех отчетов находится по ссылке github
Комментариев нет:
Отправить комментарий