高いSQL待機、特にLCK_M_Uの調査
最近、私はSQLサーバーのパフォーマンスに苦労しており、構成内の非常に多数の基本的なエラーを修正しましたが、それでもパフォーマンスが低下しています。明確にするためには、全体的なパフォーマンスではなく、かなり頻繁なタイムアウト（クライアントアプリケーションからの）です。 以前は原因としてメモリを見ていました しかし、これは現在解決されており、同じ動作を続けています。
Management Data Warehouseのグラフを見ると、LCK_M_U/X/IXが、ユーザーがタイムアウトを経験する頃に待機の大部分を引き起こしていることがわかります。私が読んでいるものはすべて、実行中のクエリとプロセスを調べる必要があると述べていますが、理解できるレベルを目指したものはまだ見つけていません。下の図でわかるように、ロックはユーザー側のエラーと同時に発生するスパイクのようです。ロックを作成しているどのクエリが実行されているのかを試し、解決するために取り組むことができる巧妙なDMVなどはありますか？詳細を見つけるためにトレースをトロールする場合ですか？ガイダンスは非常に高く評価され、情報が明確でない場合はお詫びします。
テーブル内のsp_WhoIsActiveからのデータの収集 は、ブロッキングとロックの問題を追跡するための優れた手法です。
関連するロックの詳細を確認したい場合は、 @ get_locks パラメータを使用できます。あるいは、 @ get_task_infoおよび@get_additional_info は通常、原因を特定するのに十分な量をキャプチャします。
収集された出力が問題を理解するのに十分明確でない場合は、質問に追加してください。
ロックはチェーンを形成する傾向があり、常にチェーンの先頭にあるプロセスが何をしているかに常に関心があります。多くのプロセスは長時間待機する可能性があるため（つまり、待機時間の統計情報が増える）、ロック待機時間を単に見ているだけでは誤解を招く可能性がありますが、すべてが単一の低速なプロセスによってブロックされます。表示される可能性が高いのは合体点です。許可されたロックは、現在のすべての権限受領者およびすべての保留中の待機者と互換性がなければならないため、高レベルのロック（X、またはSCH_M）は、リソースallの待機キューに入れられ、後続の要求がこのキューの後ろにキューイングされます。
例として、テーブルでレポートを実行するクエリがあるとします。たとえば、5分かかるとします。 ISテーブルのロック。これはIS互換性があり、すべての通常の操作（読み取りおよび書き込み）SCH_Mを必要とする要求が届きます。ISと互換性がないため、キューに入れられます。今、突然テーブル上の他のすべてのアクティビティはキューに入れられます。これは、すべての要求、読み取り、またはwiteがこのウェイターと互換性がないためです。したがって、突然 allロック時間が急増します。5分後に遅いクエリが終了し（DB専門用語では「低下」）、SCH_Mが許可され、5ミリ秒でそのジョブを実行し、他のすべてのユーザーは自由にこれは単なる（極端な）例であり、必ずしもSCH_Mである必要はありません。待機時間だけではすべてのことを説明できるわけではありません。
幸い、SQL Server自体は、ほとんど知られていない blocked process threshold 。 ブロックされたプロセスレポート と DDLイベント通知 を組み合わせると、完全に自動化されたソリューションが得られます。
例については、 MS SQL Serverサードパーティトランザクションブロッキングモニターツール で私の回答を参照してください。
別の観察：IXでは22.30％の待機時間があります。これは、オブジェクトレベルのロックが発生したことを意味します。 インテントロック （IS、IX）は互換性があるため、IXがブロックされたという事実は、誰かが互換性のないオブジェクトレベルのロックを取得したことを示唆しています。 Sを取得するスキャン、またはXへの大きな更新 エスカレーティング 。
ブロッキングの原因を追跡したい場合、WMIイベント通知 BLOCKED_PROCESS_REPORT を使用すると、クエリの実行から使用されたロックまでのすべての詳細が提供されます。
自動化する方法はここにあります http://social.msdn.Microsoft.com/Forums/en-US/sqldatabaseengine/thread/402c5be7-bbbb-429e-8f71-bb1d03267ef6/