Почему SSRS сообщает о превышении времени ожидания, когда хранимая процедура, на которой она основана, возвращает результаты в течение нескольких секунд?

Question

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

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

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

Я знаю, что хранимая процедура могла бы быть оптимизирована больше, но я не понимаю, почему SSRS будет время ожидания, когда кажется, что выполнение только из нескольких секунд для выполнения из SSMS.

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

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

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

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

Проблема также, кажется, возникает только в нашей производственной среде. Наши платформы тестирования и разработки, похоже, не демонстрируют ту же проблему. Хотя dev и test не имеют того же объема записей, что и production.

Answer 1

У меня также была эта проблема, когда SPROC требуется несколько секунд для запуска, но SSRS просто истекает.

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

1. Параметр сниффинг! Когда ваша хранимая процедура выполняется из SSRS, она будет "вынюхивать" ваши параметры, чтобы увидеть, как ваш SPROC их использует. Затем SQL Server создаст план выполнения на основе своих выводов. Это хорошо при первом запуске SPROC, но вы не хотите, чтобы он делал это каждый раз, когда запускаете отчет. Поэтому я объявляю новый набор переменных в верхней части моего SPROC, который просто хранит параметры, переданные в запросе, и использует эти новые параметры в запросе.

Пример:

CREATE PROCEDURE [dbo].[usp_REPORT_ITD001]
@StartDate DATETIME,
@EndDate DATETIME,
@ReportTab INT
AS

-- Deter parameter sniffing
DECLARE @snf_StartDate DATETIME = @StartDate
DECLARE @snf_EndDate DATETIME = @EndDate
DECLARE @snf_ReportTab INT = @ReportTab

... это означает, что когда ваш SPORC выполняется SSRS, он просматривает только первые несколько строк в вашем запросе для переданных параметров, а не весь ваш запрос. Что значительно сокращает время выполнения в SSRS.

1. Если в вашем SPROC есть много временных таблиц, которые объявлены как переменные (DECLARE @MyTable AS TABLE), они очень интенсивно работают на сервере (в плане памяти) при создании отчетов. Используя вместо этого временные таблицы хеш-функции (SELECT MyCol1, MyCol2 INTO #MyTable), SQL Server будет хранить ваши временные таблицы в TempDB на сервере, а не в системной памяти, что делает создание отчетов менее интенсивным.

Answer 2

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

Если вы добавляете много строк в конец диапазона столбца (подумайте о добавлении автономных номеров, или метки времени), гистограмма для этого колонка быстро устареет. Вы можете заставить немедленное обновление от T-SQL, выполнив ОБНОВЛЕНИЕ СТАТИСТИКА.

Answer 3

иногда помогает добавление опции WITH RECOMPILE в оператор CREATE хранимой процедуры. Это эффективно в ситуациях, когда количество записей, исследуемых процедурой, изменяется так, что исходный план выполнения не является оптимальным.

Answer 4

По сути, все, что я до сих пор делал, это немного оптимизировал sproc, и, похоже, это хотя бы временно решило проблему.

Я все еще хотел бы знать, в чем разница между вызовом sproc из SSMS и SSRS.