データベースでのSQLServerのブロックは、トランザクションがリソースのロックを保持し、1つ以上の接続が同じリソースで動作するのを妨げるときに発生します。 2番目の接続は、ロックが解除されるのを待ってから続行する必要があります。これは、ACIDの分離コンポーネントを確保するために行われます。つまり、並行トランザクションは、完了するまで相互に表示されません。 SQL Serverでブロックすると、どのような環境でもパフォーマンスに大きな打撃を与える可能性があります。
データベース管理者が行うタスクの1つは、ブロックを実行しているクエリを特定し、それを修正してから、さらに一歩進んで根本的な原因を特定することです。特に事後に根本原因を調査することは、非常に困難な作業になる可能性があります。ほとんどの場合、これは、 sなどのSQLServer動的管理ビューを介してroot化する非常に時間のかかるプロセスを意味します。 ys.dm_exec_requests またはsp_who2のようなシステムプロシージャを実行する ブロックチェーンに含まれるシステムプロセスID(SPIDS)の詳細を確認します。 Spotlight Cloudを使用すると、これらのブロッキングイベントを特定するための労力を大幅に削減できます。
データベース監視を使用したSQLServerブロックの識別
|
図1:概要ダッシュボード |
概要ダッシュボードから始めて、SpotlightCloudは環境全体の明確なビューを提供します。セッション数、プロセス、メモリ使用量、ディスク消費量などのメトリックが表示され、すべてが一目でわかります。さらに重要なことに、それはブロッキング活動を明確に示しています。図1の中央では、現在2つのブロックされたプロセスがあることがはっきりとわかります。
DBAの場合、ブロッキングの問題を解決するには、詳細を調べる必要があります。 Spotlight Cloudを使用すると、図2に示すように、[概要]からドロップダウンメニューを選択するだけで、セッションの詳細をさらに詳しく調べることができます。
図2:概要からのドロップダウン |
Spotlight Cloudを使用すると、ブロックされているセッションと関連するステートメントを簡単に確認できます。図3では、SPID 59と65の両方がブロックされており(ステータスの周りにオレンジ色のハイライトで示されています)、ブロックされたカウントと一致していることがわかります。また、Spotlight Cloudは、現在のインスタンスの状態に関する概要の詳細を引き続き提供し、パフォーマンスの問題に飛び込んでいる間、重要なカウンターを監視できるようになっていることにも気付くでしょう。
Spotlight CloudSQLServerモニタリングを使用したブロッキングの問題の解決
|
図3:セッションダッシュボード |
セッション(図3を参照)ダッシュボードは、問題を解決するために必要な重要な情報を提供します。ここでは、ステートメントを実行しているユーザー、影響を受けるデータベース、セッションがいつ述べられたかなどの重要な情報を見つけることができます。与えられた詳細の深さは、ブロッキングの原因に対する迅速な回答を必要とするDBAにとってリアルタイムの節約になるため、ブロッキングを解決できます。ブロックされた遷移が2つあるだけでなく、それらが両方とも、Salesデータベースに対してネットワークサービスアカウントによって実行されている同じテーブル上のUPDATEステートメントであることがわかります。実際のステートメントは右下隅に表示されます。最後に、アクティブなSPIDとそれがブロックされているSPIDの両方を確認できます。
図3の右上隅にある青いテキストで、SpotlightCloudは調査の次に進むべき場所を示しています。各レイヤー内の製品は、さらに深く潜る方法についての明確な道筋を示しています。 [ワークロードアナライザで調査]リンクをクリックすると、SPID65のリードブロッカーであるSPID61を呼び出したものを確認できます。
|
図4:ワークロードアナライザー(これは、ブロックされたセッションを拡張する場所です) |
ワークロードアナライザーは、ブロッキングなどの特定のリソースにドライブできるドリルダウンディメンションを提供します。図4では、[ブロックされたセッション]セクションの隅にある2つのエキスパンダーの矢印をクリックすると、さらに詳しく知ることができます。
図5:ブロックされたセッションの詳細 |
関連するデータベースがわかったので、もう少し掘り下げることができます。左側のナビゲーションで、販売データベースにドリルダウンできます。ここでは、現在のステータスを含むSPID61および64を確認できます。これらのシステムプロセスIDは両方ともブロックされており、SPID59がSPID64によってもブロックされていることに注意してください。このビューは、調査を継続する際に、ブロックの先を行くことができるようにするのに役立ちます。
図5の下半分では、ブロックされたセッションマッピングで、SPID 61(この場合はリードブロッカー)の詳細が示されていることがわかります。犯人は実際には実行中のSQLエージェントジョブの一部であり、ステートメントを実行していることがわかったユーザーに基づいて意味があります。それがネットワークサービスアカウント、NT AUTHORITY \NETWORKSERVICEであったことを思い出してください。この場合、SQLエージェントサービスはこの特定の資格情報のセットで実行されています。
次のステップは、実行中のジョブを調べて、ジョブを強制終了してブロックを停止できるかどうかを確認することです。通常、SQL Server ManagementStudioにアクセスしてSQLAgentを確認し、ジョブを確認しますが、Spotlightを使用すると簡単に作業でき、ジョブの包括的なビューも提供されます。概要からセッションに移動したときと同じように、上部にある「WorkloadAnalyzer」という単語の横にある矢印をクリックすると、これを見つけることができます。
図6:ワークロードアナライザからのドロップダウン |
将来のSQLServerブロックの防止
ブロッキングの調査には時間がかかります。特定の問題を調査しているときに、ブロッキングが自動的に解決する場合もあります。この場合、実行中のジョブが完了し、ブロックされた更新を実行できました。差し迫った問題はもはや存在しませんが、将来それを防ぐことができることを確認するために、根本的な原因を掘り下げ続ける必要があります。
実行中のジョブとしてSPID61をすでに識別しており、時間が経過したため、履歴を確認する必要があります。履歴を確認するには、表示されている日付範囲をアクティブなブロックの時間範囲に変更するだけです。図7では、右隅に日付範囲が表示され、ドロップダウンをクリックしてそれに応じて時間を調整できます。次に、検索機能を使用してSPID61を検索します。環境はそれぞれ異なるため、この情報をどのように処理するかは異なります。ジョブのタイミングを調整するかどうかにかかわらず、インデックス、コード、または構成にいくつかの変更を加えるかどうかは、完全にあなた次第です。
図7ジョブ |
図8:実行時間の長いブロック |
一部のブロックは非常に速く行き来するため、パフォーマンスに大きな影響はありません。彼らがより長く立ち往生するとき、私たちはこれについて速く知る必要があります。 Spotlight Cloudには、ブロックが消えないことをユーザーに通知する「長時間実行ロック」アラームがあります。
図9:ブロックされたオブジェクトの寸法 |
ブロッキングはいくつかの大きな問題の兆候であり、根本的な原因に到達するにはさまざまな視点が必要になることがよくあります。 Spotlight Cloudワークロードアナライザのブロックされたオブジェクトディメンションを使用すると、ユーザーは、特定のインスタンスで最もブロックされたアクティビティを生成しているオブジェクトをすばやく確認できます。
ブロッキングを特定して原因を掘り下げることは、DBAにとって最も難しい部分です。 Spotlight Cloud Professionalを使用すると、この情報にすばやく効率的にアクセスできます。時間が問題を解決すると、Spotlight Cloudを使用して調査を続け、根本的な原因を突き止め、最終的には、将来の発生を防ぐ方法について情報に基づいた決定を下すために必要な情報を得ることができます。
Spotlight Cloudの動作をご覧になりたいですか?今日から30日間の無料トライアルを開始してください。