Низкая производительность служб Reporting Services, очень быстрая в QueryAnalyser

Question

Мы используем SQL Server 2005 со службами отчетов.

У нас есть несколько отчетов, каждый из которых содержит относительно простой запрос SQL - под словом «относительно» я подразумеваю, что у нас есть несколько объединений, но ничего хуже. Мы не вызываем хранимые процедуры в наших запросах - это не случайный анализ параметров.

При выполнении одного из этих отчетов (назовем его отчетом A) через службы Reporting Services для его выполнения требуется очень много времени - порядка десятков минут или даже часов. При выполнении соответствующего запроса SQL в Query Analyzer он завершается через несколько секунд.

Количество строк, возвращаемых из базы данных, может быть всего 1 - но отчет так и не завершится.

Остальные отчеты работают нормально.

Глядя в таблицу ExecutionLog в службах Reporting Services, я вижу, что большую часть времени находится в TimeDataRetrieval (а мы говорим миллионы секунд здесь ...) - в те моменты, когда отчет фактически завершается. Если отчет отменяется вручную, TimeDataRetrieveal равен нулю, а вместо этого TimeProcessing невероятно высок.

Я просмотрел журналы Reporting Services, но все выглядит нормально.

Теперь, прежде чем вы начнете предлагать "блокировку" - ну, в наших запросах включена подсказка nolock.

В нынешнем виде я достиг предела своего воображения, пытаясь найти ошибку. Любые мысли, идеи будут с благодарностью.

/ Кристоффер

Answer 1

Я заканчивал тем, что отбрасывал запрос, в основном по одному утверждению за раз, пока не нашел виновника. Одно из объединений в запросе объединяется в постоянно растущей таблице (миллионы строк) с помощью подсказки «with (nolock index (x))».

Удаление подсказки индекса в Query Analyzer дает мне тот же результат, что и в службах Reporting Services - очень медленный запрос. Это само по себе неудивительно, но на самом деле казалось, что запрос, выполняемый через RS, не использует подсказку.

Затем я снова попытался запустить отчет в RS, используя инструкцию SET FORCEPLAN ON. И ... это сработало - время выполнения теперь несколько секунд, как и должно быть. Насколько я понимаю, опция FORCEPLAN заставляет SQL Server обрабатывать объединения в указанном порядке и принимать во внимание любые подсказки.

Кто-нибудь знает, почему запрос через RS будет игнорировать подсказку, когда Query Analyzer, очевидно, учитывает это?

Answer 2

Я столкнулся с такой же ситуацией.

В Management Studio результаты пришли через двадцать секунд, но когда я запустил отчет в Visual Studio, он заблокировал систему.

В профилировщике SQL я проследил запрос и понял, что он преобразует мой запрос в:

    exec sp_executesql N'
                ....................
                ....................' 
, @dateparameter1 = '2010-06-01 00:00:00'
, @datepamareter2 = '2010-06-02 00:00:00'
, @stringparameter=null

Я изучил план выполнения и понял, что стал жертвой перехвата параметров.

Я реорганизовал свой запрос, как было сказано здесь , и теперь он работает нормально ..

Answer 3

Во время выполнения отчета попробуйте совместно перехватить план выполнения с помощью SQL Profiler. Посмотрите, если у вас нет операторов CONVER_IMPLICIT, например, и сканирования таблиц / индексов в целом.

http://msdn.microsoft.com/en-us/library/ms190233.aspx

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

Вы можете попытаться добавить OPTION (RECOMPILE) к запросу отчета, возможно, ваш отчет является жертвой перехвата параметров .

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

Answer 4

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

Что я сделал, так это создал представление для фильтра, и оно было решено.

Answer 5

Быстрое обновление: может показаться, что любой запрос, выполнение которого занимает более 30 секунд, автоматически приведет к превышению времени ожидания в службах Reporting Services. Хотя команда SET FORCEPLAN ON решала проблемы для некоторых отчетов, все еще оставались сообщения о проблемах, срок действия которых истекает. Эти запросы все еще работали в Query Analyzer, хотя время их выполнения превышало 30 секунд. После устранения всех других возможных проблем с настройками тайм-аута - на сервере SQL, в службах Reporting Services, rsserver.config, в IIS - я обнаружил, что тайм-аут все еще не может быть изменен.

Я подозреваю, что это связано с тайм-аутом по умолчанию ADO.NET, и что Microsoft не оставила нам способа изменить это значение.

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

Однако это неизменяемое время ожидания меня беспокоит - что произойдет, если при выполнении запроса нагрузка на сервер SQL будет выше, чем обычно?