Запити та оновлення надзвичайно повільно після IndexOptimize

База даних SQL Server 2017 Enterprise CU16 14.0.3076.1

Нещодавно ми намагалися переключитися з технічного обслуговування Index Rebuild за замовчуванням на Ola Hallengren IndexOptimize. Завдання Index Rebuild за замовчуванням працювали протягом декількох місяців без жодних проблем, а запити та оновлення працювали з прийнятними термінами виконання. Після запуску IndexOptimizeв базі даних:

EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y'

продуктивність була надзвичайно погіршена. Оновлення заяви, яка займала 100 мс раніше, IndexOptimizeзаймала 78 000 мс після цього (використовуючи ідентичний план), а запити також були гіршими на кілька порядків.

Оскільки це все ще є тестовою базою даних (ми мігруємо виробничу систему з Oracle), ми повернулися до резервної копії та відключили, IndexOptimizeі все повернулося до нормального.

Однак ми хотіли б зрозуміти, що IndexOptimizeвідрізняється від "нормального", Index Rebuildщо могло спричинити це надзвичайне погіршення продуктивності, щоб переконатися, що ми цього уникнемо, як тільки перейдемо до виробництва. Будемо дуже вдячні за будь-які пропозиції щодо того, на що звернути увагу.

План виконання для оператора оновлення, коли він повільний. тобто
після IndexOptimize Фактичного плану виконання ( скоро
)

Я не зміг помітити різницю.
Плануйте той самий запит, коли це швидкий
Фактичний план виконання

Я підозрюю, що у вас є різні показники вибірки між вашими двома підходами до обслуговування. Я вважаю, що сценарії Ola використовують вибірки за замовчуванням, якщо ви не вказали @StatisticsSampleпараметр , який не виглядає так, як ви зараз робите.

На даний момент це міркування, але ви можете перевірити, який показник вибірки зараз використовується у вашій статистиці, виконавши наступний запит у вашій базі даних:

SELECT  OBJECT_SCHEMA_NAME(st.object_id) + '.' + OBJECT_NAME(st.object_id) AS TableName
    ,   col.name AS ColumnName
    ,   st.name AS StatsName
    ,   sp.last_updated
    ,   sp.rows_sampled
    ,   sp.rows
    ,   (1.0*sp.rows_sampled)/(1.0*sp.rows) AS sample_pct
FROM sys.stats st 
    INNER JOIN sys.stats_columns st_col
        ON st.object_id = st_col.object_id
        AND st.stats_id = st_col.stats_id
    INNER JOIN sys.columns col
        ON st_col.object_id = col.object_id
        AND st_col.column_id = col.column_id
    CROSS APPLY sys.dm_db_stats_properties (st.object_id, st.stats_id) sp
ORDER BY 1, 2

Якщо ви бачите, що це відбувається через 1 (наприклад, 100%) шанси, це ваша проблема. Можливо, спробуйте сценарії Ola ще раз, включаючи @StatisticsSampleпараметр із відсотком повернення цього запиту, і подивіться, чи це вирішує вашу проблему?

Як додаткове підтвердження цієї теорії, план виконання XML показує значно різні показники вибірки для повільного запиту (2.18233%):

<StatisticsInfo LastUpdate="2019-09-01T01:07:46.04" ModificationCount="0" 
    SamplingPercent="2.18233" Statistics="[INDX_UPP_4]" Table="[UPPDRAG]" 
    Schema="[SVALA]" Database="[ulek-sva]" />

Від швидкого запиту (100%):

<StatisticsInfo LastUpdate="2019-08-25T23:01:05.52" ModificationCount="555" 
    SamplingPercent="100" Statistics="[INDX_UPP_4]" Table="[UPPDRAG]" 
    Schema="[SVALA]" Database="[ulek-sva]" />

Відповідь Джона - це правильне рішення, це лише доповнення до того, які частини плану виконання покарань змінилися, і, наприклад, як легко визначити відмінності з програмами Sentry One Plan Explorer

Оновлення заяви, яка займала 100 мс, перш ніж IndexOptimize зайняла 78 000 мс після цього (використовуючи ідентичний план)

Переглядаючи всі плани запитів, коли ваша ефективність знизилася, ви можете легко помітити відмінності.

Погіршення продуктивності

Два рахунки, що перевищують 35 секунд процесорного часу та минувший час

Очікуване виконання

Набагато краще

Основна деградація в цьому запиті оновлення двічі:

UPDATE SVALA.INGÅENDEANALYS
                           SET 
                              UPPDRAGAVSLUTAT = @NEW$AVSLUTAT
                        WHERE INGÅENDEANALYS.ID IN 
                           (
                              SELECT IA.ID
                              FROM 
                                 SVALA.INGÅENDEANALYS  AS IA 
                                    JOIN SVALA.INGÅENDEANALYSX  AS IAX 
                                    ON IAX.INGÅENDEANALYS = IA.ID 
                                    JOIN SVALA.ANALYSMATERIAL  AS AM 
                                    ON AM.ID = IA.ANALYSMATERIALID 
                                    JOIN SVALA.ANALYSMATERIALX  AS AMX 
                                    ON AMX.ANALYSMATERIAL = AM.ID 
                                    JOIN SVALA.INSÄNTMATERIAL  AS IM 
                                    ON IM.ID = AM.INSÄNTMATERIALID 
                                    JOIN SVALA.INSÄNTMATERIALX  AS IMX 
                                    ON IMX.INSÄNTMATERIAL = IM.ID
                              WHERE IM.UPPDRAGSID = SVALA.PKGSVALA$STRIPVERSION(@NEW$ID)
                      )

план виконання цього запиту з погіршенням продуктивності

Орієнтовний план запитів цього запиту оновлення має дуже високі оцінки, коли продуктивність знизилася:

Хоча насправді (фактичний план виконання) він все ще повинен працювати, тільки не шалений розмір, який показують оцінки.

Найбільший вплив на продуктивність мають два приєднані нижче сканування та хеш-матчі:

Фактичне сканування при зниженій продуктивності №1

Фактичне сканування при зниженій продуктивності №2

План виконання цього запиту з очікуваною ефективністю

Якщо ви порівнюєте це з оцінками (або фактичними значеннями) плану запитів із нормальною очікуваною ефективністю, відмінності легко помітити.

Крім того, до попередніх двох таблиць доступу навіть не відбулося:

Ви не бачите цього усунення на хеш-з'єднанні, оскільки вхід build (верхній) вводиться спочатку в хеш-таблицю. Потім нульові значення перевіряються в цій хеш-таблиці, повертаючи нульові значення.

Без додаткової інформації ми можемо робити лише слабоінформовані удари в темряві, тому вам слід відредагувати питання, щоб надати ще трохи. Наприклад, плани запитів для цього оператора оновлення, якому ви задали терміни, як до, так і після операцій технічного обслуговування індексу, оскільки плани можуть відрізнятися через оновлення статистики індексу ( https://www.brentozar.com/pastetheplan / корисно для цього, а не заповнювати питання тим, що може бути величезним фрагментом XML або наданням екрана, який не містить деякої відповідної інформації, яку містить текст плану).

Хоча дві дуже прості точки від кажана:

1. Чи точно завершено запуск оптимізації? Якщо ваші тести змагаються з IO тривалих відновлених індексів, це вплине на терміни.
2. Ви тестували кілька разів? Якщо оновлення базується на даних запиту, що враховує багато даних (а не простого "UPDATE TheTable SET thisColumn =" Статичне значення "), можливо, ці дані зазвичай є в пам'яті, але їх вимивають у які перші запуски відповідних запитів будуть повільнішими, ніж зазвичай, через потрапляння диска, а не на пошук потрібних сторінок, які вже знаходяться в буферному пулі в пам'яті.