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'。但这不应该影响数据库中的每个表。但是，如果您通过添加一堆数据或使用填充因子来特定地对索引进行分段，并且这是唯一满足阈值并且锁定它的索引，则可能会导致此行为。

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

1 个答案: