Мониторинг курсоров, какие есть хорошие запросы / скрипты для этого?

Question

Мне нужно предоставить руководству доказательства того, что группа существующих хранимых процедур, использующих курсоры, является причиной многих проблем с производительностью. Может кто-нибудь указать мне правильное направление, чтобы найти сценарии и запросы для достижения этой цели, пожалуйста? Например, как отслеживать и измерять курсоры и т. Д. Использование SQL Server 2005.

Спасибо.

======== UPDATE ============

Менеджмент нуждается в боеприпасах, чтобы доставить его к стороннему поставщику, чтобы он сказал, чтобы он сменил свои продукты без каких-либо затрат для нас. Так как это сторонние процессы, попавшие в нашу учетную систему, у меня нет возможности переписать их в первую очередь.

Помимо следов (уже делаю), есть ли что-нибудь еще, что я могу сделать? Я обнаружил, что использование sys.dm_exec_cursors (0) позволяет мне получить быстрый список существующих курсоров. Есть ли что-нибудь подобное?

Answer 1

Итак, вы провели жесткие измерения и собрали время выполнения и статистику, показывающую, что проблемные процедуры - это те, которые используют курсоры, верно? Тогда собранная информация является отличным аргументом в доказательство вашего довода. Если вы не ... тогда откуда вы знаете, курсоры?

Начните с просмотра sys.dm_exec_query_stats и соберите самые дорогие запросы по рабочему времени (ЦП), прошедшему времени (продолжительности) и по операциям ввода-вывода. Этого должно быть достаточно, чтобы указать на виновного и выяснить, действительно ли проблема связана с курсорами или нет.

Если курсоры действительно являются проблемой, для них тоже есть выделенные DMV, sys.dm_exec_cursors

Например, самые дорогие ЦП часто выполняемые операторы:

select top(10) substring(Text,
  statement_start_offset/2, 
  (statement_end_offset-statement_start_offset)/2) as Statement
  , *
from sys.dm_exec_query_stats q
cross apply sys.dm_exec_sql_text(sql_handle)
where execution_count > 100
order by total_worker_time/execution_count desc

Answer 2

Вы можете запустить SQL Profiler и захватить трассировку с помощью проблемных sprocs (это даст вам важные меры, такие как чтение, загрузка процессора, длительность).

Хорошей идеей было бы, например, возьмите один из них в качестве примера, который довольно легко переписать как подход, основанный на множествах, запустите его и запишите трассировку профилировщика для этого. Таким образом, вы можете показать реальные различия в производительности.

Если возможно, (т. Е. Не на производстве), вы должны очистить план выполнения и кэш данных перед запуском каждой версии sproc, чтобы обеспечить достоверное сравнение.

Кроме того, вы можете получить планы выполнения для версии курсора и версии на основе набора.

В конце дня итоговая статистика говорит сама за себя, поэтому сравнение «до» и «после» будет полезным.

Answer 3

Монитор производительности (perfmon.exe) - отличный инструмент для анализа производительности SQL Server в режиме реального времени.

Answer 4

Лучше всего (если позволит время) переписать некоторые из процедур в виде операторов на основе множеств, а затем сравнить их с анализом ожидания (http://technet.microsoft.com/en-us/library/cc966413.aspx имеет хороший документ о том, как делать такие вещи ). Без «до и после» ваши противники могут просто сказать: «на основе множества не будет лучше :-)»