У мене є звіт SSRS, який викликає збережену процедуру. Якщо я запущу збережену процедуру безпосередньо з вікна запиту, вона повернеться за 2 секунди. Однак той самий запит, що виконується із звіту 2005 SSRS, займає до 5 хвилин. Це відбувається не просто з першого запуску, це відбувається кожного разу. Крім того, я не бачу цієї ж проблеми в інших середовищах.
Будь-які ідеї щодо того, чому звіт SSRS буде працювати так повільно у цьому конкретному середовищі?
Відповіді:
Дякуємо за наведені тут пропозиції. Ми знайшли рішення, і воно, як виявилося, пов’язане з параметрами. SQL Server створював заплутаний план виконання під час виконання із звіту SSRS через "нюхання параметрів". Обхідним шляхом було оголошення оголошень змінних всередині збереженої процедури та присвоєння змінним вхідних параметрів. Тоді в запиті використовували змінні, а не параметри. Це призвело до того, що запит виконувався послідовно, незалежно від того, викликаний він із менеджера SQL Server або через звіт SSRS.
Додайте це до кінця вашого процесу: option(recompile)
Це змусить звіт працювати майже так само швидко, як збережена процедура
Додам, що у мене була та сама проблема із запитом не збереженої процедури - просто звичайний оператор select. Щоб це виправити, я оголосив змінну в операторі SQL набору даних і встановив її рівною параметру SSRS.
Яке надокучливе обхідне рішення! Тим не менше, дякую усім, що наблизили мене до відповіді!
У мене була та сама проблема, ось мій опис проблеми
"Я створив процедуру магазину, яка генерує 2200 рядків і виконується майже за 2 секунди, однак після виклику процедури зберігання з SSRS 2008 і запуску звіту, який насправді ніколи не виконувався, і врешті-решт я повинен вбити BIDS (Студія розвитку бізнес-аналітики) з диспетчера завдань ".
На чому я спробував: я спробував запустити SP з входу reportuser, але SP працював нормально і для цього користувача, я перевірив Profiler, але нічого не вийшло.
Рішення:
Насправді проблема полягає в тому, що навіть незважаючи на те, що SP генерує результат, але механізму SSRS потрібен час, щоб прочитати ці багато рядків і відтворити його назад. Тому я додав опцію WITH RECOMPILE у SP та запустив звіт .. саме тоді сталося диво і моя проблема отримала рішення.
У мене траплявся той самий сценарій .. Дуже базовий звіт, SP (який займає лише 1 параметр) забирав 5 секунд, щоб повернути 10K записів, проте для звіту знадобиться 6 хвилин. За даними профілювача та таблиці RS ExecutionLogStorage, у звіті витрачався весь час на запит. Коментар Брайана С. привів мене до рішення .. Я просто додав WITH RECOMPILE перед твердженням AS у ІП, і тепер час звіту майже відповідає часу виконання ІП.
Якщо у вашій збереженій процедурі використовуються зв’язані сервери або openquery , вони можуть швидко запускатися самі по собі, але тривалий час відображаються в SSRS. Деякі загальні поради:
Я бачу, що на запитання відповіли, я просто додаю це на випадок, якщо хтось має те саме питання.
У мене виникла проблема з виходом html звіту при отриманні 32000 рядків. Запит виконувався швидко, але вихід у веб-браузер був дуже повільним. У моєму випадку мені довелося активувати “Інтерактивне підкачування”, щоб користувач міг бачити першу сторінку та мати можливість генерувати файл Excel. Плюси цього рішення в тому, що перша сторінка з’являється швидко, і користувач може генерувати експорт до Excel або PDF, мінуси в тому, що користувач може прокручувати лише поточну сторінку. Якщо користувач хоче бачити більше вмісту, він повинен використовувати кнопки навігації над сіткою. У моєму випадку користувач прийняв таку поведінку, оскільки експорт до Excel був важливішим.
Щоб активувати “Інтерактивне підкачування”, потрібно натиснути на вільну область на панелі звіту та змінити властивість “InteractiveSize” \ “Height” на рівні звіту на панелі властивостей. Встановіть для цієї властивості відмінне значення від 0. У моєму випадку я встановив 8,5 дюймів. Також переконайтеся, що ви зняли прапорець «Зберігати разом на одній сторінці, якщо це можливо» на рівні Tablix (клацніть правою кнопкою миші на Tablix, потім «Властивості Tablix», а потім «Загальні» \ «Параметри розриву сторінки»).
Я зіткнувся з подібною проблемою моєї збереженої процедури, яка швидко виконувалась із Management Studio, але дуже повільно виконувалась із SSRS. Після тривалої боротьби я вирішив цю проблему, видаливши збережену процедуру фізично та відтворивши її. Я не впевнений у логіці, яка стоїть за цим, але я припускаю, що це через зміну структури таблиці, яка використовується у збереженій процедурі.
Окрім проблеми з нюханням параметрів, я виявив, що SSRS, як правило, повільніше працює на стороні клієнта, ніж (у моєму випадку) звіти Crystal. Механізм SSRS просто не здається таким здатним, коли у ньому багато рядків для локального фільтрування або агрегування. Звичайно, це проблеми з дизайном набору результатів, на які часто можна звернутись (хоча і не завжди, якщо для деталізації потрібні деталі), але чим гм ... зріліший ... механізм звітності тим простіший.
Кілька речей, які ви можете зробити, не виконуючи фактичний звіт, просто запустіть sproc з вкладки даних служб звітності. Це все-таки вимагає часу? Інший варіант - використовувати SQL Profiler і визначити, що надходить і виходить із системи баз даних.
Інша справа, яку ви можете зробити для його тестування, щоб відтворити простий звіт без будь-яких параметрів. Запустіть звіт і перевірте, чи це має значення. Можливо, ваш звіт RS пошкоджений або погано сформований, що може призвести до того, що візуалізація буде дійсно повільною.
ВИ використовуєте "групувати" у таблиці SSRS?
У мене був звіт із 3 згрупованими за полями, і я помітив, що звіт працював дуже повільно, незважаючи на легкий запит, до такої міри, що я навіть не можу набрати значення в полі пошуку.
Потім я видалив групування, і тепер звіт зростає за лічені секунди, і все працює в одну мить.
У нашому випадку код не потрібен.
Примітка нашої довідкової служби: "Видалення налаштувань Інтернету вирішить цю проблему".
Можливо, це означає "очистити кеш".