该相信哪个？

Question

我们正在与供应商解决一个长期存在的问题。他们的软件有一种倾向，每周一到两次停止工作并停止工作，从而对我们的运营造成重大干扰。尽管我们向他们发送了许多 GB 的日志和数据库备份，但他们仍无法确定原因。最近，他们开始暗示问题出在我们的维护上，而不是出在他们的软件上（尽管没有长时间运行的查询、CPU/RAM/IO 压力，甚至在问题发生时出现死锁）。特别是他们说我们的索引是一个问题。

他们最喜欢使用的工具是 DBCC showcontig，尽管我认为 MS 不赞成使用该工具。他们尤其关注扫描密度和范围碎片。为了消除这个借口，我制定了一些积极的夜间维护，以<90% 的扫描密度或> 10% 的碎片重建索引。这在某种程度上使他们脱离了扫描密度序列，但他们仍然专注于范围碎片。即使在数小时前重建的索引上，DBCC showcontig 也会显示高度碎片化。下面是 dbcc_showcontig 和 sys.dm_db_index_physical_stats 的结果，他们指出一个表是“可能的问题”。

DBCC SHOWCONTIG

• 扫描的页面......................................: 1222108
• 扫描的范围............................................：152964
• 范围开关………………………………………………………………………………………………………………
• 平均 每个范围的页数………………………………………………………………………………………………………………………………………………
• 扫描密度 [最佳计数：实际计数]......：84.44% [152764:180905]
• 逻辑扫描分片 ..................... 3.24%
• 范围扫描碎片 ..................... 35.97%
• 平均 每页可用字节数........................: 692.5
• 平均 页面密度（完整）......................：91.44%

sys.dm_db_index_physical_stats

index_type_desc      alloc_unit_type_desc     Avg_fragmentation_in_percent  page_count

CLUSTERED INDEX       IN_ROW_DATA          3.236803129  1222070

NONCLUSTERED INDEX    IN_ROW_DATA          0.680074642  48230

NONCLUSTERED INDEX    IN_ROW_DATA          0.093237195  48264

NONCLUSTERED INDEX    IN_ROW_DATA          0.03315856   48253

NONCLUSTERED INDEX    IN_ROW_DATA          0.194653248  48291

NONCLUSTERED INDEX    IN_ROW_DATA          0.393480436  58961

NONCLUSTERED INDEX    IN_ROW_DATA          0.23622292   64346

NONCLUSTERED INDEX    IN_ROW_DATA          0.041445623  48256

NONCLUSTERED INDEX    IN_ROW_DATA          0.701172007  59044

NONCLUSTERED INDEX    IN_ROW_DATA          0.216397724  53605

我应该关心我的索引吗？上面的一个不是非典型的。首选的 MS DMV 似乎表明它很好，但供应商坚持 35.97% 的范围碎片。我怀疑这只是他们拼命想找一些东西来归咎于他们的软件问题，但如果我有实际问题，我想尝试修复它。

Answer 1

您可以检查索引是否需要重新组织或重建的一件事是使用以下查询：

declare @strBD nvarchar(50)

set @strBD = N'Tu_BD';

select table = OBJECT_NAME(object_id, database_id)
    ,index = index_id
    ,Index_Type = index_type_desc
    ,Logic_Frag = avg_fragmentation_in_percent
    ,Action = case 
        when avg_fragmentation_in_percent < 30.0
            then 'ALTER INDEX REORGANIZE'
        else 'ALTER INDEX REBUILD WITH (ONLINE = ON)'
        end
from sys.dm_db_index_physical_stats(DB_ID(@strBD), null, null, null, 'LIMITED');

@strBD用。。。来代替your database name。

根据结果​​，请按照https://msdn.microsoft.com/en-us/library/ms189858(v=sql.110).aspx中的说明进行操作。此链接适用于 2012 版 SQL Server；请选择正确的版本以正确进行。

正如有人评论的那样，最好告诉您的供应商进行审查和修复，而不仅仅是“碎片问题”。也许可以通过 SQL Profiler 捕获来识别一些查询和执行计划。