Медленная работа Reporting Services, очень быстро в QueryAnalyser
Мы используем SQL Server 2005 с Reporting Services.
У нас есть много отчетов, каждый содержащий относительно простой SQL-запрос - "относительно" я подразумеваю, что у нас действительно есть несколько соединений, но ничто худшее, чем это. Мы не называем хранимых процедур в наших запросах - это не случай сниффинга параметра.
При выполнении одного из этих отчетов (позволяют нам назвать это отчетом A) через Reporting Services, это чрезвычайно занимает много времени для завершения - на порядке десятков минут или даже часов. При выполнении соответствующего SQL-запроса в Query Analyzer это завершается за несколько секунд.
Количество строк, возвращенных из базы данных, может быть только 1 - все же, отчет никогда не завершается.
Другие отчеты хорошо работают.
Смотря в таблице ExecutionLog на Reporting Services, я вижу, что большая часть времени находится в TimeDataRetrieval (и мы говорим миллионы секунд здесь...) - те времена, которые на самом деле завершает отчет. Если отчет вручную прерывается, TimeDataRetrieveal является нулем, и TimeProcessing нелепо высок вместо этого.
Я изучил журналы Reporting Services, но все выглядит нормальным.
Теперь, прежде чем Вы начинаете предлагать "блокировку" - хорошо, нашим запросам действительно включали подсказку nolock.
В настоящий момент я достиг предела своего воображения, пытающегося найти ошибку. Любые мысли, понимание с удовольствием ценилось бы.
/Christoffer
4 ответа
В конце концов я вырезал запрос, в основном по одному утверждению за раз, пока не нашел виновника. Одно из объединений в запросе объединено в постоянно растущую таблицу (миллионы строк) с использованием подсказки «with (nolock index (x))».
Удаление подсказки индекса в Query Analyzer дало тот же результат, что и в службах Reporting Services - очень медленный запрос. Само по себе это неудивительно - но действительно казалось, что запрос при запуске через RS не использовал подсказку.
Затем я снова попытался запустить отчет в RS с помощью оператора SET FORCEPLAN ON. И ... это сработало - время выполнения теперь несколько секунд, как и должно быть. Насколько я понимаю, опция FORCEPLAN заставляет SQL Server обрабатывать соединения в указанном порядке И принимать во внимание любые подсказки.
Кто-нибудь знает, почему запрос через RS игнорирует подсказку, когда Анализатор запросов явно учитывает ее?
Во время выполнения отчета попробуйте перехватить план выполнения с помощью SQL Profiler. Посмотрите, нет ли у вас операторов CONVER_IMPLICIT, например, и сканирования таблиц/индексов в целом.
http://msdn.microsoft.com/en-us/library/ms190233.aspx
Преобразования препятствуют использованию индексов и могут произойти, если вы передаете параметры, тип которых отличается от типа столбцов, с которыми вы их сравниваете.
Вы можете попробовать добавить OPTION(RECOMPILE) в запрос отчета, возможно, что ваш отчет стал жертвой перебора параметров.
Проверьте, не используются ли в ваших запросах скалярные функции, определяемые пользователем. Они могут быть настоящими убийцами производительности. Если они у вас есть, возможно, их можно преобразовать в табличные функции.
Небольшое обновление: похоже, что любой запрос, выполнение которого занимает более 30 секунд, автоматически вызывает тайм-аут в Reporting Services. Хотя установка SET FORCEPLAN ON решила проблемы для некоторых отчетов, все еще оставались проблемные отчеты, которые отключались по таймеру. Эти запросы по-прежнему нормально работали в Query Analyzer, хотя время выполнения превышало 30 секунд. После устранения всех других возможных проблем с настройками тайм-аута - на SQL-сервере, в Reporting Services, rsserver.config, в IIS - я обнаружил, что по-прежнему существует тайм-аут, который я не могу изменить.
Я подозреваю, что это связано с тайм-аутом ADO.NET по умолчанию, и что Microsoft не оставила нам возможности изменить это значение.
В конце концов, я более глубоко изучил запрос, изменил его в лучшую сторону, и мне удалось убрать несколько секунд из времени выполнения. Теперь, наконец, отчеты работают так, как должны.
Однако этот немодифицируемый тайм-аут беспокоит меня - что произойдет, если в момент выполнения запроса нагрузка на SQL-сервер будет выше нормы?
.Я столкнулся с такой же ситуацией.
В 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
Я изучил план выполнения и понял, что стал жертвой перехвата параметров.
Я реорганизовал свой запрос, как было сказано здесь , и теперь он работает нормально ..