База данных 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
фактический план выполнения (как можно скорее)
Я не смог заметить разницу.
План для того же запроса, когда это быстро.
Фактический план выполнения