Индекс SQL Server и обслуживание статистики - IndexOptimize ola hallengren Script

Ap9_Jacka спросил: 28 апреля 2018 в 08:28 в: sql

Я использую скрипт IndexOptimize от Ola Hallengren, и у меня проблемы. Я установил это, используя приведенные ниже параметры. Я читаю онлайн, вы должны указать все параметры, чтобы это работало, что я сделал. Я поместил этот магазин proc в базу данных и вызываю его на работу. Работа выполняется успешно, но это не перестраивает или не реорганизует индексы.

Пожалуйста, см. Мой код ниже, может ли помочь.

USE TestDBA
EXEC [OlaH].[usp_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,
@PageCountLevel  = 0,
@SortInTempdb = 'Y',
@MaxDOP = NULL,
@FillFactor = NULL,
@PadIndex = NULL,
@LOBCompaction  = 'Y',
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y',
@StatisticsSample = NULL,
@StatisticsResample = 'N',
@PartitionLevel = 'Y',
@MSShippedObjects = 'Y',
@Indexes = NULL,
@TimeLimit = 360,
@Delay = NULL,
@WaitAtLowPriorityMaxDuration = 5,
@WaitAtLowPriorityAbortAfterWait  = 'SELF',
@LockTimeout = NULL,
@LogToTable = 'N',
@Execute = 'Y'

1 ответ

scsimon ответил: 28 апреля 2018 в 05:11

Вы выдаете, скорее всего, тот факт, что у вас есть @TimeLimit = 360, который является секундами, после которых команды не выполняются. Это не долгое время для этой работы. Вероятно, это мешает скрипту завершить сбор статистики фрагментации и, таким образом, никогда не будет переходить на операции реиндекса, реорганизации и восстановления. 6 минут - довольно маленькое окно для базы данных приличного размера. Установите это на нечто более реалистичное, например 3600, которое составляет 1 час.

Кроме того, уровень фрагментации может быть вторым виновником.

@FragmentationLevel1  = 5,
@FragmentationLevel2  = 30,

означает, что если фрагментация составляет от 5% до 30%, то она будет выполнять действия в @FragmentationMedium. Если он превышает 30%, он выполнит то, что вы указали в @FragmentationHigh. Если ваши индексы не фрагментированы не менее 5%, ничего не произойдет, так как у вас есть @FragmentationLow = NULL.

Вы можете проверить это с помощью sys.dm_db_index_physical_stats

SELECT OBJECT_NAME(ips.OBJECT_ID)
 ,i.NAME
 ,ips.index_id
 ,index_type_desc
 ,avg_fragmentation_in_percent
 ,avg_page_space_used_in_percent
 ,page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ips
INNER JOIN sys.indexes i ON (ips.object_id = i.object_id)
 AND (ips.index_id = i.index_id)
ORDER BY avg_fragmentation_in_percent DESC

Бенджамин поднял хороший момент. После 5 минут ожидания блокировок с низким приоритетом сценарий прервет операцию по восстановлению онлайн-индекса, так как у вас есть @WaitAtLowPriorityAbortAfterWait = 'SELF'. Это не должно влиять на каждую таблицу в вашей базе данных. Однако, если вы специально фрагментировали индекс, добавив кучу данных или играя с коэффициентом заполнения, и это единственный индекс, который соответствует вашему порогу, и блокировка держится на нем, это может привести к такому поведению.

Ap9_Jacka ответил: 28 апреля 2018 в 02:43
сделал ваши предложения, и он все еще не работал @scsimon
scsimon ответил: 28 апреля 2018 в 02:53
как долго работа выполнялась для @ Ap9_Jacka
benjamin moskovits ответил: 28 апреля 2018 в 04:52
Бьюсь об заклад, таблица, используемая сценарием Ола Халленгрен (очень хорошо оцененный), заблокирована сценарием deamon, который только что запущен и работает, поэтому скрипт Ola заблокирован.
scsimon ответил: 28 апреля 2018 в 05:11
Хорошая точка @benjaminmoskovits - я добавил, что к ответу
scsimon ответил: 29 апреля 2018 в 10:34
@ Ap9_Jacka выполнил задание более часа, и запрос выше возвращает индексы, которые фрагментированы как минимум на 10%