SQL Server索引和统计维护-- IndexOptimize ola hallengren脚本

Question

我正在使用Ola Hallengren的IndexOptimize脚本，并且遇到了问题。我已经使用下面的参数对其进行了设置。我在网上读到，你必须指定所有参数，以便这项工作，我已经做到了。我已将此存储过程放入数据库中，并在作业中调用它。作业成功运行，但它没有重新生成或重新组织索引。

请看我下面的代码可以提供任何帮助。

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'

Answer 1

你发出的可能是你有@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

Benjamin提出了一个很好的观点。在等待低优先级锁5分钟后，脚本将中止联机索引重建操作，因为您有@WaitAtLowPriorityAbortAfterWait = 'SELF'。不过，这应该不会影响数据库中的每个表。但是，如果您专门通过添加一堆数据或使用填充因子来分割索引，并且这是唯一满足您的阈值的索引，并且锁持有它，则可能会导致此行为。