如何跟踪导致 SQL Server 崩溃的 SQL 查询

Question

我们有一个 SQL Server 2008 数据库服务器（它恰好在 MS 故障转移群集下运行，但我认为这与此处无关）。

我们的应用程序运行 Hibernate 以进行数据库访问，自从我们最近从 v3.1 升级到 3.6 以来，我们经常遇到 SQL Server 崩溃（每 24-48 小时，但有时更频繁）。

有问题的具体问题似乎与内存有关。就在服务器崩溃之前（然后似乎由故障转移集群管理器自动重新启动），我们收到了这些错误的负载：

Error: 701, Severity: 17, State: 130.
There is insufficient system memory in resource pool 'internal' to run this query.

也偶尔（但定期）的消息

Error: 17300, Severity: 16, State: 1. (Params:). The error is printed in terse mode because there was error during formatting. Tracing, ETW, notifications etc are skipped.

错误：17312，严重性：16，状态：1。（参数：）。错误以简洁模式打印，因为格式化过程中出现错误。跟踪、ETW、通知等被跳过。

我还收到一些应用程序级别的错误，例如

java.sql.SQLException: A time out occurred while waiting to optimize the query. Rerun the query.

然后是令人兴奋且可能具有指导意义的错误：

The query processor ran out of internal resources and could not produce a query plan. 
This is a rare event and only expected for extremely complex queries or queries that reference a very large number of tables or partitions. 
Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.

服务器上的负载没有改变，所以没有理由它现在应该耗尽内存，因为它以前没有表明发送给它的查询有问题。

现在的问题 - 我如何跟踪导致此错误（因此可能是所有问题）的查询？似乎自从我们的 Hibernate 升级以来，它一直在 SQL Server 上触发一些巨大的查询，这已经破坏了它。碰巧的是，我对它们可能是什么有一些想法，但是能够追踪它们会很好。

我当然可以运行 SQL Server 探查器，但是一旦完成（并产生大量数据 - 这是一个繁忙的 OLTP 数据库），我该如何过滤以查找有问题的查询？

谢谢！

Answer 1

按照如何使用DBCC MEMORYSTATUS命令监视 SQL Server 上的内存使用情况中概述的步骤进行操作。补救措施将取决于您的发现。您还可以阅读更易于访问的如何识别 Microsoft SQL Server 内存瓶颈。

但是，请注意一个词：您不太可能会发现个别查询是罪魁祸首。追踪内存问题比这更微妙。请记住，当您耗尽资源并且查询抛出内存不足错误时，很可能抛出错误的查询只是受害者，而不是罪魁祸首。