zakharov: Внедряем AX2009. Поиск "тяжелых" запросов используя Microsoft SQL Server Activity Monitor

[Blog bot]

Источник: http://www.zakharov.com/2013/08/ax20...-activity.html
==============



Источник: http://www.zakharov.com/2013/08/ax20...-activity.html

[mazzy]

о, наконец-то хоть кто-то этот способ описал.
Иван, появись в этой ветке, дай тебе спасибо сказать.

[fed]

От себя замечу, что хотя способ и остроумный (я более длинным путем эту информацию получаю), но эвристический. Во первых - для сессии может быть более одного открытого курсора (и тогда надо будет по косвенным признакам искать более тяжелый из курсоров). Во вторых - у меня есть ужасное подозрение что система использует имена курсоров повторно для других запросов. Ну то есть - если ты видешь что у тебя в списке тяжелых запросов в sys.dm_exec_query_stats болтается запрос FETCH XYZ и ты видишь что у тебя в какой-то из сесии этот курсор используется для примитивного запроса select * from inventTable where itemId=%1, это не означает что сиквел сошел с ума и не может извлечь одну запись по кластерному ключу. Возможно вчера это же имя курсора использовалось для мегатяжелого запроса с 6 джойнами, а счас он просто повторно используется для простенького запроса. Во втором пункте я не уверен, но я точно видел несколько раз когда FETCH тяжелейшей исторической статистикой исполнения почему-то ссылался на простенький запросик...

[gl00mie]

Offtopic: вот все классно в этом блоге, кроме используемого движка. Какой-то он мега-тяжелый для MSIE10, не говоря уже про то, что blog bot сообщения не тянет.

[ziva]

Цитата:

Сообщение от fed

От себя замечу, что хотя способ и остроумный (я более длинным путем эту информацию получаю), но эвристический.

Поделишься своим методом? Если он более надежный, думаю многим будет полезен.

Цитата:

Сообщение от fed

Во вторых - у меня есть ужасное подозрение что система использует имена курсоров повторно для других запросов.

Повторное использование курсоров пока не замечал.

[fed]

Цитата:

Сообщение от ziva

Поделишься своим методом? Если он более надежный, думаю многим будет полезен.



Повторное использование курсоров пока не замечал.

Он тоже эвристический
На самом деле я примитивно вытаскиваю текущие исполняющиеся запросы по сессиям
пдообным запросом

select r.session_id,r.status,
 SUBSTRING(st.text, (r.statement_start_offset/2)+1, 
        ((CASE r.statement_end_offset
          WHEN -1 THEN DATALENGTH(st.text)
         ELSE r.statement_end_offset
         END - r.statement_start_offset)/2) + 1) AS statement_text,
r.blocking_session_id,r.wait_type,r.wait_resource,r.wait_time,DB_NAME(r.database_id),r.cpu_time,r.logical_reads,r.reads,r.writes,r.start_time,r.sql_handle,r.plan_handle
from sys.dm_exec_requests  r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS st
CROSS APPLY sys.dm_exec_query_plan(r.plan_handle)as qp
where sql_handle is not null

Если я вижу что где-то исполняется тот самый fetch xyz из списка тяжелых запросов, я запоминаю номер сессии и вытаскиваю данные из той же таблицы открытых курсоров что и у тебя по номеру сессии.
Проблема в том, что зачастую очень тяжелый запрос из sys.dm_exec_query_stats приводит к вполне невинному запросику в sys.dm_exec_cursors, который в Management Studio исполняется со свистом и с очень разумным планом исполнения.
Я вижу возможных причины для этого:

1. Повторное использование имен курсоров (о котором я уже писал)
2. SQL Server в каких-то случаях использует принципиально разные планы исполнения для ситуаций, когда запрос открывается через обычный select и для ситуации когда для того же запроса используется серверный курсор.

А вообще, по моему не существует гарантированного и универсального способа замеппить Fetch в исходный текст запроса и посмотреть на план исполнения того самого исходного запроса... У меня была надежда что в SQL 2012 что-то сдвинулось на эту тему, но похоже что это не так...