SQL Server 2008 Enterprise SP4 0.0.6547.0 x64 在Windows 2012R2上运行修补当前版本。 在Cisco UCM刀片和6.0 Update 3以及补丁上运行的VM。 用于存储的Nimble CS700 SAN。
这是一个具有12个vCPU的大型OLTP服务器。正常CPU使用率徘徊在6-11％左右
在没有警告的情况下，IO失速时间将通过屋顶（2000-1000ms），大多数查询将停止返回结果。 Adam Machanic的sp_whoisactive将显示数十个活动查询。 CPU为90 +％。
SAN显示几乎为零的活动，并且同一SAN上的所有其他VM都以最佳状态运行。
我们看到大规模的阻塞，因为停滞的进程持有块，一些超时和睡眠与SPID上挂着的块。杀死有问题的SPID可以暂时缓解，但几秒钟后我们就会回到我们开始的地方。
提供缓解的唯一事情是重启服务器。
管理层正确地要求实际的根本原因。当去年夏天发生这种情况时，我们可以看到首席执行官级别，我们聘请了微软的支持，他们傻眼了，并没有提供任何实际的根本原因。
我无法升级SQL服务器。机器托管打包的应用程序，如果我们实现任何较新的SQL Server版本，软件包发布者拒绝支持他们的软件。我非常想去2014/2016/2017，并且会觉得它可以解决这个问题以及其他问题。
无论如何，我搜索了错误报告，没有看到任何匹配的内容。
有没有人遇到过这个问题？如果是这样，你是否有根本原因？我有一种直觉，认为SQL 2008，Windows 2012R2或它们如何交互存在错误。但我不想在没有一些佐证的情况下将其写入RCA。
不胜感激。
答案 0 :(得分：0)
这是我的方法
1.尝试消除存储问题。我们曾经遇到存储问题（SAN），根本原因似乎是HBA。您可以进一步检查存储是否在可接受的限制内执行
您应该从以下计数器开始，看看它们是否小于15毫秒
平均。磁盘秒/读 - 是从磁盘读取数据的平均时间（以秒为单位） 平均。磁盘秒/写 - 是将数据写入磁盘的平均时间（以秒为单位）。
2.。）一旦消除了存储问题，您可以进一步检查SQLSERVER是否是唯一导致IO峰值的问题，或者是否有任何其他应用程序导致IO。您可以使用资源监视器来查找此
3。）如果你到达这里，SQLSERVER可能是罪魁祸首。按照以下步骤进行操作并尝试按照相同的顺序查看每个步骤后问题是否仍然存在。
请记住，由于
，可能会导致HIGH IO过时的统计信息和缺失的索引：您可能没有定期更新统计信息，或者某些类型的查询可能需要更频繁的索引重建/统计信息更新
收集导致HIGH IO的查询并尝试调整它们，您可以观察完成的读取次数并尝试添加索引以最大限度地减少读取次数
进一步检查内存压力，有时高内存使用量会导致缓冲池刷新，然后查询将转到磁盘..您可以查找名为PLE的计数器，看看哪些对您有用环境
答案 1 :(得分：0)
进一步研究指向VMWare。该机器分配了304GB的RAM，其中264GB分配给了SQL Server。但是，底层主机在RAM上大量过量使用。我们怀疑随着页面生命的下降而颠簸，并且其他虚拟机也需要真正的RAM。
由于 约翰。