Відображення прогнозованого плану виконання створює CXPACKET, PAGELATCH_SH та LATCH_EX [ACCESS_METHODS_DATASET_PARENT] чекає

Я запускаю Microsoft SQL Server 2016 SP2-CU6 (13.0.5292.0) на VCPU VM із 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 Мб), і для його відображення просто потрібно багато часу.
3. Сама компіляція запитів фактично зайняла багато часу через використання процесора в пошуку достатньо хорошого плану.
4. Сервер перебуває під надзвичайним примусом. Наприклад, мені, можливо, доведеться почекати, коли шлюз стане доступним.
5. Різні помилки, які призводять до надзвичайно довгого часу компіляції.

У Вашій ситуації майже напевно відповідь, що SQL Server оновлює або створює статистику. Підказки є декілька: розмір плану запитів невеликий, план запитів порівняно простий з низькою вартістю, а компіляційний процесор значно нижчий, ніж час компіляції:

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

SQL Server 2019 представляє новий тип очікування, WAIT_ON_SYNC_STATISTICS_REFRESH , коли запити чекають на оновлення статистики. Набагато простіше діагностувати це питання на цій версії. До цього часу вам просто доведеться покладатися на непрямі прийоми.

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