Тайм-аут соединения с SQL - PullRequest
Новая
       7

Тайм-аут соединения с SQL

2 голосов
/ 29 августа 2011

Мы столкнулись со странными таймаутами соединения на одном из наших веб-сайтов.

Наша среда состоит из веб-сервера IIS 7 (работающего на Windows Server 2008 R2 Standard Edition) и сервера базы данных SQL Server 2008.

При отладке функциональности веб-сайта, которая вызывает тайм-аут, мы замечаем, что самому соединению требуется миллисекунды для завершения, но SqlCommand, который вызывает хранимую процедуру в базе данных, зависает на несколько минут во время выполнения, затемповышает исключение тайм-аута.

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

Мы уже попробовали следующее:

  • Изменено SqlCommand Тайм-аут на веб-сайте код
  • Изменено тайм-аут выполнения для web.config файла
  • Изменено sessionState Таймаут для web.config файла
  • Изменено время ожидания файла cookie авторизации для файла web.config
  • Изменено время ожидания соединения в свойствах веб-сайта на IIS
  • Изменено ограничение времени отключения пула приложений на IIS
  • Проверено приложениевремя ожидания пула в IIS
  • проверено время ожидания выполнения в свойствах SQL Server (оно равно 0, не ограничено)
  • протестировано хранимая процедура непосредственно в базе данных с другими параметрами

Мы ценим любую помощь.

Нирав

Ответы [ 3 ]

0 голосов
/ 06 декабря 2011

Несколько лет назад у меня была похожая проблема при переносе приложения с SQL2000 на SQL2008.

Я добавил OPTION (RECOMPILE) в конец всех хранимых процедур в базе данных, в которых возникли проблемы. В моем случае это было связано с параметрами, которые сильно различались между вызовами хранимого процесса. Принудительная перекомпиляция процедуры заставит SQL разработать новый план выполнения вместо попытки использовать кэшированную версию, которая может быть неоптимальной для новых параметров.

И если вы еще этого не сделали, проверьте свои индексы. Ничто не может убить производительность БД, как отсутствие крайне необходимого индекса. Вот хорошая ссылка (http://sqlfool.com/2009/04/a-look-at-missing-indexes/) на запрос, который покажет отсутствующие индексы.

0 голосов
/ 25 апреля 2013

Супер-супер позднее предложение, но может пригодиться другим: типичная проблема, которую я видел и которая скорее применима к Java, заключается в следующем:

У вас есть запрос, который принимает строку в качестве параметра.Эта строка является критерием поиска по столбцу varchar (N) в базе данных.тем не менее, вы отправляете строковый параметр в запросе как Unicode (nvarchar (N)).Это приведет к полному сканированию таблицы и преобразованию значений каждого поля в Unicode для правильного сравнения, чтобы избежать потенциальной потери данных (если SQL Server преобразует входной параметр в не-Unicode, он может потерять информацию).

Простой тест: выполните запрос дважды (для простоты я предполагаю, что это SP): 

exec spWhatever 'input'
exec spWhatever N'input'

Посмотрите, как они себя ведут.Кроме того, вы можете захотеть взглянуть на раздел «Недавние дорогостоящие запросы» на мониторе активности в SSMS и попросить план выполнения, чтобы прояснить ситуацию.

Cheers, Erik

0 голосов
/ 29 августа 2011

У меня была такая же проблема с хранимой процедурой, которая была функцией поиска для пользователей.Я перепробовал все, включая ARTIHABORT и т. Д. SP присоединился ко многим таблицам, так как пользователи могли искать что угодно.Многие параметры для SP были необязательными, то есть они имели значение по умолчанию NULL в SP.Ничего не помогло.

Я "исправил" это, убедившись, что мой код ADO.NET только добавил параметры, где пользователь выбрал значение.SP шел от многих минут до секунд во время выполнения.Я предполагаю, что SQL Server лучше обрабатывал план выполнения, когда в SP передавались только параметры с фактическими значениями.

Обратите внимание, что это было для SQL Server 2000.

...