Хранимая процедура, вызывающая таймаут только при запуске из приложения

Question

У нас возникла проблема с sp.

У нас есть довольно простой sp, содержащий объявленную таблицу и пару внешних объединений, которые в конце возвращают от 20 до 100 строк.

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

Мы выпустили его в производство только для того, чтобы выяснить, что оно все еще очень медленное и вызывает истечение времени ожидания нашего приложения .NET 2.0 при его вызове.

Мы ничего не поняли и пошли в Management Studio на производственную базу данных и запустили там sp, он выполняется менее чем за 1 сек.

То есть, когда он запускается из нашего приложения, он чрезвычайно медленный и вызывает таймауты, а при запуске из Management Studio он очень быстрый и никогда не занимает больше секунды.

Кто-нибудь с хорошим знанием SQL Server 2005, который может дать нам подсказку по этому поводу?

Answer 1

Я думаю, что ваша проблема может быть в "Обнаружении параметров". Это процесс, когда среда выполнения SQL Server «вынюхивает» значения параметров sp во время компиляции или перекомпилирует для создания более быстрых планов выполнения. Но иногда он получает комбинацию параметров, которая вместе с текущими данными, которые возвращает sp, делает очень медленный sp.

Есть несколько хороших объяснений. Поиск по Stackoverflow. Это одно хорошо http://omnibuzz -sql.blogspot.com / 2006/11 / параметр обнюхивать сохраненную-procedures.html

Одним из возможных решений является создание локальных переменных в sp и установка для них значений входящих параметров. Тогда используйте только локальные переменные в sp.

CREATE PROCEDURE [dbo].spTest
  @FromDate as DATETIME
AS
BEGIN
  DECLARE @FromDate_local as DATETIME
  SET @FromDate_local = '2009-01-01'

  SET @FromDate_local = @FromDate
  ...
  SELECT * FROM TestTbl WHERE FromDate >= @FromDate_local
END

Answer 2

Recompile - тупой инструмент. Скорее всего, нюхает параметр

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

Answer 3

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

Однако не понимаю, что перекомпиляция не была произведена, когда я изменил содержимое внутри sp?

Answer 4

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

Answer 5

Убедитесь, что ваша производственная база данных имеет актуальную статистику и индексы находятся в хорошем состоянии (если возможно, подумайте о перестройке задействованных индексов).