Случайный тайм-аут при запуске сохраненного процесса - сбросить воссоздать исправления

Question

Так что я работаю с большой базой данных (30 гигов) SQL 2005 с веб-интерфейсом .net 3.5 в 10-летней системе.У него есть новые и старые биты

Мы сталкиваемся с проблемой, которая возникает все чаще и чаще.

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

Сразу после этого я выполняю тот же самый вызов, и это занимает (вошел как я) 1 сек.

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

Решение работает, но я не совсем понимаю, почему.

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

Для каждого релиза мы выполняем SQL-скрипт со всеми сохраненными procs / triggers / functions / views при каждом удалениии воссоздание самого себя.

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

Я думаю о вызове опции sps WITH RECOMPILE,это нет-нет ??или приемлемый способ

Answer 1

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

Если у вас есть «необязательные» параметры - где NULL или значение может быть передано,и вы используете OR в предложении WHERE, чтобы справиться с этим, тогда это обычно приведет к подобным вещам.

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

В общем,лучше попытаться переписать запрос - если вы используете OR s, чтобы справиться с различными наборами параметров,n динамический SQL (выполненный правильно, используя sp_executesql с параметрами) может очень помочь.

PS Что касается хранимой процедуры, работающей нормально, когда вы ее запускаете - я тоже это видел - я ожидаю, что она досоздание другого плана - мое подозрение всегда заключалось в том, что при запуске, например, в SSMS, включается несколько иной набор SET параметров, чем (в моем случае) .Net - и планы в этом случае кэшируются отдельно.Если кто-нибудь может подтвердить, что это может произойти, это будет оценено!

Answer 2

Скорее всего, это результат неправильного плана выполнения, сохраненного для конкретного процесса.

Проблема (упрощенная) в том, что сервер SQL пытается оптимизировать использование планов выполнения на основе переданных параметров. В некоторых случаях это может привести к ужасным результатам.

Вот какое-то чтение, чтобы объяснить это дальше.

http://blogs.msdn.com/b/queryoptteam/archive/2006/03/31/565991.aspx
http://elegantcode.com/2008/05/17/sql-parameter-sniffing-and-what-to-do-about-it/

С другой стороны, это очень просто исправить, скопировав переданные параметры в proc в локальные переменные.

Answer 3

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