SQL Serverで1秒あたりのキールックアップを測定する方法
私はSQL Serverでキールックアップを行うトランザクションの量を減らすことに取り組んでいます。
最初に、そのメトリックの通常の数または許容できる数のベースラインを定義する必要があります。本番環境では常にリリースがあるため、それに基づいて、南に行くと通知する自動化を作成します。
私が抱えている問題は、実際には perfmon またはデータを取得するSQL DMVのいずれかで適切なカウンターを見つけることです。
私は明白なオブジェクトを調べました SQL Server、Access Methods Object まだ、特定のオブジェクトを見つけることができませんでした。他のカウンターやSQLビューも試しましたが見つかりませんでした。
どんな提案も大歓迎です！
これを追跡する完全に正確で信頼できる方法を知りません。
少なくとも何かを潜在的に役立つ方法の1つは、 sys.dm_db_index_usage_stats のスナップショットを保持することです。具体的には、user_lookups index_id 0（RID Lookup）および1（Key Lookup）の列。このDMVは、データベースやインスタンスの再起動など、さまざまな理由でリセットできます。 SQL Server 2012以降では、再構築（再編成ではなく）とインデックスによって関連するDMVエントリがクリアされるため、状況がさらに困難になる可能性があります。情報をかなり定期的にキャプチャし、ヒューリスティックを使用してDMVがキャプチャ間でリセットされるかどうかを判断する必要があります。
インデックス使用統計DMVは、Lookupを含むプランが実行された回数のカウントも返します。単一のキールックアップを含むプランでは、実際に実行されるルックアップの数に関係なく、カウンターが1ずつ増加します。また、ルックアップがまったく実行されない場合でも増加します。
sys.dm_db_index_operational_stats DMVは、実際に実行されたシングルトンルックアップの数を記録しますが、インデックスでのシングルトンシークと、キーまたはRIDルックアップの結果であるシングルトンシークを区別しません。そのため、あなたの目的。
シングルトンシークは、アクセスメソッドオブジェクトによって報告されるプローブスキャンの別名です。一意のインデックスに対する「通常の」シングルトンシークと、ルックアップの結果として生じるシングルトンシークを区別する方法はありません。これは、Access Methods Probe Scansカウンターが役に立たないことを意味します。 AMカウンターはとにかく非常に騒々しいですし、カウンターを特定のインデックスと関連付ける方法はありません。
良い Michael J. Swartによる記述 は、キーの検索がAccessメソッドの下のProbe Scans/secカウンターにカウントされることを示しているようです：
Key Lookup（ Showplan Operator Documentation ）
この演算子は、ブックマークルックアップ演算子とも呼ばれます。常にプローブスキャン/秒のパフォーマンスカウンターにカウントされます。興味深いのは、一度に1つのレコードを取得する場合でも、この演算子はパフォーマンスの低下の症状と見なされることが多いことです。実行回数が増える可能性があるためです。多くの実行により、クエリのパフォーマンスが低下する可能性があります。パフォーマンスカウンターに注目すると、これらの実行のそれぞれがプローブスキャンパフォーマンスカウンターにカウントされることがわかります。
パフォーマンスカウンターを使用しても、数値が表示されるだけです。キールックアップを持つ特定のクエリを見つけるには、プランキャッシュを掘り下げる必要があります。 可能です 。
注：上記のshowplan演算子へのリンクは、Michaelがリンクしたものですが、たまたま、MSDNで、最新の情報を提供する最新のドキュメントを見つけました： プラン表示の論理演算子と物理演算子のリファレンス