[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 что-то сдвинулось на эту тему, но похоже что это не так...