Необъяснимые тайм-ауты при запуске хранимых процедур

Question

Фон - У меня есть сайт & запланированное задание на Windows, которое является частью MSI и устанавливается на том же сервере. Веб-сайт используется конечным пользователем для создания некоторых правил, и задание должно запускаться ежедневно, чтобы создавать плоские файлы для правил, созданных конечным пользователем. Фактические сценарии являются более сложными, чем описано выше.

Проблема (с веб-сайта) - Сайт работает отлично большую часть времени, но несколько раз он как раз не загружать страницу создания правила - и исключение после входа его «тайм-аут запроса или SQL-сервер не отвечает»

Проблема (с работой) - работа ведет себя так же, как веб-сайт и не несколько раз, за ​​исключением - «тайм-аут запроса или SQL-сервер не отвечает»

То, что я пробовал -

• Я добавил «Тайм-аут соединения» в строку подключения SQL - похоже, не помогает с протоколированием - что скажет мне, был ли это тайм-аут соединения или таймаут запроса.
• Я также запускаю хранимые процедуры, которые вызывают на веб-сайте & job - и ВСЕ хранимые процедуры полностью заполнены в течение заданного тайм-аута 3600 секунд. Хранимые процедуры фактически завершаются менее чем за минуту.
• Я также запускаю профилировщик SQL - но TRACES также не помогли мне, хотя я мог видеть много транзакций, но я не мог оправдать, что что-то не так с сервером.

Что я ищу - Есть ли другие причины, которые могут вызвать это? Есть ли что-то, что я мог бы найти?

Технология - SQL Server 2008 R2, ASP.Net, C# .Net

Ограничение - Деталь коды не может быть выявлена ​​из-за конфиденциальности клиента, хотя я открыт для вопросов - которые Я бы попытался ответить на конфиденциальность конфиденциальности клиентов.

Примечание - Существует уже тайм-аут запроса (3600s) & Connection Timeout (30s), определенные в файле конфигурации applicaiton.

Answer 1

Итак, я попробовал несколько вещей здесь и там, и был в состоянии выяснить причину -

SQL, хранимая процедура присоединялась 2 таблиц из 2 разных баз данных - одна из которых различных количеств записей - эти записи обновлялись/вставлялись другой (сторонней) работой. Поскольку время работы третьей стороны и моя работа не были одинаковыми - никаких проблем не возникало из-за блокировок таблиц, но чистый объем записей приводил мою работу к таймауту, когда моего таймаута было недостаточно.

Но, как я уже сказал, я дал тайм-ауту команды бизнес-стандартного 3600 секунд - так или иначе корпоративная библиотека переопределяла мой пользовательский тайм-аут с собственным тайм-аутом команды по умолчанию 30 с - и, следовательно, часть кода C# вышла бы за исключения даже до завершения хранимой процедуры.

То, что я сделал - это может быть полезным для некоторых из нас -

1. Я удалил ссылку на Enterprise Library из проекта
2. Подчищены мое решение и проверено в SVN.
3. Затем очищается SVN.
4. Я не создавал приложение после удаления ссылки на Enterprise Library - очевидно, что он не будет создан из-за ошибок ссылки.
5. После этого я взял чистый чек и снова добавил корпоративную библиотеку.

Теперь он работает даже с различным количеством записей.

Answer 2

У меня была аналогичная проблема с mssql и не нашла особых причин для этого нестабильного поведения. Мое решение было иметь дб Переиндексировано с

sp_updatestats

каждый час.

Answer 3

Вы можете использовать WITH RECOMPILE в вашем определением хранимой процедуры, чтобы избежать ошибки «тайм-аута запроса или SQL-сервер не отвечает»

Вот статья Microsoft:
http://technet.microsoft.com/en-us/library/ms190439.aspx

см Также в этом для справки:
SQL Server: Effects of using 'WITH RECOMPILE' in proc definition?

Пример кода:

CREATE PROCEDURE [dbo].[sp_mystoredproc] (@param1 varchar(20) ,@param2 int) 
WITH RECOMPILE 
AS 
... proc code ... 

Answer 4

У меня была такая же проблема и вчера. Имел огромный запрос, занимающий 18 секунд в SQL Server, но заканчивался на C# даже через 200 секунд. Я перезагрузил свой компьютер, отключив БД и даже отключив сервер ... ничего не изменилось.

После прочтения некоторых потоков я заметил общий фид об индексах. Поэтому я удалил некоторые индексы в своей базе данных, положил обратно и voilà !. Вернемся к норме.

Возможно, я думал, что могло случиться. В то время как я выполнял некоторый тест, у меня, вероятно, все еще были некоторые связи с зомби, и мой коллега одновременно создал несколько таблиц в БД и связал их с таблицами, используемыми в моей хранимой процедуре. Даже если вновь созданные таблицы не имеют ничего общего с хранимой процедурой, связать их с другими, похоже, перепутали с индексами. Почему только C# не может работать правильно? Я предполагаю, что кэш памяти в SQL Server недоступен при непосредственном подключении какого-либо места, кроме SQL Server.

N.B.В моем случае просто изменение хранимой процедуры вообще не имело никакого эффекта, даже если это было обычное «решение» среди некоторых потоков.

Надеюсь, это поможет, если у кого-то есть такая же проблема. Если кто-нибудь может найти лучшее решение/объяснение, пожалуйста, поделитесь!

Cheers,