SQL ServerをクラッシュさせるSQLクエリをトレースする方法
SQL Server 2008データベースサーバーがあります（たまたまMSフェールオーバークラスタリングで実行されていますが、ここでは関係ないと思います）。
私たちのアプリケーションはDBアクセス用に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データベース））、問題のあるクエリを見つけるためにどのようにフィルターをかけますか？
ありがとう！
DBCC MEMORYSTATUSコマンドを使用してSQL Server のメモリ使用量を監視する方法の概要に従ってください。対処方法は、調査結果によって異なります。よりアクセスしやすい Microsoft SQL Serverのメモリボトルネックを特定する方法 も読むことができます。
ただし、注意すべきことは、個々のクエリのせいにしてしまうことはまずありません。メモリの問題を追跡することは、それよりも微妙です。リソースが不足し、クエリがメモリ不足エラーをスローする場合、エラーをスローするクエリはvictim犯人ではありません。
あなたがやりたいようですExtended Eventsイベントを使用した設定query_memory_grant_xxxxx。
これは、情報をログに記録し、いつでも読み取ることができるアウトサイズのSQLエンジンを格納するのに最適なオプションです（ライブデータも見ることができます）。格納された情報は、DMVsとは異なり、サーバーの再起動時に消去されません。