У вас есть веб-сайт ASP.Net или другое приложение, которое создает зависимости Cql Server Cache? Он является очередью Sql Server Service Broker, он выполняет этот оператор WAITFOR ..., который ждет около одной минуты (60000 мс), а затем выполняет следующую секунду. Обычно это не вызывает проблем, он не должен блокировать или откладывать ваши «обычные» запросы или хранимые процедуры.
Однако, я видел, что это вызывало проблемы для меня один раз - одна из хранимых процедур при выполнении из того же веб-приложения, которое установила зависимость кеша, сделала тайм-аут (вернее, вернулась через 120 секунд, что неприемлемо). Точно такая же хранимая процедура, выполненная под той же учетной записью с одинаковыми параметрами, но из Management Studio, прошла отлично без каких-либо проблем. Это был SQL Server 2005 SP4.
SQL Profiler показал, что в середине выполнения моей хранимой процедуры (и всегда после той же инструкции INSERT INTO ...) ее выполнение было прервано, и вместо его утверждения было, что WAIT FOR .... from Sql Query Notification, завершено за одну минуту, затем еще один WAIT FOR ... начиная и снова, завершен через 59 секунд - и только после этого Profiler показал мне, что моя хранимая процедура завершена. С длительностью 119000, что составляет почти ровно две минуты.
Это было, если уведомления о запросах присоединились к транзакции в моей хранимой процедуре.
Что помогло: перекомпилировал нарушающую хранимую процедуру. Я просто изменил свой скрипт, сделал оператор ALTER с некоторыми незначительными изменениями синтаксиса. После этого проблем нет.
Какова природа таймаута? Получаете ли вы время ожидания при попытке подключения? Или некоторые запросы слишком долго выполняются? В производительности базы данных есть много факторов, таких как размер сети/производительность/латентность, размеры таблиц, индексы, пропускная способность запросов, клиентские соединения и т. Д. Я думаю, было бы разумно отступить и изучить вашу общую систему до перехода на вывод о том, что вам нужно начать уничтожать внутренние хранимые процедуры. – mellamokb
Иногда Тайм-аут возникает при вызове хранимых процедур, и иногда они даже не вызываются. Тот же код работал нормально, без каких-либо проблем в прошлом месяце. В этом месяце мы начали замечать эту проблему с таймаутом. Мы не изменили никаких хранимых процедур или каких-либо запросов. – nav100
Это довольно распространенный шаблон, когда у вас есть таблицы, которые со временем растут. Вам нужно взять конкретный пример и попытаться устранить таймаут. Например, если у вас есть хранимая процедура, которая считывает данные из таблицы с тысячами строк и должна завершиться менее чем за 30 секунд, рассмотрите индексирование столбцов, используемых при фильтрации (т. Е. Предложение WHERE). Вы также можете увеличить длину таймаута в своем клиентском коде - таймауты [полностью на стороне клиента] (http://blogs.msdn.com/b/khen1234/archive/2005/10/20/483015.aspx) и могут обычно быть сделанным бесконечно долго. – mellamokb