索引未重组

Question

我正在使用Ola的索引维护解决方案。在运行job.Below是我的代码之后，很少有索引没有被重新组织。

    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',
   @LogToTable = 'Y',
   @PageCountLevel = 0

即使在运行了索引优化工作之后，也很少有27 %的指数没有得到重组。

我已经经历了常见的问题，它暗示了页面的级别，在我的例子中已经是0了。

而且，它的index_id =1而不是0。

Answer 1

我猜这些指数很小。

亚伦·伯特兰注释这里

Ola的解决方案被设置为忽略不足1000页的索引(请参见@PageCountLevel参数)。您可以覆盖它，这样它就会关心不到1000页的索引，但是为什么呢？浪费精力IMHO。我将不再担心这样的小表--让Ola的解决方案完成它的工作，当您能够实际证明它正在对特定的索引造成明显的性能问题时，就会担心它的碎片。“碎片化程度高”本身并不是一个问题。

另外，托马斯·斯特林格注释这里

如果索引非常小(我相信不到8页)，它将使用混合区段。因此，似乎仍然存在碎片，因为外壳范围将包含来自多个索引的页面。正因为如此，还有这样一个事实:在这样一个如此小的索引中，碎片通常是疏忽的，您实际上应该只使用特定的页面阈值来重建索引。重建最少1000页的零碎索引是最佳实践。

Answer 2

要获得与Ola的光盘相匹配的碎片级别，需要使用

sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, 'DETAILED') 

和index_level=0上的过滤器

我发现，在被证明导致灾难性问题之前，不应忽视无法解释的支离破碎的总体态度，这种态度很有趣。它解释了我们在应用程序团队中的一些经验。