Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 метрики сравнения производительности запросов  [new]
mlc
Member

Откуда: Asus Winter Cup
Сообщений: 460
Всем привет.

Задался вопросом о сборе макисмальной инфы о производительности запроса с целью сравнения разных вариантов исполения. Трасса само собой один из инструментов для такого анализа. Однако хотелось бы собрать инфу по разным служебным вьюхам. Может есть у кого полезный скриптец буду признателен.
Что накопал:
v$sql - дисковые и логические чтения, различные временные характиристики, аля elapsed, cpu, concurrency и io time, px_servers_executions
v$sql_plan_statistics_all - план запроса с размером используемой памяти + немного инфы по выполнению соединения(optimal hj, onepass etc.)
v$active_session_history - куда ж без нее. По sql_plan_line_id можно примерно понять на чем теряется основное время

Максимум еще можно посомтреть v$session_event, но это уже слишком общая инфа.

Хотелось бы сравнить несколько запросов на предмет производительности, но че т мне кажется маловато у меня показателей и что-то я не учел, например, из приведенных выше вьюх не увидишь, как долго происходил execute, fetch. Поделитесь опытом.
30 окт 19, 17:14    [22006279]     Ответить | Цитировать Сообщить модератору
 Re: метрики сравнения производительности запросов  [new]
Кобанчег
Member

Откуда: Рахів
Сообщений: 593
mlc
Максимум еще можно посомтреть v$session_event, но это уже слишком общая инфа.
Ну почему же, в древние времена до AWR пару таблиц v$session_event, v$sesstat (и их эквиваленты уровня системы v$system_event, v$sysstat)
были чуть ли не основным источником информации про производительность.
Можешь набрать в гугле "oracle yapp".

mlc
Хотелось бы сравнить несколько запросов на предмет производительности, но че т мне кажется маловато у меня показателей и что-то я не учел, например, из приведенных выше вьюх не увидишь, как долго происходил execute, fetch.
По понятным причинам fetch в базе не трекается. Это процесс который не может рассматриваться в отрыве от клиента.
Можно выдумывать всякие трюки и смотреть первый и последний сэмпл в ash для конкретного запроса чтоб определить "общую длительность выполнения", но их там может не быть.
Если всковырнуть dbms_sqltune.report_sql_monitor, то там можно увидеть

                       XMLELEMENT("duration", NULL,
GREATEST(TARGET_DURATION,
LEAST(MAX_ELAPSED_TIME/1000000, 1),
CEIL(MAX_QUEUING_TIME/1000000))))

Где для каждого из трех составляющих свой отдельный механизм вычисления.

elapsed_time и executions в v$sql вполне достаточно для старта, потом может понадоится еще множество других v$ вьюх или уровней трассировки (+runtime execution statistics) в зависимости от того, что хочется отловить.

+уже упомянутый v$sql_monitor

PS. Информация для разных инструментов может частично пересекаться, но весьма наивно пытаться получить информацию из трассировки не делая самой трассировки.
30 окт 19, 18:15    [22006397]     Ответить | Цитировать Сообщить модератору
 Re: метрики сравнения производительности запросов  [new]
Valergrad
Member

Откуда:
Сообщений: 686
mlc,

gv$sqlstats ( и dba_hist_sqlstats ) содержит разные статистики по конкретному запросу

В gV$SQL_PLAN_MONITOR есть инфа для каждой строки плана - сколько раз она выполнялась, сколько строк получилось и сколько времени заняло - если запрос конечно был отмониторен со statistics_level = all.

Если тебе интересно сколько времени проходил парс, установка соединения или скажем Pl/sql execution ты можешь замерить
GV$SESS_TIME_MODEL до и после.

По поводу же "скриптеца" имхо самое универсальное что я использую - это XPLAN_ASH Рэндольфа Гейста. Большой такой скрипт, который дает очень много инфы, думаю, что примерно все что есть в системных таблицах - он анализирует.
https://oracle-randolf.blogspot.com/2016/06/new-version-of-xplanash-utility.html

Для своего удобства я его чуть допилил чтобы вызывать из pl/sql developer и смотреть результаты одной кнопкой, потому что sql*plus не самая удобная среда разработки.

Есть скрипты от Оракла которые дают еще больше диагностической инфы ( типа статистики по таблицам учавствующим в запросах и пр. ) но это уже редко когда нужно, и работать они могут по полчаса. По соотшению информация-время анализа думаю что XPLAN_ASH пока лучший.
30 окт 19, 20:31    [22006529]     Ответить | Цитировать Сообщить модератору
 Re: метрики сравнения производительности запросов  [new]
Alexander Anokhin
Member

Откуда: Хабаровск
Сообщений: 442
mlc
Всем привет.

Задался вопросом о сборе макисмальной инфы о производительности запроса ...

Более эффективно не лазить по десяткам представлений, а получить отчёт (пакет), который соберёт всё за тебя, включая SQL monitor, исторические планы, и больше. Рекомендую эти
1. SQLT - требует установки своих пакетов в базу. У него есть одно крайне важное преимущество перед другими - он собирает сразу 2 тест кейса - SQLT и DBMS_SQLDIAG, которые потом можно в другом окружении воспроизводить. Поддерживается Oracle
2. SQLHC - не требует установки чего-либо в базу, поддерживается Oracle
3. SQLd360, не требует установки. Сторонний.


mlc
из приведенных выше вьюх не увидишь, как долго происходил execute, fetch.
В ASH есть столбцы IN_PARSE, IN_HARD_PARSE, IN_EXECUTION.
30 окт 19, 22:04    [22006594]     Ответить | Цитировать Сообщить модератору
 Re: метрики сравнения производительности запросов  [new]
Alexander Anokhin
Member

Откуда: Хабаровск
Сообщений: 442
Valergrad
В gV$SQL_PLAN_MONITOR есть инфа для каждой строки плана - сколько раз она выполнялась, сколько строк получилось и сколько времени заняло - если запрос конечно был отмониторен со statistics_level = all.


V$SQL_PLAN_MONITOR это часть Real Time SQL Monitoring, он не связан с statistics_level = all
Возможно ты путаешь с V$SQL_PLAN_STATISTICS[_ALL]
Лазить туда вручную врядли стоит. Проще получить SQL monitor report. Также скрипт можно (нужно) сделать и вызывать из PL/SQL Developer или другого инструмента.
30 окт 19, 22:10    [22006599]     Ответить | Цитировать Сообщить модератору
 Re: метрики сравнения производительности запросов  [new]
DВА
Member

Откуда:
Сообщений: 5419
mlc,
а что с этой информацией делать собираетесь?
31 окт 19, 00:27    [22006663]     Ответить | Цитировать Сообщить модератору
 Re: метрики сравнения производительности запросов  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7088
делать CBO
DВА
mlc,
а что с этой информацией делать собираетесь?
31 окт 19, 01:30    [22006667]     Ответить | Цитировать Сообщить модератору
 Re: метрики сравнения производительности запросов  [new]
xtender
Member

Откуда: Мск
Сообщений: 5250
Alexander Anokhin
3. SQLd360, не требует установки. Сторонний.
edb360 и sqld360 теперь объединены в sqldb360
31 окт 19, 04:22    [22006685]     Ответить | Цитировать Сообщить модератору
 Re: метрики сравнения производительности запросов  [new]
mlc
Member

Откуда: Asus Winter Cup
Сообщений: 460
DВА
mlc,
а что с этой информацией делать собираетесь?

Как подметил Relic Hunter для CBO:
mlc
Хотелось бы сравнить несколько запросов на предмет производительности
31 окт 19, 09:08    [22006740]     Ответить | Цитировать Сообщить модератору
 Re: метрики сравнения производительности запросов  [new]
mlc
Member

Откуда: Asus Winter Cup
Сообщений: 460
Кобанчег,

dbms_sqltune с его v$sql_monitor и v$sql_plan_monitor - это конечно здорово, но вот не доступен он на наших средах. Отключен вплоть до прода.
31 окт 19, 09:20    [22006750]     Ответить | Цитировать Сообщить модератору
 Re: метрики сравнения производительности запросов  [new]
Vadim Lejnin
Member

Откуда:
Сообщений: 6829
Коллеги, нужно учитывать, что даже обращение к некоторым view, может привести к нарушению лицензий (tuning pack, performance pack).
Подробнее:
Database Licensing Information User Manual
Oracle Database Offerings and Their Permitted Features
31 окт 19, 11:24    [22006926]     Ответить | Цитировать Сообщить модератору
 Re: метрики сравнения производительности запросов  [new]
Valergrad
Member

Откуда:
Сообщений: 686
Alexander Anokhin
mlc
Всем привет.

Задался вопросом о сборе макисмальной инфы о производительности запроса ...

Более эффективно не лазить по десяткам представлений, а получить отчёт (пакет), который соберёт всё за тебя, включая SQL monitor, исторические планы, и больше. Рекомендую эти...


Здесь конечно вкусовщина, но конкретно они мне не зашли. Дело в том, что они работают, бывает по полчаса на запрос и выдают мегабайтные отчеты среди которых полезного в общем случае дай бог 1% ( т.е. нужно еще продираться между бесполезных данных и искать полезные ). Я в большинстве случаев предпочту утилиту которая работает не дольше минуты, и выдает репорт с исключительно полезными данными, поэтому остановился на xplan_ash.
31 окт 19, 17:23    [22007407]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить