Обслуживание индекса и статистики SQL Server - IndexOptimize ola hallengren Script - PullRequest
Новая
       52

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

0 голосов
/ 22 мая 2018

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

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

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 Ответ

0 голосов
/ 22 мая 2018

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

...