Обнаружение / мониторинг проблем обнаружения параметров

Question

Существуют ли какие-либо инструменты для специального мониторинга / обнаружения проблем с перехватом параметров, в отличие от тех, которые сообщают о запросах, которые занимают много времени?

Я только что столкнулся с проблемой перехвата параметров.(Это не было слишком серьезно, так как отчет работал около 2 минут вместо нескольких секунд при правильном кэшировании и, возможно, 30 секунд при перекомпиляции. А так как отчет обычно запускается всего несколько раз в месяц, онна самом деле это не проблема).

Однако, так как я написал отчет и знал, что он делает, мне стало любопытно, и я начал исследовать и использовать SQL Profiler, и в плане запросов я увидел раздел, в котором указано числопримерное количество строк равнялось 1, но фактическое количество строк составляло несколько сотен тысяч.

Итак, меня поразило, что если в SQL есть эти цифры (или, по крайней мере, могут получить эти цифры), то, возможно, есть некоторыеспособ получить sql, чтобы отслеживать и сообщать, какие планы были значительно вне.

Answer 1

У вас есть пара вопросов:

Существуют ли какие-либо инструменты для специального мониторинга / обнаружения проблем с отслеживанием параметров, в отличие от тех, которые сообщают о запросах, которые занимают много времени? Чтобы поймать это, вам нужно отслеживать кэш процедур, чтобы узнать, когда план выполнения запроса меняется с хорошего на плохой. SQL Server 2008 сделал это намного проще, добавив поля query_hash и query_plan_hash в sys.dm_exec_query_stats. Вы можете сравнить текущий план запроса с прошлым для того же самого query_hash, а когда он изменится, сравнить количество логических чтений или количество рабочего времени от старого запроса до нового. Если это резко возрастет, у вас может быть проблема с анализом параметров.

С другой стороны, кто-то мог просто удалить индекс или изменить код в вызываемой UDF, или изменить MAXDOP, или любой из миллиона параметров, влияющих на поведение плана запроса.

То, что вам нужно, - это одна панель мониторинга, которая отображает самые ресурсоемкие запросы в совокупности (потому что у вас может быть эта проблема в запросе, который вызывается очень часто, но каждый раз потребляет небольшое количество ресурсов), а затем показывает изменения в его план выполнения с течением времени, плюс накладывает на изменения уровня системы и базы данных. Quest Foglight Performance Analysis делает это. (Раньше я работал на Quest, поэтому знаю продукт, но здесь я не шиллинг.) Обратите внимание, что Quest продает отдельный продукт, Foglight, который не имеет ничего общего с Performance Analysis. Я не знаю ни о каком другом продукте, который входит в этот уровень детализации.

Я мог видеть раздел в плане запроса, в котором число предполагаемых строк было 1, но фактическое количество строк составляло несколько сотен тысяч.

Это не обязательно сниффинг параметров - это может быть, например, плохая статистика или использование табличных переменных. Чтобы решить эту проблему, мне нравится бесплатный инструмент SQL Sentry Plan Advisor . На вкладке «Основные операции» выделены различия между оценочными и фактическими строками.

Теперь, это только для одного плана за раз, и вы должны сначала знать план. Вы хотите сделать это 24/7, верно? Конечно, вы делаете - но это требует больших вычислительных ресурсов. Кэш процедур может быть огромным (у меня есть клиенты с> 100 ГБ кэша процедур), и это все неиндексированный XML. Чтобы сравнить примерные и фактические строки, вам нужно уничтожить весь этот XML - и помнить, что кэш процедур может постоянно меняться под нагрузкой.

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

Answer 2

Вы сказали

"оценочные строки были 1, но фактическое количество строк составляло несколько сотен тысяч."

Это может быть вызвано переменными таблицы, которые неНет статистики.

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

Мы сейчас используем постоянное маскирование параметров (система была разработана на SQL Server 2000).Нам это не нужно в 99,9+% случаев, но <0,1% оправдывает это из-за уверенности пользователей + накладных расходов на поддержку, которые это влечет за собой. </p>

Answer 3

Вы можете настроить трассировку для записи текста запроса всех запусков пакетов / хранимых процедур, имеющих длительность> Ns.

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

См. Как создать трассировку SQL с использованием T-SQL , как создать трассировку с использованием T-SQL.Это даст лучшую производительность, чем использование SQL Profiler, поскольку он только захватывает события, для которых вы устанавливаете события трассировки (по сообщениям, SQL Profiler захватывает все события и затем фильтрует их в приложении).