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

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

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

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

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

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

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

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

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

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

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

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

sql-server sql-server-2008 execution-plan

— Mongus Pong
источник

Вы уверены, что компиляция плана занимает много времени, а не только чтение данных в кэш с диска?

— Марк Стори-Смит

Время компиляции отображается в самом XML-плане. Вы определили, что это определенно время компиляции, а не что-то еще, например, синхронное автоматическое обновление статистики? На какой версии SQL Server вы работаете?

— Мартин Смит

@ MarkStorey-Smith Ну, я не уверен ни в чем. Я знаю, что запуск DBCC FREEPROCCACHE , который только очищает этот кэш плана, займет время следующего запроса до 3 минут.

— Mongus Pong

@MartinSmith Ах да, очень полезно, я использую план визуального запроса. Да, время компиляции составляет примерно все время выполнения запроса. Мы находимся на SQL Server 2008 R2.

— Mongus Pong

@MongusPong - Если вы создаете только статистическую копию производственной базы данных, можете ли вы воспроизвести ее в своей тестовой среде? Что говорится в плане StatementOptmEarlyAbortReason?

— Мартин Смит

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

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

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

exec sp_updatestats

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

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

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

— Mongus Pong
источник