При просмотре предполагаемого плана выполнения генерируются CXPACKET, PAGELATCH_SH и LATCH_EX [ACCESS_METHODS_DATASET_PARENT] ожидания

Я использую Microsoft SQL Server 2016 с пакетом обновления 2 (SP2-CU6) (13.0.5292.0) на виртуальной машине с 4 виртуальными ЦП с max degree of parallelismустановленным значением 2и cost threshold for parallelismустановленным значением 50.

По утрам, при попытке отобразить примерный план выполнения для запроса SELECT TOP 100 , я сталкиваюсь с массовым ожиданием, и операция рендеринга оценочного плана занимает минуты, часто раз в диапазоне 5-7 минут. Опять же, это не фактическое выполнение запроса, это всего лишь процесс отображения оценочного плана выполнения .

sp_WhoIsActiveпокажет либо PAGEIOLATCH_SHждет, либо LATCH_EX [ACCESS_METHODS_DATASET_PARENT]ждет, и когда я запустил сценарий Пола Рэндала WaitingTasks.sql во время операции, он показывает CXPACKETожидания с рабочими потоками, показывающими PAGEIOLATCH_SHожидания:

* поле описания ресурса = exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

Рабочие потоки, по-видимому, переносят всю statsтаблицу в память (как эти номера страниц, так и последующие номера страниц, показанные из запроса Пола Рэндала, возвращаются к кластерному ключу для statsтаблицы). Как только план возвращается, он в основном мгновенный на оставшуюся часть дня, даже после того, как я вижу большую часть statsистощения таблицы из кэша с оставшимися только различными записями (которые, я полагаю, были извлечены из-за операций поиска из похожих запросов).

Я ожидал бы такого начального поведения, если запрос фактически выполнялся с планом, в котором использовались операторы SCAN, но почему он делает это при оценке планов выполнения только для получения оператора SEEK, как показано в плане, связанном выше? Что я могу сделать (кроме выполнения этого оператора до рабочего дня, чтобы мои данные должным образом кэшировались), чтобы улучшить производительность здесь? Я предполагаю, что пара покрывающих индексов будет полезна, но действительно ли они гарантируют какие-либо изменения в поведении? Я должен работать в рамках некоторых ограничений окна хранения и обслуживания, и сам запрос генерируется из решения поставщика, поэтому любые другие предложения (помимо лучшей индексации) будут приветствоваться на этом этапе.

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

Таким образом, SQL Server использует статистику для создания плана, достиг порога изменения и выполняет автоматическое обновление статистики как часть операции.

В XML для оценочного плана, которым вы поделились, я вижу эти близкие даты обновления статистики с этого утра:

LastUpdate="2019-05-06T09:12:49.92"
LastUpdate="2019-05-06T09:12:58.3"
LastUpdate="2019-05-06T09:13:20.33"
LastUpdate="2019-05-06T09:13:09.67"
LastUpdate="2019-05-06T09:12:59.05"
LastUpdate="2019-05-06T09:12:39.56"

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

Когда я вижу длительное плановое время в SSMS, это одно из следующего в порядке вероятности:

1. Оптимизатор запросов решил, что ему нужно создать или обновить статистику.
2. Размер предполагаемого плана очень велик (скажем,> 10 МБ), и для его отображения SSMS требуется много времени.
3. Сама компиляция запроса на самом деле заняла много времени из-за использования процессора в поисках достаточно хорошего плана.
4. Сервер находится под чрезвычайным давлением. Например, мне, возможно, придется подождать, пока шлюз станет доступным.
5. Различные ошибки, которые приводят к очень длительному времени компиляции.

В вашей ситуации ответ почти наверняка таков: SQL Server обновляет или создает статистику. Есть несколько подсказок: размер плана запроса небольшой, план запроса относительно простой с низкой стоимостью, а ЦП компиляции значительно меньше времени компиляции:

Новый участник Джош Дарнелл также указал на хорошую подсказку с последним обновленным временем для статистики в XML.

SQL Server 2019 представляет новый тип ожидания, WAIT_ON_SYNC_STATISTICS_REFRESH , когда запросы ожидают обновления статистики. Диагностировать эту проблему по этой версии намного проще. До тех пор вы просто должны полагаться на косвенные методы.

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