Быстрый запрос работает медленно в SSRS

Question

У меня есть отчет SSRS, который вызывает хранимую процедуру. Если я запускаю хранимую процедуру прямо из окна запроса, она вернется через 2 секунды. Однако тот же запрос, выполненный из отчета SSRS 2005, может занять до 5 минут. Это происходит не только при первом запуске, это происходит каждый раз. Кроме того, я не вижу такой же проблемы в других средах.

Есть идеи, почему отчет SSRS будет работать так медленно в этой конкретной среде?

Answer 1

Спасибо за предложения, представленные здесь.Мы нашли решение, и оно оказалось связанным с параметрами.SQL Server создавал замысловатый план выполнения при выполнении из отчета SSRS из-за «перехвата параметров».Обходной путь должен был объявить переменные внутри хранимой процедуры и назначить входящие параметры переменным.Тогда запрос использовал переменные, а не параметры.Это привело к тому, что запрос выполнялся последовательно независимо от того, вызывается ли он из диспетчера SQL Server или из отчета SSRS.

Answer 2

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

Какой досадный обходной путь! Тем не менее, спасибо всем за то, что приблизили меня к ответу!

Answer 3

Добавьте это в конец вашего процесса: option(recompile)

Это сделает отчет почти таким же быстрым, как и хранимая процедура

Answer 4

У меня была такая же проблема, вот мое описание проблемы

"Я создал процедуру хранилища, которая генерировала бы 2200 строк и выполнялась почти через 2 секунды, однако после вызова процедуры хранилища из SSRS 2008 и запуска отчета, он фактически никогда не выполнялся, и в конечном итоге мне нужно убить BIDS (Business Intelligence Студия разработки) из диспетчера задач ".

Что я пробовал: я пытался запустить SP из Reportuser Login, но SP также работал нормально для этого пользователя, я проверил Profiler, но ничего не получилось.

Решение:

На самом деле проблема в том, что, хотя SP генерирует результат, но движок SSRS тратит время, чтобы прочитать эти строки и обработать их. Поэтому я добавил опцию WITH RECOMPILE в SP и запустил отчет ... вот когда произошло чудо, и моя проблема была решена.

Answer 5

Если в вашей хранимой процедуре используются связанные серверы или openquery , они могут быстро выполняться сами по себе, но для рендеринга в SSRS потребуется много времени. Некоторые общие предложения:

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

Я вижу, что на вопрос дан ответ, я просто добавляю его на тот случай, если у кого-то возникнет такая же проблема.

Answer 6

Я просто отменил выбор «Повторять столбцы заголовков на каждой странице» в свойствах Tablix.

Answer 7

У меня был такой же сценарий. В очень простом отчете SP (который принимает только 1 параметр) потребовалось 5 секунд, чтобы вернуть записи 10K, но запуск отчета занял 6 минут. Согласно профилировщику и таблице RS ExecutionLogStorage, отчет тратит все время на запрос. Комментарий Брайана С. привел меня к решению. Я просто добавил WITH RECOMPILE перед оператором AS в SP, и теперь время отчета в значительной степени соответствует времени выполнения SP.

Answer 8

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

Answer 9

У меня были проблемы с выводом html-отчета при получении 32000 строк. Запрос выполнялся быстро, но вывод в веб-браузер был очень медленным. В моем случае мне пришлось активировать «Интерактивный пейджинг», чтобы позволить пользователю увидеть первую страницу и создать файл Excel. Плюсы этого решения в том, что первая страница появляется быстро, и пользователь может генерировать экспорт в Excel или PDF, минус в том, что пользователь может прокручивать только текущую страницу. Если пользователь хочет видеть больше контента, он должен использовать навигационные кнопки над сеткой. В моем случае пользователь принял это поведение, потому что экспорт в Excel был важнее.

Чтобы активировать «Интерактивный пейджинг», необходимо щелкнуть свободную область на панели отчетов и изменить свойство «InteractiveSize» \ «Высота» на уровне отчета на панели «Свойства». Установите для этого свойства значение, отличное от 0. Я установил значение 8,5 дюймов в моем случае. Также убедитесь, что вы сняли флажок «Хранить вместе на одной странице, если это возможно» на уровне табликса (щелкните правой кнопкой мыши на Tablix, затем «Свойства Tablix», затем «Общие» \ «Параметры разрыва страницы»).

Answer 10

Помимо проблемы с прослушиванием параметров, я обнаружил, что SSRS обычно медленнее при обработке на стороне клиента, чем (в моем случае) отчеты Crystal. Механизм SSRS не кажется таким способным, когда в нем много строк для локальной фильтрации или агрегирования. Конечно, это проблемы дизайна набора результатов, которые часто можно устранить (хотя и не всегда, если для детализации требуются подробности), но механизм отчетности ... более зрелый ... более щадящий.