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

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

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

71 голос | спросил user275554 17 FebruaryEurope/MoscowbWed, 17 Feb 2010 22:55:31 +0300000000pmWed, 17 Feb 2010 22:55:31 +030010 2010, 22:55:31

17 ответов


0

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

ответил user275554 18 FebruaryEurope/MoscowbThu, 18 Feb 2010 00:47:17 +0300000000amThu, 18 Feb 2010 00:47:17 +030010 2010, 00:47:17
0

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

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

ответил Brian Smedley 23 MarpmWed, 23 Mar 2011 21:51:28 +03002011-03-23T21:51:28+03:0009 2011, 21:51:28
0

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

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

ответил JHFB 20 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 20 Sep 2011 22:52:33 +0400 2011, 22:52:33
0

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

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

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

Решение:

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

ответил Redroidmator 19 +04002012-10-19T01:32:47+04:00312012bEurope/MoscowFri, 19 Oct 2012 01:32:47 +0400 2012, 01:32:47
0

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

ответил Rod C 18 PM00000040000002731 2011, 16:59:27
0

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

ответил Antony 8 +04002012-10-08T02:05:47+04:00312012bEurope/MoscowMon, 08 Oct 2012 02:05:47 +0400 2012, 02:05:47
0

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

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

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

ответил bubbassauro 24 MarpmMon, 24 Mar 2014 22:52:15 +04002014-03-24T22:52:15+04:0010 2014, 22:52:15
0

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

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

 введите описание изображения здесь

ответил Alexey Sukhanov 1 J0000006Europe/Moscow 2016, 17:13:04
0

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

ответил jay 19 Jpm1000000pmWed, 19 Jan 2011 20:10:00 +030011 2011, 20:10:00
0

Я столкнулся с той же проблемой. Для меня это было просто, чтобы разблокировать опцию:

  

Свойства Tablix => Параметр разрыва страницы => Хранить вместе на одной странице, если это возможно

Отчета SSRS. Он пытался поместить все записи на одну и ту же страницу, а не создавать много страниц.

ответил Joanne 18 J000000Wednesday12 2012, 22:42:58
0

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

ответил Steve 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 24 Sep 2013 23:48:45 +0400 2013, 23:48:45
0

В моем случае мне просто нужно было отключиться и подключить SSMS. Я профилировал запрос, и продолжительность его выполнения составляла 1 минуту, хотя сам запрос выполнялся менее 2 секунд. Перезапустил соединение и снова запустился, на этот раз продолжительность показала правильное время выполнения.

ответил Ranjan 12 AM000000120000005231 2017, 00:37:52
0

Пара вещей, которые вы можете сделать, не выполняя реальный отчет, просто запустите sproc на вкладке данных служб отчетов. Это все еще занимает время? Другой вариант - использовать SQL Profiler и определять, что входит и выходит из системы базы данных.

Еще одна вещь, которую вы можете сделать, чтобы протестировать ее - воссоздать простой отчет без каких-либо параметров. Запустите отчет и посмотрите, имеет ли это значение. Возможно, ваш отчет RS поврежден или неправильно сформирован, что может привести к очень медленной визуализации.

ответил JonH 17 FebruaryEurope/MoscowbWed, 17 Feb 2010 23:07:11 +0300000000pmWed, 17 Feb 2010 23:07:11 +030010 2010, 23:07:11
0

Возникла та же проблема, и она была исправлена ​​путем предоставления общему набору данных параметра по умолчанию и обновления этого набора данных на сервере отчетов.

ответил Solomon 13 AM00000020000001231 2014, 02:49:12
0

Вы используете "group by" в таблице SSRS?

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

Чем я удалил группировки, и теперь отчет увеличивается за считанные секунды, и все работает в одно мгновение.

ответил Riddle-Master 17 J000000Sunday16 2016, 08:59:52
0

В моем случае я смог решить эту проблему, только удалив встроенное поле [& TotalPages] снизу. Время, когда вниз от минуты до менее секунды.

Что-то странное, что я не мог определить, оказало влияние на подсчет общего количества страниц.

Я использовал SSRS 2012.

ответил ByteArtisan 20 PMpThu, 20 Apr 2017 20:04:44 +030004Thursday 2017, 20:04:44
0

В нашем случае код не требуется.

Примечание нашей справочной службы: «Очистка настроек Интернета решит эту проблему».

Может быть, это означает "очистить кеш".

ответил user7788038 29 MarpmWed, 29 Mar 2017 22:44:16 +03002017-03-29T22:44:16+03:0010 2017, 22:44:16

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132