Почему вычисление плана выполнения занимает так много времени?

9

Один из наших клиентов только что перешел на новый сервер.

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

Это наводит меня на мысль, что первые три минуты в основном используются для расчета плана выполнения. Последующие запуски затем просто используют кэшированный план и запускаются мгновенно.

В наших тестовых базах данных для расчета плана для той же процедуры требуется около 5 секунд.

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

Сервер состоит из 16 ядер с 24 ГБ памяти. Не происходит большой загрузки процессора или памяти.

Что может быть причиной таких медленных вычислений только в конкретной базе данных?

Какие шаги я могу предпринять, чтобы найти причину проблемы?

редактировать

Поэтому мне удалось получить доступ к серверу и выполнить запрос с помощью SET SHOWPLAN_XML ON .

Я могу подтвердить, что CompileTime для запроса занимает 99% времени выполнения запроса. StatementOptmEarlyAbortReason является «TimeOut» , на нашей тестовой базе данных с копией базы данных их причина MemoryLimitExceeded.

sql-server sql-server-2008 execution-plan Mongus Pong
источник
1
Вы уверены, что компиляция плана занимает много времени, а не только чтение данных в кэш с диска?
Марк Стори-Смит
1
Время компиляции отображается в самом XML-плане. Вы определили, что это определенно время компиляции, а не что-то еще, например, синхронное автоматическое обновление статистики? На какой версии SQL Server вы работаете?
Мартин Смит
@ MarkStorey-Smith Ну, я не уверен ни в чем. Я знаю, что запуск DBCC FREEPROCCACHE , который только очищает этот кэш плана, займет время следующего запроса до 3 минут.
Mongus Pong
@MartinSmith Ах да, очень полезно, я использую план визуального запроса. Да, время компиляции составляет примерно все время выполнения запроса. Мы находимся на SQL Server 2008 R2.
Mongus Pong
@MongusPong - Если вы создаете только статистическую копию производственной базы данных, можете ли вы воспроизвести ее в своей тестовой среде? Что говорится в плане StatementOptmEarlyAbortReason?
Мартин Смит

Ответы:

9

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

Проблема была из-за некоторой нечеткой статистики в базе данных. Глядя на план выполнения, оптимизатор ожидал 11,5 ТБ данных, возвращенных из запроса. На самом деле это было получение 87kb. Теперь я знаю, что огромные несоответствия между ожидаемыми и реальными возвращаемыми строками являются признаком того, что статистика устарела.

Просто работает

exec sp_updatestats

заставляет базу данных обновлять статистику для всех таблиц.

Это уменьшило время выполнения запроса с 3 минут до 6 секунд. Каждый победитель!

Спасибо за всю помощь, ребята. : 0)

Mongus Pong
источник