Хранимая процедура висит вроде бы без объяснения причин

Question

у нас есть хранимая процедура, которая нормально работала до 10 минут назад, а затем просто зависает после ее вызова.

Замечания:

• Копирование кода в окно запроса дает результат запроса за 1 секунду
• SP занимает> 2,5 минуты, пока я не отменю его
• Activity Monitor показывает, что он ничем не заблокирован, он просто выполняет команду SELECT.
• Запуск sp_recompile на SP не помогает
• Удаление и воссоздание SP не помогает
• Установка LOCK_TIMEOUT на 1 секунду не помогает

Что еще может происходить?

---

ОБНОВЛЕНИЕ : Я предполагаю, что это связано с анализом параметров. Я использовал рутину Адама Маханича, чтобы выяснить, какой подзапрос завис. Я нашел что-то не так с планом запроса благодаря подсказке Мартина Смита. Я узнал о EXEC ... WITH RECOMPILE, OPTION(RECOMPILE) для подзапросов в SP и OPTION (OPTIMIZE FOR (@parameter = 1)) для атаки на сниффинг параметров. Я до сих пор не знаю, что было не так в этом конкретном случае, но я вышел из этой битвы опытным и намного лучше вооруженным. Я знаю, что делать в следующий раз. Так вот в чем суть!

Answer 1

Я думаю, что это связано с анализом параметров и необходимостью параметризации ваших входных параметров для локальных параметров в SP.Добавление с перекомпиляцией приводит к пересозданию плана выполнения и устраняет большую часть преимуществ наличия SP.Мы использовали With Recompile во многих отчетах, пытаясь устранить эту проблему зависания, и иногда это приводило к зависанию SP, которые могли быть связаны с другими блокировками и / или транзакциями, обращающимися к одним и тем же таблицам одновременно.См. Эту ссылку для получения более подробной информации Обнаружение параметров (или спуфинг) в SQL Server и измените SP на следующие, чтобы исправить это:

CREATE PROCEDURE [dbo]. [SPNAME] @ p1 int, @ p2 int AS

ОБЪЯВИТЬ @ localp1 int, @ localp2 int

SET @ localp1 = @ p1 SET @ localp2 = @ p2

Answer 2

Запустите отличный хранимый процесс sp_WhoIsActive Адама Мачаника во время выполнения запроса Он даст вам информацию об ожидании - то есть, что ожидает сохраненный процесс - плюс такие вещи, как план выполнения:

http://www.brentozar.com/archive/2010/09/sql-server-dba-scripts-how-to-find-slow-sql-server-queries/

Answer 3

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

DBCC DROPCLEANBUFFERS 

DBCC FREEPROCCACHE

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

msdn.microsoft.com

Answer 4

First First First.

Пожалуйста, проверьте, есть ли какие-либо незафиксированные транзакции.Начальная транзакция без "COMMIT TRANSACTION"

Answer 5

Я думаю, у меня была такая же проблема.Я удалил свои параметры из подзапросов.После этого все прошло нормально.Не уверен, что это возможно в вашем сценарии, но это то, что решил для меня.

Answer 6

Спасибо за все комментарии.

Я до сих пор не нашел ответ, но опубликую здесь прогресс.

Я не смог воспроизвести проблему раньше, но сегодня случайно наткнулся надругая хранимая процедура с той же проблемой.Снова появились те же симптомы:

• В обычном окне запросов висящий фрагмент запроса выполняется нормально и быстро (3 секунды) (висящий фрагмент идентифицирован как sp_whoisactive)
• Нет блокировок, согласно ActivityМонитор SPID выполняет SELECT
• Хранимая процедура выполняется более 6 часов без ответа
• Параметры, переданные в SP и переменные, объявленные в окне, совпадают

Использование приведенных выше подсказокЯ нашел план выполнения SP, и он не показал ничего необычного (по крайней мере для меня).Создание новой хранимой процедуры с тем же содержимым также не решило проблему.Поэтому я начал разбирать SP на все меньше и меньше, пока не столкнулся с вызовом UDF другой базы данных .Когда я удалил это (заменил вызов встроенным содержимым функции, оператором CASE), он снова заработал нормально.

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