最近、プランキャッシュをクエリするために、DMVで本番システムに対してクエリを実行しています。特に、クエリのfrom句は次のとおりです。
FROM sys.dm_exec_cached_plans AS cp
CROSS APPLY sys.dm_exec_query_plan(plan_handle) AS qp
CROSS APPLY query_plan.nodes('/ShowPlanXML/BatchSequence/Batch/Statements/StmtSimple') AS batch(stmt)
CROSS APPLY stmt.nodes('.//IndexScan/Object[@Index=sql:variable("@IndexName")]') AS idx(obj)
Dm_exec_cached_plansには約28k行あります。
これを行うと、PLEが非常に低いディスクと非常に高いディスクをドロップするというアラートが発生しますIOおよびレイテンシー(読み取り/書き込みストール)。
DMVに対してアドホッククエリを実行する際のパフォーマンスの問題について読んだり経験したりしたことがないので、これは驚きです。このサーバーには24コア、64GB RAMおよびSSDがあります。それ以上のものがあることはわかっていますが、これらのクエリがこのような問題を引き起こすとは信じられません。
誰かがこれが起こる理由を正確に説明できますか?構成についてさらに情報を提供できてうれしいですが、簡単な説明もあることを望んでいました。
これを定量化するのに役立つ他のDMVがあります。 sys.dm_exec_sessions
列がありますcpu_time
、memory_usage
およびtotal_scheduled_time
とりわけ。 1つのセッションで計画取得クエリを実行しているときに、2番目のセッションでこのDMVに問い合わせて、最初のセッションのコストを確認できます。
喜ばしいことに、2番目のセッションの費用を同時に定量化することもできます。