2
信任哪个?
我们正在解决与供应商长期存在的问题。他们的软件倾向于冻结并每周停止一次或两次工作,从而严重干扰我们的运营。尽管我们向他们发送了许多GB的日志和数据库备份,但他们无法确定原因。最近,他们开始暗示问题出在我们的维护上,而不是软件方面(尽管没有长期运行的查询,CPU / RAM / IO压力,甚至在出现问题时出现死锁)。特别是他们说我们的索引是一个问题。 尽管我认为MS不赞成使用该工具,但他们最喜欢使用的工具是DBCC showcontig。他们特别着迷于扫描密度和范围碎片。为了消除借口,我建立了一些积极的夜间维护措施,以小于90%的扫描密度或大于10%的碎片重建索引。这多少使它们脱离了扫描密度列,但是它们仍然专注于范围碎片。DBCC showcontig即使在几个小时之前重建的索引上也显示出高度碎片。下面是dbcc_showcontig和sys.dm_db_index_physical_stats的结果,它们指向的表是“可能的问题”。 DBCC SHOWCONTIG 已扫描的页面................................:1222108 扫描范围.....................:152964 范围开关.....................:180904 平均 每个范围的页数...........................:8.0 扫描密度[最佳计数:实际计数] ..: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 …