У меня есть отчет SSRS, который вызывает хранимую процедуру. Если я запустил хранимую процедуру непосредственно из окна запроса, она вернется менее чем за 2 секунды. Тем не менее, тот же запрос, который запускается из отчета SSRS 2005 года, занимает до 5 минут. Это происходит не только при первом запуске, это происходит каждый раз. Кроме того, я не вижу этой проблемы в других средах.
Любые идеи о том, почему отчет SSRS будет работать так медленно в этой конкретной среде?
Спасибо за предоставленные здесь предложения. Мы нашли решение, и оно оказалось связанным с параметрами. SQL Server создавал свернутый план выполнения при выполнении из отчета SSRS из-за "обнюхивания параметров". Обходной путь состоял в том, чтобы объявлять переменные внутри хранимой процедуры и назначать входящие параметры для переменных. Затем в запросе использовались переменные, а не параметры. Это привело к тому, что запрос выполнялся последовательно, вызванный из диспетчера SQL Server или с помощью отчета SSRS.
Добавьте это в конец вашего proc: option(recompile)
Это приведет к тому, что отчет будет выполняться почти так же быстро, как хранимая процедура
Я добавлю, что у меня была та же проблема с запросом не хранимой процедуры - просто простой оператор select. Чтобы исправить это, я объявил переменную в операторе SQL набора данных и установил ее равным параметру SSRS.
Какое раздражающее обходное решение! Тем не менее, благодарю вас всех за то, что привлек меня к ответу!
У меня была та же проблема, вот мое описание проблемы
"Я создал процедуру хранилища, которая будет генерировать 2200 строк и будет выполняться почти через 2 секунды, но после вызова процедуры хранения из SSRS 2008 и запуска отчета, который он фактически никогда не запускал, и в конечном итоге мне нужно убить BIDS (Business Intelligence Development Studio) из диспетчера задач".
Что я пробовал: я попробовал запустить SP из входа в Reportuser, но SP тоже работал нормально для этого пользователя, я проверил Profiler, но ничего не получилось.
Решение:
На самом деле проблема заключается в том, что даже если SP генерирует результат, но механизм SSRS занимает время, чтобы прочитать эти много строк и вернуть их обратно. Поэтому я добавил параметр WITH RECOMPILE в SP и запустил отчет.. это произошло, когда произошло чудо, и моя проблема была решена.
У меня был такой же сценарий... Главный базовый отчет, SP (который принимает только 1 параметр), занимал 5 секунд, чтобы вернуть 10K записей, но для отчета потребуется 6 минут. Согласно профилировщику и таблице RS ExecutionLogStorage, отчет тратил все время на запрос. Комментарий Brian S. привел меня к решению. Я просто добавил WITH RECOMPILE перед выражением AS в SP, и теперь время отчета в значительной степени соответствует времени выполнения SP.
Я просто не выбрал "Повторить столбцы заголовков на каждой странице" в свойствах Tablix.
Если ваша хранимая процедура использует связанные серверы или openquery, они могут запускаться быстро самостоятельно, но в SSRS требуется много времени. Некоторые общие рекомендации:
Я вижу, что на вопрос был дан ответ, я просто добавляю это, если у кого-то есть такая же проблема.
Я столкнулся с аналогичной проблемой моей хранимой процедуры, выполняющейся быстро из Management Studio, но очень медленной с SSRS. После долгой борьбы я решил эту проблему, физически уничтожая хранимую процедуру и воссоздавая ее. Я не уверен в логике этого, но я предполагаю, что это связано с изменением структуры таблицы, используемой в хранимой процедуре.
У меня возникла проблема с выходом отчета html в отчете, в котором было получено 32000 строк. Запрос выполнялся быстро, но вывод в веб-браузер был очень медленным. В моем случае мне пришлось активировать "Интерактивный пейджинг", чтобы пользователь мог видеть первую страницу и иметь возможность генерировать файл Excel. Преимуществом этого решения является то, что первая страница появляется быстро, и пользователь может генерировать экспорт в Excel или PDF, минусы - это то, что пользователь может прокручивать только текущую страницу. Если пользователь хочет увидеть больше контента, он должен использовать кнопки навигации над сеткой. В моем случае пользователь принял это поведение, потому что экспорт в Excel был более важным.
Чтобы активировать "Интерактивный пейджинг", вы должны щелкнуть по свободной области в панели отчета и изменить свойство "InteractiveSize" \ "Height" на уровне отчета в панели "Свойства". Установите это свойство в отличие от 0. Я установил 8,5 дюйма в моем случае. Также убедитесь, что вы сняли флажок "Держать вместе на одной странице, если это возможно" на уровне Tablix (щелкните правой кнопкой мыши на Tablix, затем "Свойства табликса", затем "Общие" \ "Параметры разрыва страницы" ).
I Столкнулась с той же проблемой. Для меня это было просто отменить выбор:
Свойства Tablix = > Вариант разрыва страницы = > Держите вместе на одной странице, если возможно
Отчет SSRS. Он пытался поместить все записи на одну и ту же страницу, а не создавать много страниц.
Помимо проблемы с параметром-обнюхивания, я обнаружил, что SSRS, как правило, медленнее обрабатывается на стороне клиента, чем (в моем случае) отчеты Crystal. Двигатель SSRS просто не кажется таким же способным, когда у него есть много строк для локального фильтрации или агрегации. Конечно, это проблемы с дизайном набора результатов, которые часто могут быть решены (хотя не всегда, если детали необходимы для детализации), но тем больше um... зрелый... механизм отчетности более прост.
В моем случае мне просто пришлось отключить и подключить SSMS. Я профилировал запрос, и продолжительность выполнения показывала 1 минуту, хотя сам запрос выполнялся менее 2 секунд. Перезагрузили соединение и снова запустили, на этот раз продолжительность показала правильное время выполнения.
Пара вещей, которые вы можете сделать, не выполняя фактический отчет, просто запускает sproc из вкладки данных служб отчетов. По-прежнему требуется время? Другой вариант - использовать SQL Profiler и определить, что входит в систему базы данных и выходит из нее.
Еще одна вещь, которую вы можете сделать, чтобы проверить ее, чтобы воссоздать простой отчет без каких-либо параметров. Запустите отчет и посмотрите, не изменилось ли оно. Возможно, ваш отчет RS поврежден или плохо сформирован, что может привести к тому, что рендеринг будет очень медленным.
Имел ту же проблему и исправил ее, предоставив общий набор данных по умолчанию и обновив этот набор данных на сервере отчетов.
Используете ли вы "group by" в таблице SSRS?
У меня был отчет с 3 группами по группам, и я заметил, что отчет работает очень медленно, несмотря на легкий запрос, до такой степени, что я даже не могу набрать значения в поле поиска.
Чем я удалил группировки, и теперь отчет увеличивается за считанные секунды, и все работает мгновенно.
Я смог решить эту проблему, удалив встроенное поле [& TotalPages] снизу. Время, когда вниз с минуты до секунды.
Что-то странное, что я не мог определить, оказало влияние на подсчет общего количества страниц.
Я использовал SSRS 2012.
В нашем случае код не требовался.
Обратите внимание, что в нашей справочной службе: "Очистка настройки Интернета исправит эту проблему".
Возможно, это означает "очистить кеш".