信任哪个？

我们正在解决与供应商长期存在的问题。他们的软件倾向于冻结并每周停止一次或两次工作，从而严重干扰我们的运营。尽管我们向他们发送了许多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    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％的范围碎片上。我怀疑这只是他们拼命地试图寻找某种原因来怪罪于他们的软件问题，但是，如果我遇到实际问题，我想尝试并解决它。

他们的软件倾向于冻结并每周停止一次或两次工作，从而严重干扰我们的运营。尽管我们向他们发送了许多GB的日志和数据库备份，但他们无法确定原因。...特别是他们说我们的索引是一个问题。

哦，对，我想我以前听过这个笑话。难道不是这样的：

一只鸭子走进酒吧 说道：“哦！” （开个玩笑；-），酒保说：“你会吃什么？”

鸭子说：“给我三个最强伏特加酒的手指。”

调酒师几乎在开玩笑地说：“你不是说三羽'羽毛'吗？”

鸭子说：“看，对不起，您不再是《每个人都喜欢雷蒙德》的首席作家，但这是艰难的一天，所以您能成为好朋友并用伏特加酿造吗？”

酒保说：“当然，伙计。等等。”

过了一会儿，他回来了，显然比离开时还不高兴。他对鸭子说：“看起来我们都没什么好东西了。我们只剩下Skyy。行得通吗？”

鸭子在柜台上跳起来，用一只翅膀抓住酒保（用某种方式），从另一只翅膀的某个地方拉出一把刀，然后，慢慢地，轻轻地说，但很明显，“我。切。你。”

酒保惊慌地说道：“嘿，这是数据库。它很慢。它没有响应。”

鸭子对他是否应该结束酒保感到困惑-现在就在这里-愤怒地咆哮着他，“数据库？你到底在说什么？”

调酒师，现在正在抽泣，脱口而出，“我不知道...有什么阻碍吗？。这就是我们所说的...。您可以尝试重建索引吗？..您知道，什么时候我们不知道该说些什么。...也许我们应该向服务器添加更多的内存...您认为这会有所帮助吗？...每个人都知道应用程序代码快速且数据库是瓶颈。 ..嘿，我听说过这些NoSQL数据库，它们是<air-quotes> web-scale </ air-quotes>，通常是开源的，因此它们是免费的，例如Twitter和Google，以及Facebook都使用了这些东西，因为关系数据库即将淘汰。”

这样，鸭子就下定了决心...........

嗯 好吧，请相信我，这在原始的匈牙利人中很有趣。

但是，当系统变慢时，为什么这么多人的最初反应只是假设它是数据库？好像无法编写可怕的应用程序代码，或者仅仅存在一些错误？事情变慢的肯定是数据库。但是仅仅是锁定/冻结？对于特定于数据库的问题，这并不令我震惊。

它确实听起来像可能是未正确释放外部资源（网络插座，文件系统处理等）的一些应用程序代码。如果我们谈论的是.NET应用程序，则有时开发人员会忘记正确地Dispose()拥有与非托管资源相关联的对象。例如：打开一个SqlConnection对象。您不会得到无限的数量。因此，如果他们想在数据库中查找，就可以了。但是，也许下次系统冻结时，请快速查看一下：

SELECT sdec.*, '---' AS [---], sdes.*
FROM sys.dm_exec_connections sdec
INNER JOIN sys.dm_exec_sessions sdes
        ON sdes.session_id = sdec.session_id

如果他们的代码没有释放连接，那么连接太多就应该很明显，尤其是其中许多有很长的空闲时间时。

也许这些东西已经过检查，根本没有在课题中披露。但是令我感到奇怪的是，它们如此专注于索引和碎片。当然，存在参数嗅探问题，这些问题有时会导致一个或几个存储过程花费很长时间，但会锁定整个应用程序？我不购买它，特别是如果您没有看到查询正在运行并且在发生这种情况时占用了大量资源或锁或时间的情况下。

因此，“值得信赖的是哪一个？” 当然不是这个供应商;-)。

您可以查看以下内容以查看您的索引是否需要重新组织或重建：使用此查询：

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/zh-cn/library/ms189858(v=sql.110).aspx中所述进行操作。该链接适用于SQL Server 2012版本。请选择正确的版本以正确进行。

正如某人所评论的那样，除了“碎片问题”之外，最好告诉您的供应商该检查和修复。也许可以使用SQL Profiler捕获来识别一些查询和执行计划。