В этой статье хотел бы описать мои, которые запускаются из Oracle Sql developer.
Выгрузка всех отчетов находится по ссылке github
Для работы необходимо наличие лицензии "Diagnostic and Tuning Pack"
Полный список всех отчетов можно видеть на картинке слева.Большинство из них вспомогательные и нужны для определения параметров запуска отчета "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)
Дополнительные параметры:
- 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 от параллельных потоков в истории.
После задания параметров открывается главная форма отчета:
Форма собирается из 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.
* ash now - сейчас исполняющиеся запросы:
* plan - максимально детальный план запроса:
* binds - историй биндов запроса
* v$sql - информация о запросе из v$sql:
Список child планов, наличие профиля или baseline и все количественные характеристики child планов:
* awr - количественные характеристики плана в разрезе снапшотом без агрегации
* text - полный текст запроса:
* plan real - детализация плана запроса:
** план запроса
** предикаты доступа к объекту (если план сейчас в кэше)
** полный список колонок используемого индекса (для анализа эффективности индекса на месте)
** event - список событий этой строчки плана с процентным распределением от общего времени запроса
** prc - % времени работы этой строчки плана.
Удобно для быстрого определения неоптимальной части запроса, которую требуется оптимизировать в первую очередь.
* graph - график суммарного времени работы запроса в разрезе часов.
* awr wk - аналог отчета awr, но с группировкой до недели.
Удобно для определения тренда времени запроса и определения времени, когда сменился план.
* objects - топ таблиц по времени обращения к ним от этого запроса
* v$bh - история объема таблиц запроса в буферном кэше (источник: отчет "Таблицы в кэше")
* module - топ программ, которые взывают этот запрос
* graph_exe - график, аналогично отчету "graph", но по числу выполнений запроса.
Удобно сравнивать graph и graph_exe между собой, чтобы визуально видеть, растет ли число выполнений запроса вместе с общим временем.
Если число выполнений не растет, а общее время растет, то вероятная причина - рост среднего времени запроса.
* список сессий, которые блокировки работу выделенного запроса
** Событие блокировки
** клиент, который блокировал работу
** id сессии блокировки
** current_* - блок и строка в блоке, на которой происходила блокировка.
** obj_name - Объект, на котором блокировка
** cnt - количество sample во время которых длилась блокировка.
** sql_text - текст запроса, для определения строчки, на которой висела блокировка (на основании current_* столбцов)
Данный отчет удобно использовать для определения горячих строк, к которым пытаются получить блокировку несколько процессов.
* plan real tbs - на каком tablespace были основные чтения у строк плана запроса.
Данный отчет удобен для понимания причин замедления запроса, у которого не поменялся план
Скорей всего замедление связано с ростом числа чтений сегментом отката UNDO из-за интенсивной вставки/обновления одной из таблиц запроса ранее.
* text_bnd - Запрос с подставленным параметрами на место биндов.
Удобно для проверки влияния биндов на план запроса. Если с подставленными значениями получается хороший план, то вероятная причина в перекосе данных или отсутствующих гистограммах.
Выгрузка всех отчетов находится по ссылке github
Комментариев нет:
Отправить комментарий