パフォーマンスのトラブルシューティングは芸術であり科学です。芸術は経験から（そして他の人の経験から学ぶことから）生まれ、科学はどのシナリオで何をすべきかについてのよく知られたガイドラインから生まれます。
または、少なくともそれが私が考え、教えたいことです。
実際、多くのDBAや開発者は、私が「ひざまずくパフォーマンスのトラブルシューティング」と呼んでいるものを実践しています。これは通常、パフォーマンスの問題が重大な段階に達した場合に発生します。たとえば、クエリのタイムアウト、プロセスの実行速度の低下または失敗、ユーザーの不満、経営陣による回答とアクションの迅速化などです。
「ひざまずく」は、問題の表面的な分析を行い、最も一般的な症状が根本的な原因であるに違いないという結論にジャンプし、それに対処しようとすることから来ます。多くの場合、オンラインで見つかった誤ったアドバイスやまったく間違ったアドバイスを使用します。これは多くのフラストレーションと時間の浪費につながり、組織がサーバーやI / Oサブシステムをアップグレードして問題にハードウェアを投入しようとすると、問題がまだ残っていることに気付くだけで、多くの場合、お金の浪費につながります。 、またはすぐに再表示されます。
待機統計分析は、ひざまずくのが最も簡単な領域の1つです。この投稿では、一般的な待機タイプのいくつかと、人々がそれらを取り巻く間違いについて説明します。このような記事には、それぞれの場合に何をすべきかについて深く掘り下げる範囲はありませんが、正しい方向を示すのに十分な情報を提供します。
LCK_M_XX
ほとんどの人は、ロック待機が最も一般的である場合、それは問題であるある種のブロッキング問題であるに違いないと思います。多くの場合、適切な非クラスター化インデックスがないために、REPEATABLE_READまたはSERIALIZABLE分離レベルでテーブルスキャンが発生し、Sテーブルロックにエスカレートします。 （簡単なヒントとして、SERIALIZABLEを使用したことがないと思われる場合は、分散トランザクションを使用した場合に使用します。すべてが内部でSERIALIZABLEに変換されるため、予期しないブロッキングやデッドロックが発生する可能性があります。）
ただし、ブロッキングが他の原因で発生している場合がよくあります。デフォルトのREAD_COMMITTED分離レベルでは、変更をカバーするロックはトランザクションがコミットされるまで保持され、同じ行への読み取りやその他の更新をブロックします。トランザクションのコミットを妨げるものがあると、ブロッキングが表示される可能性があります。
たとえば、データベースが同期的にミラーリングされている場合、ログレコードがミラーに送信され、ミラーのログドライブに書き込まれるまで、トランザクションはロックをコミットおよび解放できません。ネットワークがひどく混雑している場合、またはミラーで大規模なI / O競合が発生している場合、ミラーリング操作が大幅に遅延する可能性があるため、トランザクションのコミットにはるかに長い時間がかかります。これはブロッキングのように見えますが、根本的な原因はミラーリングに関連するリソースの競合です。
ロック待機の場合、クエリプランを確認して原因が明らかでない限り、リソースをロックします（たとえば、ロックのエスカレーションを示すテーブルレベル、または分離レベル、ブロッキングチェーンに従います（sys.dm_exec_requestsのblocking_session_id列をウォークするスクリプトを使用して）。ブロッキングチェーンの先頭にあるスレッドが何を待っているかを確認してください。これは根本的な原因を示しています。
ASYNC_NETWORK_IO
これの名前は多くの混乱を引き起こします。どんな言葉に焦点を当てていますか？通信網。この待機タイプの原因は通常、ネットワークとは関係ありません。実際には、WAITING_FOR_APP_ACK（nowledgment）などと呼ばれる必要があります。これはまさに起こっていることです。SQLServerはクライアントにデータを送信し、データが消費されたことをクライアントが確認するのを待っています。
待機統計について教えるときに行う私のお気に入りのデモの1つは、Management Studioで大きな結果セットを返すクエリを実行し、サーバーがASYNC_NETWORK_IOの待機をラックアップするのを監視することです。明らかにネットワークは関係していません。SQLServerへの応答に長い時間がかかるのはSSMSだけです。これは、RBAR（Row-By-Agonizing-Row）と呼ばれる処理を実行します。この場合、すべての結果をキャッシュしてすぐにSQL Serverに応答し、処理に進むのではなく、一度に1行だけが結果から取得されて処理されます。キャッシュされた行。
これがASYNC_NETWORK_IOの待機の主な原因であり、アプリケーションの設計が不十分です。次に、アプリケーションコード自体が適切に設計されている場合でも、アプリケーションコードを実行しているサーバーにパフォーマンスの問題があるかどうかを確認します。時々それはネットワークですが、それは私の経験ではまれです。
OLEDB
ここでの一般的なひざまずく反応は、この待機タイプをリンクサーバーと同一視することです。ただし、2005には多数の新しいDMVが含まれており、DMVは主に内部でOLE DBを使用しているため、この待機時間はSQLServer2005の出荷時期を確認するためにより一般的になりました。リンクサーバーの問題を探す前に、監視ツールがサーバー上でDMVを常に実行しているかどうかを確認します。
リンクサーバーがある場合は、リンクサーバーに移動し、そこで待機統計を調べて最も一般的な問題を確認し、同じ分析を続行して、トラブルシューティングを続行します。
OLEDB待機を引き起こす可能性のあるもう1つのものは、DBCC CHECKDB（および関連するコマンド）です。 OLE DB行セットを使用して、クエリプロセッサとストレージエンジンサブシステム間で情報を通信します。
その他の待機
ひざまずく反応を引き起こす他の待機には、CXPACKET、PAGEIOLATCH_XX、SOS_SCHEDULER_YIELD、およびWRITELOGがあります。これらについては、来月の投稿で取り上げます。
概要
パフォーマンスに問題がある場合は、時間をかけて見ているデータを理解し、さらに調査を行って、問題の根本原因を絞り込むのに役立ててください。トップウェイト統計と思われるものを把握し、オンラインで出くわした最初のアドバイスに従うだけではいけません（有名で評判の良い情報源からのものでない限り）。そうしないと、問題が解決しない可能性があります。悪化させます。
一般的な待機統計に関する限り、パフォーマンスのトラブルシューティングにそれらを使用する方法の詳細については、次のURLを参照してください。
- 待機統計から始まる私のブログ投稿シリーズ、またはどこが痛いのか教えてください
- 待機タイプとラッチクラスのライブラリはこちら
- 私のPluralsightオンライントレーニングコースSQLServer：待機統計を使用したパフォーマンスのトラブルシューティング
- SQL Sentry Performance Advisor
これは、SQL Serverに関するひざまずく（再）アクションと、それらが間違っている理由について説明する、今年の間に行う一連の投稿の最初の投稿でした。次回まで、トラブルシューティングをお楽しみください！