Запросы и обновления очень медленно после IndexOptimize

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

Недавно мы попытались переключиться с заданий по техническому обслуживанию на восстановление индекса по умолчанию на Ola Hallengren IndexOptimize. Задания по перестройке индекса по умолчанию выполнялись в течение нескольких месяцев без каких-либо проблем, а запросы и обновления работали с приемлемым временем выполнения. После запуска 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которое могло бы вызвать это экстремальное снижение производительности, чтобы гарантировать, что мы избежим его, как только перейдем к производству. Будем весьма благодарны за любые предложения о том, что искать.

План выполнения оператора update, когда он медленный. т.е.
после IndexOptimize
фактический план выполнения (как можно скорее)

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

Я подозреваю, что у вас есть другая частота выборки, определенная между вашими двумя подходами обслуживания. Я полагаю, что скрипты Олы используют выборку по умолчанию, если вы не укажете @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.

Заявление об обновлении, которое заняло 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 (top) сначала вставляется в хеш-таблицу. После этого в этой хэш-таблице проверяются нулевые значения, которые возвращают нулевые значения.

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

Хотя два очень простых момента:

1. Оптимизированный прогон определенно завершен? Если ваши тесты конкурируют с IO длительных перестроений индекса, это повлияет на время.
2. Вы тестировали несколько раз? Если обновление основано на данных из запроса, который рассматривает много данных (а не просто `UPDATE TheTable SET ThisColumn = 'A Static Value'), то, возможно, эти данные обычно находятся в памяти, но были сброшены в который при первом запуске связанных запросов будет медленнее, чем обычно, из-за попадания на диск, а не из-за того, что нужные страницы уже находятся в пуле буферов в памяти.