SQL Server アクティビティモニター：DBA向け完全ガイド [2026]

SQL Server アクティビティモニターは内蔵診断ツールですosticツール内 SQL Server 情報を表示する管理スタジオ SQL Server プロセスとそれがサーバーのパフォーマンスに与える影響を追跡できます。 SQL Server プロセスの実行、リソース待機の監視、コストのかかるクエリの分析、I/O パターンの観察をすべて単一のインターフェースから実行できます。

1.2 使用する理由 SQL Server アクティビティモニター?

アクティビティモニターは、パフォーマンスの問題をトラブルシューティングする際の第一線として機能します。コンピュータ上で何が起こっているかを即座に可視化します。 SQL Server 複雑な T-SQL クエリやサードパーティツールを必要とせずにインスタンスを作成できます。

このツールは、セッションのブロック、CPU負荷の高いクエリ、過剰なクエリ実行、I/Oボトルネックといった一般的な問題を迅速に特定するのに優れています。ユーザーからアプリケーションの速度低下や応答停止の報告があった場合、アクティビティモニターはデータベースサーバーに原因があるかどうかを判断するのに役立ちます。

データベース管理者で、 SQL Server アクティビティモニターは、日々のサーバーアクティビティを把握するための入り口として利用できます。経験豊富なDBAでさえも、これを監視ツールとして活用しています。tarパフォーマンス調査のポイント。

1.3 アクティビティモニターと他の監視ツールの比較

アクティビティモニターは便利ですが、他の監視オプションとの比較も重要です。

アクティビティモニターと sp_WhoIsActive: アクティビティモニターは複数のペインを備えたグラフィカルインターフェイスを提供しますが、sp_WhoIsActive は単一の結果セットでより詳細な情報を提供する包括的なストアドプロシージャです。sp_WhoIsActive は、アクティビティモニターがグループ化した特定の待機タイプを表示し、より詳細なブロック情報を提供します。

アクティビティモニターと sp_who2: 従来の sp_who2 コマンドは基本的なセッション情報を表示しますが、アクティビティモニターはさらに進んで、待機統計、コストの高いクエリ、I/O メトリックを整理された視覚的な形式で表示します。

アクティビティモニターとサードパーティ製ツールの比較: SolarWinds Database Performance Analyzerのような商用監視ソリューションは、アクティビティモニターにはない履歴追跡、アラート、高度な分析機能を提供します。ただし、アクティビティモニターは追加のcを必要としません。ost またはインストール。

1.4 データベース管理者にとっての主なメリット

アクティビティモニターには、必須の DBA ツールとなるいくつかの利点があります。

ゼロCost: 組み込みとして SQL Server Management Studio 機能では、ライセンス料金や展開作業は必要ありません。
リアルタイム監視: 1 秒から 1 時間までの更新間隔を設定して、現在のサーバーアクティビティをリアルタイムで確認できます。
統合アクション: プロセスを右クリックしてセッションを終了したり、クエリの詳細を表示したり、起動したりします。 SQL Server プロファイラートレースはすべてツール内から実行されます。
複数の視点: それぞれパフォーマンスの特定の側面に焦点を当てた 5 つの専用ペインを通じて、さまざまな角度からサーバーの健全性を表示します。
クイックトラブルシューティング: mを特定するost 一般的なパフォーマンスの問題を数分以内に解決し、平均解決時間を短縮します。
低い参入障壁: ツールを効果的に使い始めるのに高度な知識は必要ありませんが、より深く理解すれば SQL Server 専門知識は解釈に役立ちます。

2. Sを取得するtarアクティビティモニターで確認

アクティビティモニターを効果的に活用するには、前提条件、必要な権限、およびツールを起動するためのさまざまな方法を理解しておく必要があります。

2.1 前提条件とシステム要件

使用するには SQL Server アクティビティモニターが必要です SQL Server Management Studio (SSMS) をローカルマシンまたはジャンプサーバーにインストールします。アクティビティモニターツールは、 SQL Server 2008年なので、このガイドの情報は SQL Server 2008以降のバージョン。

ネットワーク接続が必要です SQL Server 監視したいインスタンス。cloud-hの場合osted データベースの場合、インスタンスにアクセスするには、通常、VPN 接続または適切に構成されたファイアウォールルールが必要になります。

アクティビティモニターは、すべてのエディションで動作します SQL ServerExpress、Standard、Enterprise などのプランがあります。ツール自体は SSMS 内のクライアントマシン上で実行されるため、サーバーのリソースはツールが実行する監視クエリによってのみ影響を受けます。

2.2 必要な権限

アクティビティモニターが正しく機能するには、適切な権限が不可欠です。適切な権限がない場合、画面に何も表示されないか、アクセス拒否エラーが表示される場合があります。

2.2.1 VIEW SERVER STATE権限

その サーバーの状態を表示 アクティビティモニターを使用するには、権限が必須です。このサーバーレベルの権限により、すべてのアクティブなプロセスとそれに関連するメトリクスを確認できます。

この権限を付与するには、サーバー管理者は次のコマンドを実行します。

GRANT VIEW SERVER STATE TO [YourLoginName];

VIEW SERVER STATE がないと、アクティビティモニターは開きますが、どのペインにもデータが表示されないことがあります。

2.2.2 データベースレベルの権限

データファイルI/Oペインの情報を表示するには、追加の権限が必要です。具体的には、次のいずれかの組み合わせが必要です。

データベース作成 許可、または
任意のデータベースを変更する 許可、または
任意の定義を表示 許可

これらの権限は、 サーバーの状態を表示 アクティビティモニターの全機能を利用するには。

2.2.3 権限のトラブルシューティング

アクティビティモニターが開いてもデータが表示されない場合は、権限がost よくある原因です。ログイン時にサーバーレベルでVIEW SERVER STATE権限が付与されていることを確認してください。以下のコマンドを実行することで権限を確認できます。

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

permission_name列で「VIEW SERVER STATE」を探してください。見つからない場合は、データベース管理者に連絡して権限を付与してもらってください。

2.3 SSMSでアクティビティモニターを開く方法

SQL Server Management Studio では、アクティビティモニターを起動するための 4 つの方法が提供されており、ワークフローの設定に基づいた柔軟性が得られます。

2.3.1 方法1: ツールバーから

アクティビティモニタを開く最も簡単な方法は、ツールバーアイコンを使用することです。

に接続します SQL Server のインスタンス SQL Server ManagementStudio。
標準ツールバーでアクティビティモニターアイコンを見つけます (緑色の再生ボタンが付いた棒グラフに似ています)。
アイコンをクリックしてアクティビティモニターを起動します。

すでに SSMS で作業していて、サーバーのアクティビティをすぐに確認する必要がある場合、この方法が最も高速です。

2.3.2 方法2: オブジェクトエクスプローラーから

オブジェクトエクスプローラーから直接アクティビティモニターを起動することもできます。

オブジェクトエクスプローラーで、 SQL Server 監視するインスタンス。
インスタンス名を右クリックします。
選択する 活動モニター コンテキストメニューから選択します。

この方法は、正しいインスタンスを監視していることを確認できるため、複数のサーバーに接続するときに便利です。

2.3.3 方法3: キーボードショートカットを使用する

キーボード中心のユーザーの場合、 SQL Server Management Studio には専用のショートカットが用意されています。

SSMS がアクティブウィンドウであり、インスタンスに接続されていることを確認します。
メディア掲載 Ctrlキー + 他の + A.
オブジェクトエクスプローラーで現在選択されているインスタンスのアクティビティモニターが開きます。

アクティビティモニターは、オブジェクトエクスプローラーで選択したサーバーインスタンスに接続するので、このショートカットを使用する前に正しいインスタンスを選択していることを確認してください。

2.3.4 方法4: オプションメニューから（Startup 構成)

アクティビティモニターを頻繁に使用する場合は、SSMSを設定して、アクティビティモニターをいつでも自動的に起動するようにすることができます。tarアプリケーション:

In SQL Server Management Studioに移動 ツール -> オプション.
オプションダイアログボックスで展開します環境、次に選択 Starタップ.
ノーザンダイバー社の sでtarタップ ドロップダウンリストで、 オブジェクトエクスプローラーとアクティビティモニターを開く.
選択する OK.

次回 SSMS を起動してサーバーに接続すると、オブジェクトエクスプローラーの横にアクティビティモニターが自動的に開きます。

3. アクティビティモニターのパネルを理解する

アクティビティモニターは、5つの展開可能なペインに情報を整理し、それぞれ異なる視点からサーバーアクティビティを表示します。各ペインに表示される内容を理解することは、効果的なトラブルシューティングを行う上で非常に重要です。

3.1 概要ペイン

概要パネルには、あなたの健康状態を素早く把握できる4つのリアルタイムグラフが表示されます。 SQL Server インスタンス。これらのグラフは設定可能な間隔で更新され、異常なパターンを一目で特定するのに役立ちます。

3.1.1 % プロセッサ時間

このグラフは、プロセッサが非アイドルスレッドの実行に費やした時間の割合を示しています。 SQL Server すべてのCPUにわたるインスタンス。値は SQL Serverサーバー全体の CPU 使用率ではなく、プロセッサ使用率です。

プロセッサ時間が常に100%またはそれに近い場合、サーバーはCPUバウンド状態です。これは、クエリの効率が悪い、インデックスが欠落している、またはハードウェア容量が不足している可能性を示しています。「最近の高負荷クエリ」ペインを使用して、どのクエリがCPUを消費しているかを特定してください。ost CPU。

3.1.2 待機中のタスク

このメトリックは、処理を続行する前にリソースの解放を待機しているタスクの数を表示します。タスクはCPU、I/O、メモリ、またはロックを待機する場合があります。

待機タスクの数が常に高い場合は、リソースの競合が発生していることを示しています。「リソース待機」ペインでは、待機の原因となっているリソースの種類について、より詳細な情報が表示されます。

3.1.3 データベースI/O（MB/秒）

このグラフは、メモリとディスク間のデータ転送速度を示しています。読み取りと書き込みの両方の速度を合計し、1秒あたりのメガバイト単位で測定されます。

データベースI/Oの急増は、大規模なテーブルスキャンを実行するクエリ、過剰なログ記録アクティビティ、またはチェックポイント操作を示している可能性があります。「データファイルI/O」ペインでは、データベースとファイルごとにI/Oアクティビティを分類できます。

3.1.4 バッチリクエスト/秒

この指標は、 SQL Server インスタンスが1秒あたりに受信するバッチの数。バッチは単一のステートメント、または複数のステートメントをまとめて送信したものになります。

この値は、サーバー全体のアクティビティを把握するのに役立ちます。通常の営業時間中にバッチリクエストが突然減少した場合は、アプリケーションの接続に問題があるか、ユーザー側に問題が発生している可能性があります。

3.1.5 更新間隔の設定

アクティビティモニターがデータを更新する頻度をカスタマイズできます。

概要ペイン内の任意の場所を右クリックします。
選択する 更新間隔.
事前定義された値（1 秒、5 秒、10 秒 (デフォルト)、30 秒、1 分、または 1 時間）から間隔を選択します。

更新間隔を10秒未満に設定すると、サーバーの監視オーバーヘッドが増加します。負荷の高い本番システムでは、影響を最小限に抑えるため、30秒以上の間隔を設定することを検討してください。

3.2 プロセスペイン

プロセスペインには、現在実行中のセッションに関する情報が表示されます。 SQL Server インスタンス。このペインは、誰が何を実行しているかを特定し、ブロックの問題を見つけるために不可欠です。

3.2.1 プロセス情報の理解

プロセスペインの各行は、サーバー上のアクティブなセッションを表します。このペインには、すべてのデータベースとすべてのユーザーのセッションが表示されるため、サーバーのアクティビティを包括的に把握できます。

表示される情報には、ログイン名、アプリケーション名、ost名前、アクセス中のデータベース、現在のコマンド。これにより、データベースのアクティビティを特定のユーザーまたはアプリケーションと関連付けることができます。

3.2.2 主要な列の説明

主要な列を理解すると、プロセス情報を効果的に解釈できるようになります。

セッションID： 各接続の一意の識別子。システムプロセスは負のセッションIDを使用します。
ユーザープロセス: これがユーザーセッション (はい) かシステムプロセス (いいえ) かを示します。
ログイン： その SQL Server セッションに関連付けられたログインまたは Windows アカウント。
データベース： セッションの現在のデータベースコンテキスト。
タスクの状態: セッションが現在何を実行しているかを表示します (RUNNING、SUSPENDED、SLEEPING など)。
コマンド： 実行されるコマンドの種類 (SELECT、INSERT、UPDATE など)。
応用： 接続を作成したアプリケーションの名前。
待ち時間： セッションがリソースを待機している時間 (ミリ秒単位)。
待機タイプ: セッションが待機しているリソースの特定のタイプ。
CPU時間: 接続してからこのセッションで消費された CPU 時間の合計。
メモリ使用量: 現在セッションに割り当てられているメモリの量 (KB 単位)。

3.2.3 フィルタリングとソートのプロセス

プロセスウィンドウには、関連するセッションに焦点を絞るのに役立つ強力なフィルタリング機能が含まれています。

任意の列ヘッダーのドロップダウン矢印をクリックします。
フィルタには、その列で使用可能な値が表示されます。 事例一覧, ブランク, 非空白.
特定の値を選択して、表示をそれらのセッションのみにフィルタリングします。

例えば、フィルタリングすることができます タスクの状態 実行中のセッションのみを表示するか、フィルタリングする データベース 特定のデータベースに対するアクティビティを確認します。

列のヘッダーをクリックすることで、任意の列で並べ替えることもできます。1回クリックすると昇順、2回クリックすると降順になります。

3.2.4 ブロックされているセッションとブロックされたセッションの識別

プロセスウィンドウは、1 つのセッションが他のセッションの進行を妨げるブロックシナリオを識別するのに役立ちます。

ブロックした人: このセッションをブロックしているセッションのセッションIDを表示します。この列に値が含まれている場合、セッションは別のセッションによって保持されているロックを待機しています。
ヘッドブロッカー: このセッションが他のセッションをブロックしているものの、それ自体はブロックされていない場合は「1」が表示されます。これがブロッキングチェーンの根本原因です。

ブロッキングの問題を調査するには、まずヘッドブロッカー (ヘッドブロッカー列に「1」とマークされているセッション) を特定し、それが何を実行しているかを調べて、完了させるか終了するかを決定します。

3.2.5 プロセスアクション（強制終了、詳細、トレース）

アクティビティモニターを使用すると、個々のセッションに対してアクションを実行できます。

[プロセス] ペイン内の任意のセッションを右クリックします。
いくつかのオプションが表示されます:
- 詳細： このセッションで最後に実行されたコマンドを表示します。
- プロセスを強制終了: セッションを終了します (注意して使用してください)。
- トレースプロセス SQL Server プロファイラー: 進水 SQL Server プロファイラーこのセッションからのアクティビティのみを表示するように自動的にフィルタリングします。

詳細オプションではコマンドテキストが表示されますが、これは last コマンドは実行されたばかりで、まだ実行されていない可能性があります。トレースオプションは、セッションで実行されているコマンドの完全なシーケンスを確認する必要がある場合に特に便利です。

3.3 リソース待機ペイン

リソース待機ペインには、待機統計の概要が表示され、どの種類のリソースセッションが待機しているかが表示されます。ost 頻繁に実行してください。この情報はパフォーマンスのボトルネックを診断する上で非常に重要です。

3.3.1 待機統計の理解

日時 SQL Server リソース要求（ロック、CPU時間、メモリなど）をすぐに許可できない場合、要求元のタスクは待機状態になります。待機統計はこれらの待機期間を追跡し、サーバーがどこで作業ではなく待機時間を費やしているかを把握するのに役立ちます。

「リソース待機」ペインは、sys.dm_os_wait_stats や sys.dm_exec_requests などのシステム動的管理ビューからデータを収集します。更新間隔ごとに、現在のスナップショットと前回のスナップショットの差分を計算し、各待機タイプの累積率を表示します。

3.3.2 待機カテゴリ

アクティビティモニターは、解釈を簡素化するために、数百の個別の待機タイプをより広いカテゴリにグループ化します。

CPU： CPU 時間が利用可能になるのを待機しているタスク。
バッファラッチ: メモリ内のデータページへのアクセスを保護するための短期同期オブジェクトの待機。このカテゴリには、ページラッチ待機（PAGELATCH_*）が含まれます。
ロック： 他のセッションが必要とするロックを保持しているセッションによって発生する待機。
メモリ： ソートやハッシュなどの操作に必要なメモリの許可を待機します。
ネットワークI/O: クライアントへのデータの送信またはクライアントからのデータの受信を待機します。
SQL CL: 共通言語ランタイムの実行に関連する待機。

このグループ化はビューを簡素化しますが、重要な詳細が見えにくくなります。例えば、「バッファラッチ」は、パフォーマンスにそれぞれ異なる影響を与えるPAGELATCH_SH、PAGELATCH_UP、PAGELATCH_EXの待機をまとめてグループ化してしまう可能性があります。

3.3.3 待機時間と待機タスクの解釈

リソース待機ペインには、待機カテゴリごとに 2 つの主要なメトリックが表示されます。

累積待ち時間（ミリ秒）: この待機カテゴリの現在の更新間隔中に累積された合計ミリ秒数。
待機中のタスク: 現在このカテゴリのリソースを待機しているタスクの数。

待機時間の値は特に重要です。更新間隔が10秒で、あるカテゴリの待機時間が20,000ミリ秒の場合、複数の同時待機が発生していることを示しています（20,000ミリ秒 / 10,000ミリ秒 = 間隔中の2つの同時待機の平均）。

3.3.4 パフォーマンスのボトルネックの特定

リソース待機ペインを使用して、サーバーがどこでリソースを消費しているかを特定します。ost 待ち時間:

リソース待機ペインを展開します。
最も長い待機時間が蓄積されている待機カテゴリを観察します。
並べ替え 累積待ち時間 どのリソースがmであるかを確認するost 拘束された。

バッファラッチ待機時間の増加は、メモリ内のデータページの競合を示していることが多く、I/Oボトルネックやtempdbの競合が発生している可能性があります。ロック待機時間の増加は、ブロッキングの問題を示しています。メモリ待機時間の増加は、クエリ操作に必要なメモリ割り当てが不足していることを示唆しています。

3.4 データファイルI/Oペイン

データファイル I/O ペインには、サーバー上の各データベースファイルのディスクアクティビティが表示されるため、I/O ボトルネックを特定し、ディスク使用率のパターンを把握するのに役立ちます。

3.4.1 I/Oメトリックの理解

データファイル I/O ペインには、各データベースファイルのいくつかのメトリックが表示されます。

データベース： データベースの名前。
ファイルの種類： データ (テーブルとインデックスを含む) またはログ (トランザクションログ) のいずれか。
論理名: 定義される論理ファイル名 SQL Server.
MB/秒読み取り: このファイルから読み取られるデータの速度。
MB/秒書き込み: このファイルに書き込まれるデータの速度。
応答時間（ミリ秒）： このファイルでの I/O 操作の平均応答時間。

これらのメトリックは概要ペインと同じ間隔で更新され、ディスクアクティビティをリアルタイムで確認できます。

3.4.2 I/Oボトルネックの特定

I/O パフォーマンスの問題を示す次のパターンに注意してください。

高速応答時間: 応答時間が一貫して15～20ミリ秒を超える場合は、ディスクサブシステムの速度が遅い可能性があります。応答時間が50ミリ秒を超える場合は、深刻なI/Oボトルネックが発生している可能性があります。
不均衡な負荷： あるデータファイルの I/O レートが同じデータベース内の他のファイルよりも大幅に高い場合、負荷を分散するためにファイルを追加すると効果的です。
過剰な Tempdb アクティビティ: tempdb ファイルの I/O レートが高い場合、多くの場合、クエリによって大きな中間結果セットが作成されているか、非効率的な実行プランが使用されていることを示します。

3.4.3 データベースファイル分析

データベースがディスクリソースをどのように使用しているかを理解するには、[データファイル I/O] ペインを使用します。

データファイル I/O ペインを展開します。
並べ替え MB/秒の読み取り or MB/秒書き込み mを識別するost アクティブなファイル。
アクティビティが一貫して高いファイルや応答時間が長いファイルをメモします。
この情報を [最近の高コストのクエリ] ペインと相互参照して、どのクエリが I/O 負荷を引き起こしているかを特定します。

3.5 最近の高コストクエリペイン

最近の高コストクエリペインは、多くの場合、ost アプリケーションのパフォーマンス問題のトラブルシューティングに役立つ貴重なパネルです。サーバーリソースを大量に消費しているクエリが表示されるため、最適化の機会を特定するのに役立ちます。

3.5.1 クエリメトリクスの理解

アクティビティモニターには、コストのかかるクエリごとにいくつかのメトリックが表示されます。

実行回数/分: 過去 1 分間にクエリが実行された回数。
CPU（ミリ秒/秒）: このクエリによって 1 秒あたりに消費された CPU 時間。
物理読み取り/秒: このクエリの 1 秒あたりの物理ディスク読み取り数。
論理書き込み/秒: 1 秒あたりの論理書き込み (バッファキャッシュへの) 数。
論理読み取り/秒: 1 秒あたりの論理読み取り回数 (バッファキャッシュから)。
平均継続時間（ミリ秒）: このクエリの平均実行時間。
プラン数: このクエリのキャッシュ内の実行プランの数。

これらの指標は、どのクエリが高価かだけでなく、 現在も将来も、 それらは高価であり、どのくらいの頻度で実行されるかです。

3.5.2 並べ替えオプション

さまざまなタイプの問題を見つけることができます。

任意の列ヘッダーをクリックすると、そのメトリックで並べ替えることができます。
一般的なソート戦略は次のとおりです。
- CPUで並べ替え: mを消費するクエリを見つけるost プロセッサ時間。
- 実行回数/分で並べ替え: 過度に頻繁に実行されるクエリを識別します。
- 物理読み取りによる並べ替え: mの原因となるクエリを見つけるost ディスク I/O。
- 平均所要時間で並べ替え: 長時間実行されるクエリを見つけます。

パフォーマンスの問題をトラブルシューティングする際は、複数の列で並べ替えて、異なる視点から物事を捉えてみましょう。CPU使用率は中程度なのに、1分あたりの実行回数が非常に多いクエリこそが、真の問題である可能性があります。

3.5.3 クエリテキストの表示

高価なクエリの背後にある実際の SQL ステートメントを確認するには:

[最近の高コストのクエリ] ペインでクエリ行を右クリックします。
選択する クエリテキストの編集.
新しいクエリウィンドウが開き、完全な SQL ステートメントが表示されます。

これにより、クエリロジックを検証し、潜在的な最適化の可能性を特定できます。その後、クエリテキストをコピーして、修正したバージョンをテストできます。

3.5.4 実行計画の分析

実行計画は方法を示します SQL Server クエリを実行すると、インデックスの欠落や不適切な結合タイプなどの非効率性が明らかになります。

[最近の高コストのクエリ] ペインでクエリ行を右クリックします。
選択する 実行プランを表示.
SQL Server Management Studio では、クエリの実行方法がグラフィカルに表示されます。

クエリcの大部分を消費する操作を探すost統計情報やインデックスの欠落、予期しないテーブルスキャン操作に関する警告など、多くの場合、これらは最適化の取り組みをどこに集中させるべきかを示しています。

3.5.5 問題のあるクエリの特定

[最近の高価なクエリ] ペインで次のパターンに注意してください。

過剰な処刑: 1 分間に何千回も実行されるクエリは、アプリケーションコードがループ内でデータベースを呼び出す N+1 クエリの問題を示している可能性があります。
高い物理読み取り: 物理読み取り率の高いクエリはディスクに頻繁にアクセスしており、インデックスが欠落しているか、クエリが適切に記述されていない可能性があります。
短い期間でCPU使用率が高い: 多数の高速クエリが合計で大量の CPU を消費すると、少数の低速クエリと同様にサーバーパフォーマンスに影響を及ぼす可能性があります。
複数プラン数: 実行プランが多数あるクエリでは、パラメータスニッフィングの問題が発生したり、パラメータ化されていないクエリによってプランキャッシュが肥大化したりする可能性があります。

4. アクティビティモニタを使用したパフォーマンスのトラブルシューティング

アクティビティモニターは、パフォーマンスの問題を体系的に診断・解決することで真価を発揮します。このセクションでは、よくあるトラブルシューティングのシナリオと、そのアプローチ方法について説明します。

4.1 過剰なクエリ実行の診断

それらの中の一つost 一般的なパフォーマンスの問題は、多くの場合、アプリケーションの設計上の問題により、クエリが必要以上に頻繁に実行されることです。

4.1.1 繰り返しクエリの識別

頻繁に実行されるクエリを見つけるには:

アクティビティモニターを開いて展開します 最近の高額なクエリ ペイン。
並べ替え 実行回数/分 (1 分あたりの実行回数)。
実行回数が不当に多いと思われるクエリを上位から探します。
疑わしいクエリを右クリックして選択 クエリテキストの編集 SQL ステートメントを調べます。

たとえば、単純な SELECT ステートメントが 1 分間に 37,000 回実行されている場合、アプリケーションがこのクエリを本当にそれほど頻繁に呼び出す必要があるかどうか疑問に思うでしょう。ost 1 分間に数千回以上実行されるクエリは調査が必要です。

4.1.2 根本原因の分析

過剰なクエリ実行は通常、次の問題に起因します。

N+1クエリ問題: アプリケーションコードはアイテムのリストを取得し、各アイテムに対して個別のクエリを実行して関連データを取得します。これにより、N個の追加クエリが生成されます（Nはアイテム数）。
キャッシュがありません: アプリケーションはデータベースに問い合わせて、 rarアプリケーションメモリにキャッシュするのではなく、変更のみを保存します。
ポーリングループ: コードは、変更通知やメッセージキューを使用するのではなく、状態の変更をチェックしながらデータベースを繰り返しクエリします。
ORMの非効率性: Entity Framework や類似のツールでは、開発者がコードが SQL にどのように変換されるかを理解していない場合に、非効率的なクエリパターンが生成されることがあります。

根本原因を特定するには、クエリをアプリケーションコードまで遡ります。用途 and ログイン クエリ実行時にプロセスペインの列に表示されます。プロセスを右クリックして トレースプロセス SQL Server プロファイラー 呼び出しパターンを確認します。

4.1.3 ソリューションとベストプラクティス

過剰なクエリ実行を特定したら、次の解決策を検討してください。

バッチ処理： ループ内で個別のクエリを実行するのではなく、結合または IN 句を使用して単一のクエリで複数の項目を取得するようにアプリケーションコードを変更します。
結果のキャッシュ: 頻繁にアクセスされ、頻繁に変更されないデータを適切な有効期限でアプリケーションメモリにキャッシュします。
熱心な読み込み: より少ない、より効率的なクエリで関連データを取得する、積極的な読み込み戦略を使用するように ORM を構成します。
クエリのパラメータ化: クエリでは値を連結するのではなくパラメータを使用するようにすることで、プランキャッシュの再利用性が向上し、コンパイルのオーバーヘッドが削減されます。

4.2 ブロッキング問題の調査

ブロッキングは、あるセッションがロックを保持し、他のセッションの進行を妨げているときに発生します。これは、アプリケーションの応答速度の低下やユーザーの不満といった形で現れます。

4.2.1 ブロッキングチェーンの識別

ブロックを検出して分析するには:

アクティビティモニターを開いて展開します プロセス ペイン。
値を持つセッションを探す ブロックされた 列—これらは他のセッションによって保持されているロックを待機しています。
'1'を含むセッションを検索 ヘッドブロッカー コラム—これらがブロッキングチェーンの根本的な原因です。
注意してください セッションID ヘッドブロッカーの。
ヘッドブロッカーセッションを右クリックして選択 Details 実行されているコマンドを確認します。

ブロッキングチェーンを理解することは非常に重要です。調査が必要なのは、下流のブロックされたセッションではなく、先頭のブロッカーセッションです。

4.2.2 ロックの種類について

その 待機タイプ プロセスペインの列には、ブロックされたセッションが待機しているロックの種類が表示されます。

LCK_M_X: 排他ロック待機。通常は UPDATE、DELETE、または INSERT 操作によって発生します。
LCK_M_S: 共有ロックの待機。通常は、排他ロックが解放されるのを待機する SELECT ステートメントです。
LCK_M_U: 更新ロック待機。更新時に使用される中間ロックタイプです。
LCK_M_IX: ページレベルまたは行レベルのロック競合を示す、意図的な排他ロック待機。

その 待機リソース 列には、どのデータベースオブジェクトがロックされているかが表示され、競合に関係しているテーブルまたはインデックスを把握するのに役立ちます。

4.2.3 ブロッキング問題の解決

ブロックしているセッションとその動作を特定したら、いくつかのオプションがあります。

完了を待ちます: ヘッドブロッカーが、すぐに完了する正当なクエリを実行している場合は、自然に終了させるのが最善の策である可能性があります。
セッションを終了する: ヘッドブロッカーがスタックしているか、キャンセルする必要があるクエリを実行している場合:
- [プロセス] ペインでセッションを右クリックします。
- 選択する プロセスを殺す.
- ダイアログボックスでアクションを確認します。
クエリの最適化: 同じクエリでブロックが繰り返される場合は、クエリを最適化してロック期間を短縮します。
分離レベルを調整する: 読み取り負荷の高いワークロードでのブロッキングを減らすには、READ COMMITTED SNAPSHOT ISOLATION の使用を検討してください。
インデックスのチューニング: インデックスを追加すると、クエリが高速化され、ロックを保持する時間が短縮されます。

4.3 高いCPU使用率の分析

[概要] ペインにプロセッサ時間が一貫して 100% またはそれに近い値で表示される場合は、どのクエリが原因であるかを特定し、最適化できるかどうかを判断する必要があります。

4.3.1 CPU負荷の高いクエリの特定

CPU を過剰に消費しているクエリを見つけるには:

Video Cloud Studioで 最近の高額なクエリ ペイン。
並べ替え CPU（ミリ秒/秒） mを使用してクエリを表示するost CPU時間。
リスト内の上位のクエリを調べます。
CPU使用率の高いクエリを右クリックして選択 クエリテキストの編集 SQL ステートメントを表示します。
選択する 実行プランを表示 クエリがどのように実行されるかを理解するため。

個々のクエリのCPU使用率だけでなく、 実行回数/分 列。実行ごとに CPU を中程度使用するものの、1 分間に数千回実行されるクエリは、CPU を最も多く消費する可能性があります。

4.3.2 クエリ最適化手法

CPU 消費量を削減するための一般的なアプローチは次のとおりです。

不足しているインデックスを追加します: インデックスシークはテーブルスキャンよりもCPU消費量が大幅に少なくなります。実行プランで不足しているインデックス推奨事項を確認してください。
非効率的なクエリを書き換える: カーソルをセットベースの操作に置き換え、WHERE 句内の不要な関数を削除し、冗長な結合を削除します。
統計情報を更新: 古い統計は SQL Server 非効率的な実行プランを選択する可能性があります。影響を受けるテーブルに対してUPDATE STATISTICSを実行してください。
データ量を削減: 事前に WHERE 句を追加してデータをフィルター処理し、ページ区切りに TOP または OFFSET/FETCH を使用し、SELECT * を回避します。
パラメータスニッフィングを修正: パラメータスニッフィングによって問題が発生する場合は、OPTION (RECOMPILE)、クエリヒント、またはプランガイドを使用します。

4.4 メモリの問題の調査

メモリ不足によりクエリがディスクに書き込まれ、パフォーマンスが著しく低下する可能性があります。アクティビティモニターは、メモリを大量に消費する操作を特定するのに役立ちます。

4.4.1 メモリメトリックの理解

その メモリ使用 プロセスペインの列には、各セッションに割り当てられたメモリがキロバイト単位で表示されます。単一のセッションでメモリ使用量が多い場合、多くの場合、次のような状況を示しています。

当初割り当てられたメモリに収まらなかった大規模なソートまたはハッシュ操作
膨大な結果セットを取得するクエリ
過剰な並列処理により実行プラン演算子の多くのコピーが作成される
CLR ストアドプロシージャまたは関数のメモリリーク

クエリが十分なメモリ許可を取得できず、メモリが使用可能になるまで待機する必要がある場合、[リソース待機] ペインにメモリ待機が表示されることがあります。

4.4.2 メモリを大量に消費するクエリの識別

メモリ負荷の原因となるクエリを見つけるには:

プロセス ペイン、並べ替え メモリ使用 mを消費しているセッションを確認するost メモリ。
メモリ使用量が多いセッションを右クリックして選択 Details クエリを表示します。
最近の高額なクエリ ペインで、高いクエリを探します 論理読み取り or 論理書き込みこれらは多くの場合、メモリ使用量と相関関係にあるためです。
メモリ許可を使用するソート演算子とハッシュマッチ演算子の実行プランを調べます。

実行プランに「メモリ許可」警告またはスピル警告が表示されるクエリは、メモリ不足の問題を示しています。

4.5 アプリケーションパフォーマンスの問題の検出

アプリケーションの応答時間が遅いとユーザーが報告した場合、アクティビティモニターはデータベースがボトルネックになっているかどうかを判断するのに役立ちます。

4.5.1 アクティビティモニターとアプリケーションの問題の相関関係

アプリケーションの速度低下を調査するには:

ユーザーが問題を報告した正確な時間と、影響を受けるアプリケーションに注意してください。
アクティビティモニターを開いて、 製品の概要 その時点でのリソースの急増を示すペイン。
プロセス ペイン、フィルター用途影響を受けるアプリケーションからの接続のみを表示します。
高いものを探す 待ち時間 データベースの遅延を示す値。
チェック 最近の高額なクエリ 大量のリソースを消費するアプリケーションからのクエリのペイン。

ユーザーが速度低下を経験している一方で、データベースに異常なアクティビティが見られない場合、問題はアプリケーションコード、ネットワーク遅延、またはクライアント側のパフォーマンスにある可能性があります。

4.5.2 非効率的なアプリケーションパターンの特定

アクティビティモニターは、アプリケーション設計におけるいくつかのアンチパターンを明らかにします。

チャットアプリケーション: より効率的な少数のクエリではなく、多数の小さなクエリ。「最近の高コストクエリ」で、接続数が多く、単純なクエリが多数あることで識別されます。
N+1クエリ: 1 回のクエリに続いて、関連データを取得する N 回の追加クエリが実行されます。1 分あたりの実行回数が非常に多い単純なクエリとして表示されます。
大規模な結果セット: アプリケーションは必要以上に多くのデータを取得しています。 論理読み取り 単純な SELECT * クエリと組み合わせます。
タイムアウトがありません: コマンドタイムアウトを設定していないアプリケーションでは、接続が無期限に開いたままになる場合があり、プロセスペインに長時間実行セッションとして表示されます。

5. 代替方法: T-SQL 経由でアクティビティモニターデータを取得する

アクティビティモニターは便利なグラフィカルインターフェイスを提供しますが、同等の情報をプログラムで取得したり、カスタム監視ソリューションを作成したりする必要がある場合もあります。

5.1 動的管理ビュー（DMV）の使用

SQL Server アクティビティモニターがバックグラウンドでクエリを実行する動的管理ビューを通じてアクティビティ情報を公開します。

5.1.1 アクティビティモニタリングの主なDMV

Most アクティビティモニターの機能を複製するための重要な DMV には次のものがあります。

sys.dm_exec_requests: 現在実行中の要求を CPU、I/O、待機情報とともに表示します。
sys.dm_exec_sessions: ログイン名、hなどのセッションレベルの情報が含まれますost 名前、プログラム名。
sys.dm_os_wait_stats: インスタンス全体の累積待機統計を提供します。
sys.dm_exec_query_stats: キャッシュされたクエリの集計パフォーマンス統計が含まれます。
sys.dm_io_virtual_file_stats: データおよびログファイルの I/O 統計を返します。
sys.dm_exec_sql_text: 指定された sql_handle または plan_handle の SQL テキストを取得します。
sys.dm_exec_query_plan: キャッシュされたクエリの実行プランを返します。

5.1.2 プロセス情報のサンプルクエリ

プロセスペインの機能を複製するには、次のクエリを実行します。

SELECT 
    s.session_id AS [Session ID],
    CASE WHEN s.is_user_process = 1 THEN 'Yes' ELSE 'No' END AS [User Process],
    s.login_name AS [Login],
    ISNULL(CAST(r.blocking_session_id AS VARCHAR), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), '') AS [Database],
    ISNULL(t.task_state, '') AS [Task State],
    ISNULL(r.command, '') AS [Command],
    r.cpu_time AS [CPU Time],
    r.total_elapsed_time AS [Elapsed Time],
    r.wait_time AS [Wait Time],
    r.wait_type AS [Wait Type],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

5.1.3 待機統計のサンプルクエリ

リソース待機ペインと同様の待機統計を表示するには:

SELECT TOP 10
    wait_type AS [Wait Type],
    wait_time_ms / 1000.0 AS [Wait Time (sec)],
    waiting_tasks_count AS [Waiting Tasks],
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS [Avg Wait Time (ms)]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
    AND wait_type NOT LIKE '%IDLE%'
    AND wait_type NOT LIKE '%QUEUE%'
ORDER BY wait_time_ms DESC;

5.2 sp_WhoIsActive の使用

sp_WhoIsActive は、コミュニティが作成した強力なストアドプロシージャであり、アクティビティモニターよりも詳細な情報を単一の結果セットで提供します。

5.2.1 sp_WhoIsActiveのインストール

sp_WhoIsActive をインストールするには:

から最新バージョンをダウンロードします http://whoisactive.com.
ダウンロードは、プロシージャ定義を含む SQL スクリプトです。
スクリプトを開く SQL Server ManagementStudio。
に接続します SQL Server インスタンス。
スクリプトを実行して、マスターデータベースにプロシージャを作成します。
適切なユーザーに実行権限を付与します。

sp_WhoIsActive はマスターにインストールされているため、どのデータベースコンテキストからでもアクセスできます。

5.2.2 基本的な使用例

sp_WhoIsActive を使用する最も簡単な方法は次のとおりです。

EXEC sp_WhoIsActive;

これにより、すべてのアクティブセッションとそのクエリ、待機タイプ、ブロック情報、およびリソース使用量を示す結果セットが返されます。

その期間のアクティビティを示す 10 秒間のサンプルの場合:

EXEC sp_WhoIsActive @delta_interval = 10;

これは、CPU や読み取りなどのメトリックのデルタを計算し、その 10 秒間に何が起こったかを表示します。

5.2.3 高度なパラメータ

sp_WhoIsActive はカスタマイズ用に多数のパラメータをサポートしています。

@フィルター： 結果を特定のセッション、データベース、またはログインにフィルタリングします。
@フィルタータイプ: フィルターの適用対象 (セッション、データベース、ログインなど) を指定します。
@get_plans: 結果に実行プランを含めます (1 に設定)。
@get_locks: 詳細なロック情報を表示します (1 に設定)。
@get_transaction_info: トランザクションの詳細を表示します (1 に設定)。
@並べ替え順序: さまざまなメトリック (CPU、読み取り、期間など) で結果を並べ替えます。
@宛先テーブル: 履歴追跡のために結果をテーブルに挿入します。

CPU 別にソートされたプランを示す例:

EXEC sp_WhoIsActive 
    @get_plans = 1,
    @sort_order = '[CPU] DESC';

5.3 システムストアドプロシージャの使用

SQL Server アクティビティを監視するための従来のストアドプロシージャが含まれていますが、DMV やアクティビティモニターよりも提供される情報は少なくなります。

5.3.1 sp_who と sp_who2

sp_who プロシージャは基本的なセッション情報を表示します。

EXEC sp_who;

sp_who2 プロシージャでは、もう少し詳細な情報が提供されます。

EXEC sp_who2;

どちらの手順でも、セッションID、ログイン名、CPU時間、ブロック情報が表示されます。ただし、DMVやアクティビティモニターで得られる詳細な情報はありません。ost 最小限の情報がすぐに必要なときに、簡単に確認するのに役立ちます。

5.3.2 その他の便利なシステム手順

監視のための追加のシステム手順は次のとおりです。

sp_ロック: ロック情報を表示します (非推奨。代わりに sys.dm_tran_locks を使用してください)。
sp_モニター: 統計情報を表示します SQL Server 活動。
sp_ヘルプ: オブジェクトの定義とメタデータを表示します。
DBCC SQLPERF: トランザクションログのスペース使用量と待機統計を表示します。

5.4 カスタム監視スクリプトの作成

Activity Monitor が提供する以上の特定の監視を必要とする環境では、DMV を使用してカスタムソリューションを構築できます。

5.4.1 完全なアクティビティモニター相当のスクリプト

これはmを再現する包括的なスクリプトですost アクティビティモニターの機能:

-- Processes Information
SELECT 
    s.session_id AS [Session ID],
    CONVERT(CHAR(1), s.is_user_process) AS [User Process],
    s.login_name AS [Login],
    ISNULL(CONVERT(VARCHAR, w.blocking_session_id), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), N'') AS [Database],
    ISNULL(t.task_state, N'') AS [Task State],
    ISNULL(r.command, N'') AS [Command],
    SUBSTRING(st.text, (r.statement_start_offset/2) + 1,
        ((CASE r.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE r.statement_end_offset 
        END - r.statement_start_offset) / 2) + 1) AS [Statement],
    st.text AS [Command Text],
    r.cpu_time AS [CPU Time (ms)],
    r.total_elapsed_time / 1000 AS [Elapsed Time (sec)],
    r.wait_time AS [Wait Time (ms)],
    r.wait_type AS [Wait Type],
    r.wait_resource AS [Wait Resource],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    c.client_net_address AS [Net Address],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests w ON r.session_id = w.blocking_session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id 
    AND r.request_id = t.request_id
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

-- Recent Expensive Queries
SELECT TOP 20
    qs.execution_count / 
        DATEDIFF(MINUTE, qs.creation_time, GETDATE()) AS [Executions/min],
    qs.total_worker_time / 1000 AS [CPU Time (ms)],
    qs.total_physical_reads AS [Physical Reads],
    qs.total_logical_writes AS [Logical Writes],
    qs.total_logical_reads AS [Logical Reads],
    qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg Duration (ms)],
    SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
        ((CASE qs.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset 
        END - qs.statement_start_offset) / 2) + 1) AS [Query Text]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE qs.execution_count > 0
ORDER BY qs.total_worker_time DESC;

5.4.2 SQLエージェントジョブによる監視の自動化

カスタム監視スクリプトをスケジュールするには、 SQL Server エージェント：

監視結果を保存するテーブルを作成します。
監視スクリプトを変更して、結果をこのテーブルに挿入します。
In SQL Server 管理スタジオ、展開 SQL Server エージェント オブジェクトエクスプローラーで。
右クリックする求人をクリックして 新しい仕事.
監視スクリプトを定期的に実行するようにジョブを構成します。
収集されたデータに基づいてアラートまたはレポートを設定します。

このアプローチにより、アクティビティモニターでは提供されない履歴の追跡と傾向分析が可能になります。

6. アクティビティモニターの制限と考慮事項

アクティビティモニターは便利ですが、その制限を理解しておくと、適切に使用し、必要に応じて他のツールで補うことができます。

6.1 アクティビティモニターのオーバーヘッドを理解する

アクティビティモニターは無料ではありません。情報を収集して表示するためにサーバーリソースを消費します。このオーバーヘッドを理解することで、責任を持って使用できるようになります。

6.1.1 サーバーリソースへの影響

アクティビティモニターは、更新のたびにシステムDMVに対してクエリを実行します。これらのクエリはCPUを消費し、論理読み取りを生成し、システムテーブルを一時的にロックすることがあります。負荷の高いサーバーでは、このオーバーヘッドがパフォーマンスに影響を与える可能性があります。

「プロセス」ペインと「最近の高負荷クエリ」ペインは、潜在的に大きなDMVとキャッシュテーブルをスキャンする必要があるため、特に負荷が高くなります。数千のキャッシュされたクエリプランを持つサーバーでは、「最近の高負荷クエリ」の更新に数秒かかる場合があります。

Microsoft のドキュメントでは、更新間隔が 10 秒未満の場合、特に既に負荷がかかっているシステムでは、サーバーのパフォーマンスに顕著な影響を与える可能性があると警告しています。

6.1.2 更新間隔のベストプラクティス

状況に応じて適切な更新間隔を選択します。

1～5秒: 負荷の低いサーバーにおける重大な問題の即時トラブルシューティングにのみ使用してください。アクティビティモニターは、この間隔で実行したままにしないでください。
10秒（デフォルト）: mにとってリーズナブルost トラブルシューティングのシナリオと一般的な監視。
30～60秒: 負荷の高い運用サーバーや長期間にわたる監視を行う場合に適しています。
手動更新のみ: 継続的なポーリングを行わずに、現在の状態を時々確認したい場合。

調査が終わったら、必ずアクティビティモニターを閉じてください。特に異なるユーザーによる複数のインスタンスでアクティビティモニターが継続的に実行されている場合は、アクティビティモニターを常に実行したままにしないでください。

6.2 待機タイプのグループ化の問題

アクティビティモニターの待機の分類方法は、ビューを簡素化する一方で、重要な診断を見えにくくする可能性がある。ostic 情報。

6.2.1 アクティビティモニターの待機のグループ化方法

SQL Server 数百種類の異なる待機タイプを追跡します。それぞれが特定のリソースまたは状態を示します。アクティビティモニターは、これらを「バッファラッチ」、「ロック」、「メモリ」などの大まかなカテゴリに分類します。

例えば、「バッファラッチ」カテゴリには、PAGELATCH_SH、PAGELATCH_UP、PAGELATCH_EX、その他いくつかの特定の待機タイプが含まれます。これらはすべてページアクセスに関連していますが、原因と解決策はそれぞれ異なります。

Microsoft では、どの待機タイプがどのカテゴリにマップされるかを正確に文書化していないため、実際に何が表示されるのか理解することが困難です。

6.2.2 不足している待機タイプ

アクティビティモニターはすべての待機タイプを表示しません。Most 特に、並列クエリ実行を示す CXPACKET 待機が省略されることが多いです。CXPACKET 待機は一般的であり、通常は問題にはなりませんが、その存在を把握しておくと、ワークロードの特性を理解するのに役立ちます。

アクティビティモニターで「バッファーラッチ」が最多待機時間として表示されているのに、他のツールでは CXPACKET が優勢であると表示される場合、その不一致はアクティビティモニターのフィルタリングおよびグループ化のロジックに起因します。

6.2.3 特定の待機タイプが重要な理由

トラブルシューティングには、特定の待機タイプを知ることが重要です。

ページラッチ_EX: 多くの場合、アロケーションページでのtempdbの競合が原因と考えられます。解決策としては、tempdbデータファイルの追加が挙げられます。
ページラッチ_SH: ユーザーテーブル内のホットページを示している可能性があります。解決策としては、パーティション分割またはインデックスの再編成が必要です。
ページラッチアップ: アップデート中によく発生します。問題ではなく、正常な動作を示している可能性があります。

アクティビティモニターはこれらすべてを「バッファラッチ」にグループ化するため、診断が困難になります。sp_WhoIsActiveやDMVクエリなどのツールは、特定の待機タイプを表示します。

6.3 データの正確性と適時性

アクティビティモニターはほぼリアルタイムのビューを提供しますが、「ほぼ」という言葉が重要です。データ収集方法を理解することで、結果を正しく解釈できるようになります。

6.3.1 スナップショットと継続的な監視

アクティビティモニターは、更新間隔ごとに取得されたポイントインタイムのスナップショットを表示します。スナップショット間で発生したイベントはキャプチャされません。クエリの実行時間が2秒で、10秒ごとに更新している場合、タイミングによっては、一度しか表示されないか、全く表示されない可能性があります。

つまり、アクティビティモニターは、永続的な問題 (数分間続くブロック、一貫して高い CPU 使用率) を見つけるのに優れていますが、一時的な問題 (短時間のデッドロック、時々発生するクエリの急増) を見逃す可能性があります。

6.3.2 集計とサンプリング

「最近の高負荷クエリ」ペインには、クエリプランがキャッシュに入ってからの集計データが表示されます。パラメータ値が異なる2つの同一クエリが同じプランを共有している場合、1行として表示されます。この集計により、特定のパラメータの組み合わせに関する問題（パラメータスニッフィングの問題）が隠れてしまう可能性があります。

リソース待機ペインは、スナップショットを比較してレートを計算します。待機統計がスナップショット間でリセットされた場合（rarただし、可能であれば、計算されたレートが正しくない場合もあります。

6.4 アクティビティモニターを使用しない場合

アクティビティモニターはあらゆる監視シナリオに適しているわけではありません。代替ツールの方が適している場合があることを認識しておきましょう。

6.4.1 履歴分析の要件

アクティビティモニターは現在または最近のアクティビティのみを表示します。履歴データは保存されません。数日または数週間にわたる傾向を分析したり、現在のパフォーマンスを基準と比較したり、パフォーマンスパターンに関するレポートを生成したりする必要がある場合、アクティビティモニターだけでは不十分です。

歴史的分析には、 SQL Serverの組み込みパフォーマンスダッシュボード、ファイル付き拡張イベント tar取得、またはサードパーティの監視ソリューションを使用します。

6.4.2 詳細な待機統計の必要性

高度なチューニングのために正確な待機タイプ情報が必要な場合、アクティビティモニターのグループ化とフィルタリングでは不十分です。DMVクエリを直接使用するか、sp_WhoIsActiveを使用してください。

包括的な待機統計分析を行うには、sys.dm_os_wait_stats を直接クエリし、無害な待機を手動で除外します。

6.4.3 本番サーバーに関する考慮事項

負荷の高い本番サーバーでは、アクティビティモニターのオーバーヘッドが問題となる可能性があります。複数のデータベース管理者が、同じサーバー上で同時にアクティビティモニターを実行しないでください。

運用監視の場合は、監視データベースに保存されるスケジュールされた DMV スナップショットなどの軽量な代替手段を検討するか、読み取り専用ルーティングを使用して Always On 構成でセカンダリレプリカを監視します。

7. アクティビティモニターの使用に関するベストプラクティス

ベストプラクティスに従うことで、サーバーへの悪影響を最小限に抑えながら、アクティビティモニターから最大限の価値を引き出すことができます。

7.1 アクティビティモニターを使用する場合

アクティビティモニターは特定のシナリオで真価を発揮します。その強みがあなたのニーズに合致するときにご利用ください。

7.1.1 リアルタイムパフォーマンスの問題

アクティビティモニターは、ユーザーが現在問題を抱えており、すぐに診断する必要がある場合に最適です。リアルタイムビューで、現在何が起こっているかを確認できます。

「アプリケーションが遅い」という連絡を受けたら、まずアクティビティモニターを開いてみてください。データベースがビジー状態か、ブロック状態か、アイドル状態かをすぐに確認できます。

7.1.2 アプリケーションの速度低下の調査

特定のアプリケーションが応答しなくなった場合、アクティビティモニターはデータベースの問題が原因であるかどうかを判断するのに役立ちます。プロセスパネルをアプリケーション名でフィルタリングすると、そのアプリケーションのデータベースアクティビティのみが表示されます。

ユーザーから問題が報告されているにもかかわらず、アプリケーションにデータベースアクティビティがまったく見られない場合、問題はスタック内の別の場所にあります。大規模なブロックや高負荷のクエリが発生している場合は、原因が特定できたことになります。

7.1.3 クイックヘルスチェック

アクティビティモニターは、日常的な管理作業中に素早くヘルスチェックを行うための優れたダッシュボードを提供します。ダッシュボードを開いて概要グラフを確認し、異常がないか確認してください。

この簡単なチェックは数秒で完了し、問題が深刻化する前に発見することができます。毎日の習慣にしましょう。

7.2 最適な構成設定

アクティビティモニターを適切に構成すると、その有用性とリソースフットプリントの両方が向上します。

7.2.1 推奨される更新間隔

更新間隔を目的に合わせてください。

アクティブなトラブルシューティング: 10 秒であれば、適度なオーバーヘッドで良好な応答性が実現します。
拡張監視: 30 ～ 60 秒にすると、長時間の監視期間中のサーバーへの影響が軽減されます。
重大な問題の診断: 1 秒ごとに重要な場合は 5 秒にすると粒度が高くなりますが、短時間だけ使用してください。
定期的な健康診断： アクティブに視聴していない場合は手動で更新します（1 時間間隔）。

終了したらアクティビティモニターを閉じることを忘れないでください。長い間隔を設定して忘れると、サーバーのリソースが無駄になります。

7.2.2 フィルタリング戦略

フィルターを使用して関連情報に焦点を絞り、認知負荷を軽減します。

プロセスをフィルタリング データベース 特定のデータベースに対するアクティビティのみを表示します。
絞り込む ログイン 特定のユーザーのアクティビティを追跡します。
絞り込む タスクの状態 = RUNNING はアイドルセッションを非表示にします。
絞り込む用途特定のプログラムからのトラフィックを分離します。
空白以外の文字のみ表示 ブロックされた ブロック状況のみを確認します。

7.2.3 列の選択と並べ替え

アクティビティモニターのデータを確認するための体系的なアプローチを開発します。

Star概要付き: グラフをチェックして、明らかな急上昇や異常がないか確認します。
ブロックするプロセスを確認します: セッション ID で並べ替えて、Blocked By 値を探します。
リソース待機の確認: 累積待機時間で並べ替えて、リソースのボトルネックを特定します。
コストのかかるクエリを分析する: さまざまなメトリック (CPU、実行、読み取り) で並べ替えて、さまざまな問題の種類を見つけます。
I/O ペインで検証: I/O 集中型のクエリがディスクアクティビティの増加と相関しているかどうかを確認します。

7.3 他のツールとの統合

アクティビティモニターは、スタンドアロンソリューションとしてではなく、より広範なツールキットの一部として使用すると最適に機能します。

7.3.1 使用 SQL Server プロファイラー

アクティビティモニターと SQL Server プロファイラーは互いにうまく補完し合います。アクティビティモニターで問題のあるセッションを見つけたら、それを右クリックして トレースプロセス SQL Server プロファイラー.

これにより、そのセッションのアクティビティのみをキャプチャするように設定されたフィルターを備えたプロファイラーが起動します。実行されたステートメントの完全なシーケンス、タイミング情報、エラーメッセージなど、アクティビティモニターでは提供されない詳細情報が表示されます。

の詳細については SQL Server プロファイラー機能と高度なトレース技術については、包括的な SQL Server プロファイラーガイド.

7.3.2 拡張イベントによる補完

拡張イベントは、アクティビティモニターでは捕捉できない情報を、オーバーヘッドの少ない詳細な監視機能で捕捉します。拡張イベントセッションを作成して、デッドロック、長時間実行クエリ、過剰な再コンパイルといった特定のイベントを追跡できます。

即時の調査にはアクティビティモニターを、継続的な監視と履歴分析には拡張イベントをご利用ください。この2つのツールはそれぞれ異なるニーズに対応します。

の詳細については SQL Server 拡張イベント機能と高度な監視技術については、包括的な SQL Server 拡張イベントガイド.

7.3.3 サードパーティの監視ソリューション

SolarWinds Database Performance Analyzer、Redgate SQL Monitor、Quest Spotlightなどの商用ツールは、アクティビティモニターにはないアラート、履歴傾向、キャパシティプランニング、自動診断などの機能を提供します。ostic。

これらのツールはアクティビティモニターの便利な追加機能であり、代替ツールではありません。高度な監視ツールが利用可能になった場合でも、アクティビティモニターは迅速なチェックや調査に役立ちます。

7.4 避けるべきよくある間違い

アクティビティモニターのよくある間違いを理解すると、アクティビティモニターをより効果的に使用できるようになります。

7.4.1 アクティビティモニターを継続的に実行する

Most よくある間違いは、アクティビティモニターを開いて無期限に実行したままにすることです。これはサーバーリソースを浪費し、実際に監視していないためほとんど役に立ちません。

アクティビティモニターをあまり使用していないときは閉じてください。継続的な監視が必要な場合は、代わりにスケジュールされたデータ収集機能を備えた適切な監視ソリューションを導入してください。

7.4.2 アクティビティモニターだけに頼りすぎる

アクティビティモニターは、サーバーの健全性に関する単一の視点を提供します。これだけに頼りすぎないでください。OSレベルのメトリクスにはWindowsパフォーマンスモニター、詳細な追跡には拡張イベント、クエリチューニングには実行プラン分析を併用してください。

アクティビティモニターは問題を特定するのに役立ちますが、問題を解決するには、多くの場合、追加のツールとより詳細な分析が必要になります。

詳細については、こちらから SQL Server パフォーマンスモニター完全なガイド.

7.4.3 歴史的傾向を無視する

アクティビティモニターは現在の状態を表示しますが、パフォーマンスの問題は多くの場合、時間の経過とともにパターンが明らかになります。履歴データの収集を実装することで、現在の指標をベースラインと比較し、傾向を特定できます。

過去の状況を把握していなければ、今日の「通常の」CPU 使用率が先月の基準値より 30% 高く、徐々に低下していることに気付かないかもしれません。

8. アクティビティモニターの問題のトラブルシューティング

アクティビティモニター自体に問題が発生することがあります。こうした問題のトラブルシューティング方法を知っておくと、イライラを防ぐことができます。

8.1 アクティビティモニターが開かない、またはデータが表示されない

アクティビティモニタが開いても空白のペインが表示される場合、またはまったく開かない場合は、いくつかの要因が考えられます。

8.1.1 権限の問題

Most アクティビティモニターの問題の一般的な原因は、権限不足です。確認して解決するには、以下の手順に従ってください。

サーバーレベルの権限を確認してください:

SELECT * FROM fn_my_permissions(NULL, 'SERVER')
WHERE permission_name = 'VIEW SERVER STATE';

行が返されない場合は、VIEW SERVER STATE 権限がありません。
サーバー管理者に許可を依頼してください:
```
USE master;
GRANT VIEW SERVER STATE TO [YourLogin];
```
権限が付与されたら、アクティビティモニターを閉じて再度開きます。

8.1.2 バージョン互換性の問題

古いバージョンの SQL Server Management Studioで新しいものに接続 SQL Server バージョンによっては、アクティビティモニターに障害が発生する可能性があります。ツールが新しい待機タイプやシステムビューの列を認識できない可能性があります。

常に、使用しているバージョンと一致するかそれより新しいSSMSバージョンを使用してください。 SQL Server バージョン。Microsoftは最新のSSMSを、 SQL Server そのもの。

8.1.3 ファイアウォールとネットワークの問題

アクティビティモニターには、 SQL Server 標準ポート（デフォルトは1433）でインスタンスに接続します。オブジェクトエクスプローラー経由で接続できるのにアクティビティモニターで接続できない場合は、ファイアウォールルールによって特定の接続がブロックされている可能性があります。

クライアントがアクセスできることを確認してください SQL Server 必要なすべてのポートでマシンのセキュリティを確保してください。Windowsファイアウォールと、クライアントとサーバー間のネットワークファイアウォールの両方を確認してください。

8.2 アクティビティモニターが永久に一時停止されました

特に、 SQL Server 2019年、アクティビティモニターが一時停止状態で開き、再開を拒否します。

8.2.1 一時停止状態を理解する

アクティビティモニターが一時停止すると、すべてのペインに「一時停止」ステータスが表示され、再開ボタンは機能しない場合があります。そのため、サーバーのアクティビティを確認できなくなります。

一時停止状態は通常、意図的な一時停止アクションではなく、アクセス許可の問題、リモート接続の制限、または SSMS バージョンのバグによって発生します。

8.2.2 一般的な原因

アクティビティモニターは、次の理由により永続的に一時停止状態になる場合があります。

最近追加された新しいペインにVIEW SERVER STATE権限がありません SQL Server バージョン
リモート接続が無効になっています SQL Server
特定のシステムクエリに対する認証失敗
特定の SSMS ビルド（特に 18.0 から 18.3）のバグ
クライアントとサーバー間の接続の問題

8.2.3 解決手順

アクティビティモニターの一時停止状態の問題を解決するには:

SSMS を更新します。 最新のものをダウンロードしてインストールする SQL Server Microsoft のウェブサイトから入手できる Management Studio バージョン。一時停止状態に関する多くのバグは、以降のリリースで修正されました。
権限を確認します: VIEW SERVER STATE および VIEW ANY DEFINITION 権限があることを確認してください。
リモート接続を確認します。 その SQL Server インスタンスはリモート接続を許可します:
```
EXEC sp_configure 'remote access';
```
値が 0 の場合は、管理者に有効にするよう依頼してください。
解像度tart SSMS: 時にはすべてのウィンドウを閉じてtarティン SQL Server Management Studio は問題を解決します。
Windows 認証で接続します。 SQL 認証を使用している場合は、認証関連の一時停止の問題を回避することができるため、代わりに Windows 認証を試してください。

8.3 アクティビティモニター使用時のパフォーマンスの問題

アクティビティモニター自体が遅くなったり、サーバーのパフォーマンスが低下したりする場合は、調整が必要です。

8.3.1 監視オーバーヘッドの削減

アクティビティモニタの影響を最小限に抑えるには:

更新間隔を 30 秒または 1 分に増やします。
折りたたみボタンをクリックして、使用していないペインを閉じます。
ペインが折りたたまれている場合、アクティビティモニターはペインのデータを照会しません。
複数のアクティビティモニターインスタンスを同時に実行することは避けてください。
問題を積極的に調査していない場合は、アクティビティモニターを完全に閉じます。

8.3.2 代替の軽量監視方法

アクティビティモニターが環境に対してリソースを大量に消費する場合は、代替手段を検討してください。

DMV を直接クエリします。 必要な情報のみを取得する特定の T-SQL クエリを記述します。
sp_WhoIsActive を使用します。 このストアドプロシージャは高度に最適化されており、通常はアクティビティモニターよりもオーバーヘッドが低くなります。
サンプリングを実装する: DMV データのスナップショットを定期的にキャプチャし、後で分析できるように結果をテーブルに保存する SQL エージェントジョブをスケジュールします。
セカンダリレプリカを監視します。 In Always On 可用性グループ、プライマリではなく読み取り可能なセカンダリに対してアクティビティモニターを実行します。

8.4 不正確または不足している情報

アクティビティモニターには、不正確または不完全と思われる情報が表示されることがあります。

8.4.1 DMVによるデータの検証

アクティビティモニターの結果が疑わしい場合は、基盤となるDMVに直接クエリを実行して検証してください。例えば、「プロセス」ペインにブロックが表示されていないにもかかわらず、ユーザーからブロックが報告されている場合は、次のようにクエリを実行してください。

SELECT 
    blocking_session_id,
    session_id,
    wait_type,
    wait_time,
    wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id != 0;

このクエリに、アクティビティモニターが見逃したブロックが表示された場合は、表示の問題が確認されます。

8.4.2 データ更新タイミングの理解

アクティビティモニターにはスナップショットが表示されることに注意してください。更新間隔の間に実行されたクエリは、実行プランがキャッシュに残っていない限り、「最近の高負荷クエリ」には表示されません。

同様に、「リソース待機」ペインの待機統計は、前回のスナップショット以降の累積を反映します。ワークロードが急速に変化する場合は、更新ごとに異なるパターンが現れる場合があります。

9. 高度なアクティビティモニターテクニック

経験豊富なデータベース管理者は、アクティビティモニターを洗練された方法で使用して、最大限の診断結果を引き出します。ostic 値。

9.1 根本原因分析のための複数のペインの結合

アクティビティモニターの真の威力は、複数のペイン間で情報を相関させて複雑なパフォーマンスの問題を理解するときに発揮されます。

9.1.1 待機とプロセスの相関関係

リソース待機ペインでカテゴリの待機時間が長いことが示されている場合は、プロセスペインを使用して、どのセッションで待機が発生しているかを特定します。

累積待機時間が長い待機カテゴリ (「ロック」など) に注意してください。
プロセスペインに切り替えます。
並べ替え 待機タイプ 現在の待機時間別にセッションをグループ化します。
問題のあるカテゴリで待機タイプを示すセッションを探します。
これらのセッションでは、 待機リソース 列を見ると、どのデータベースオブジェクトが関係しているかがわかります。
右クリックして選択 Details クエリテキストを表示します。

この相関関係により、「ロック待機が発生している」状態から「この特定のクエリはこのテーブルのロック待ち状態にある」状態に移行できます。

9.1.2 高価なクエリとI/O問題の関連付け

データファイル I/O ペインに特定のデータベースのディスクアクティビティが高いことが示されている場合:

どのデータベースファイルが MB/秒の読み取りまたは書き込み速度が高いかに注意してください。
最近のコストの高いクエリに切り替えます。
並べ替え 物理読み取り/秒 ディスクから大量の読み取りを行うクエリを識別します。
高い I/O でデータベースに対して実行されているクエリをフィルタリングまたは視覚的に識別します。
これらのクエリの実行プランを調べて、テーブルスキャンやインデックスの欠落による過剰な I/O の発生を調べます。

このマルチペイン分析は、症状 (高いディスク I/O) と原因 (特定の非効率的なクエリ) を結び付けます。

9.2 アクティビティモニターを使用したキャパシティプランニング

アクティビティモニターは履歴データを保存しませんが、容量計画の監視に戦略的に使用できます。

9.2.1 ピーク使用パターンの特定

使用パターンを特定するために、1 日のさまざまな時間帯のサーバーアクティビティを監視します。

業務のピーク時間帯にアクティビティモニターを開きます。
% プロセッサ時間グラフのピーク値に注意してください。
待機中のタスクの最大数を記録します。
ピーク時のバッチリクエスト数/秒を観察します。
最もビジーなデータベースをプロセスペインに記録します。
比較のため、オフピーク時間帯に繰り返します。

ピーク時のプロセッサ時間が常に80%を超える場合、CPUの容量限界に近づいています。同様に、待機回数の増加はリソース競合の増加を示しています。

9.2.2 リソーストレンド分析

アクティビティモニターは現在の状態を表示しますが、時間の経過に伴う主要な指標を記録することで、傾向をスポットチェックするために使用できます。

毎日同じ時間に概要パネルのスクリーンショットを撮ります
各グラフからピーク値を記録する
週ごとの比較で成長傾向を把握する
平均プロセッサ時間またはI/Oレートの段階的な増加に注意してください

この手動の傾向分析は、より洗練された監視ソリューションを補完し、容量拡張の正当化に役立ちます。

9.3 パフォーマンスベースラインの文書化

ベースラインパフォーマンスメトリックを確立すると、パフォーマンスが低下したタイミングを認識するのに役立ちます。

9.3.1 ベースラインメトリックの取得

良好なパフォーマンスが判明している期間中に、アクティビティモニターのメトリックを記録します。

通常の業務運営中（ピーク時やオフピーク時ではない）にアクティビティモニターを開きます。
レコード概要ペインの値:
- 標準的な%プロセッサ時間範囲
- 平均待機タスク数
- 通常のデータベースI/Oレート
- 典型的なバッチリクエスト数/秒
注記リソース待機ペインのカテゴリには、mが表示されます。ost 待ち時間。
通常、アクティブなプロセスの数は [プロセス] ペインに記録されます。
最近のコストの高いクエリからの代表的なクエリ実行メトリックを記録します。

パフォーマンスの問題を調査するときに将来参照できるように、このベースラインドキュメントを保存します。

9.3.2 現在のパフォーマンスとベースラインのパフォーマンスの比較

パフォーマンスの問題が発生した場合は、現在のアクティビティモニターの読み取り値を、文書化されたベースラインと比較します。

プロセッサ時間はベースラインよりも大幅に長くなっていますか? CPU を集中的に使用するクエリに焦点を当てます。
待機中のタスクはベースラインレベルの 2 ～ 3 倍ですか? リソースの待機を調査します。
I/O が大幅に増加していますか? データファイル I/O ペインとコストのかかるクエリを確認してください。
ピーク時間帯のバッチリクエストはベースラインより少ないですか? ブロックや接続の問題がないか確認してください。

この比較により、何が変更されたかを特定し、トラブルシューティング作業に適切に集中できるようになります。

9.4 カスタム監視ワークフローの作成

徹底的かつ繰り返し可能な分析を確実に実行できるように、一般的な調査シナリオ向けの体系的なワークフローを開発します。

9.4.1 段階的な調査プロセス

ユーザーからパフォーマンスの問題が報告された場合は、一貫したワークフローに従ってください。

クイックヘルスチェック: アクティビティモニターを開き、概要ペインのグラフをスキャンして明らかな異常がないか確認します。
ブロックの確認: [プロセス] ペインを展開し、[ブロック元] 列で [NonBlanks] をフィルターします。
リソースの競合を特定する: 待機時間順に並べられたリソース待機ペインを確認します。
高価なクエリを見つける: CPU、実行、読み取りの順にソートされた最近の高価なクエリを調べます。
I/O パターンを相関させる: コストのかかるクエリをデータファイル I/O ペインのアクティビティと相互参照します。
文書の調査結果: スクリーンショットを撮り、関連するセッション ID、待機タイプ、クエリの詳細を記録します。
ディープダイブ： 特定された問題を詳細に調査するには、プロファイラートレース、実行プラン分析、および DMV クエリを使用します。

9.4.2 エスカレーション基準

問題をエスカレーションするか調査を継続するかの基準を確立します。

すぐにエスカレーションしてください: ブロッキングチェーンが 5 分を超えて継続し、プロセッサ時間が 2 分を超えて 100% になり、重要なシステムプロセスが SUSPENDED 状態を示しています。
分析を伴ってエスカレーション: 繰り返し発生する高価なクエリにより CPU 使用率が 50% を超え、一貫して I/O 応答時間が 50 ミリ秒を超え、メモリ付与が繰り返し失敗します。
さらに調査する: テンポrary は数分以内に解決を待機し、クエリのプランは最適ではないがパフォーマンスは許容範囲内、ブロックの期間は 30 秒未満です。

10. アクティビティモニターのさまざまな SQL Server バージョン

アクティビティモニターは進化してきました SQL Server バージョンがあり、リリースごとに機能強化が行われ、場合によっては新しい問題も発生します。

10.1 アクティビティモニター SQL Server 2008以降

SQL Server 2008 年に、現在もほとんど変わっていない最新のアクティビティモニターのデザインが導入されました。

10.1.1 で導入された新機能 SQL Server 2008

その SQL Server 2008 アクティビティモニターの再設計により、大幅な改善がもたらされました。

概要ペインにリアルタイムチャートを表示するグラフィカルダッシュボード
従来のグリッドのみのビューに代わる、展開/折りたたみ可能なペインインターフェース
集計クエリパフォーマンスデータを表示する最近の高コストクエリペイン
ファイルごとのディスクアクティビティを監視するためのデータファイルI/Oペイン
待機分類を備えた強化されたリソース待機ペイン
セッションの終了やプロファイラの起動などのプロセスアクションの右クリックコンテキストメニュー
1秒から1時間までの更新間隔を設定可能

これらの変更により、アクティビティモニターは単純なプロセスリストから包括的な監視ダッシュボードへと変化しました。

10.1.2 変更点 SQL Server 2005

SQL Server 2005 年のアクティビティモニターははるかに制限されていました。

ツールバーではなくオブジェクトエクスプローラーの管理フォルダーからアクセスします。
基本情報を含むプロセスリストを表示する単一のグリッド
グラフや複数のペインはありません
高価なクエリやI/O監視は不要
限定待機統計情報

2008 年の再設計は、段階的な改善ではなく、完全な再構想を表していました。

10.2 アクティビティモニター SQL Server 2014/2016

SQL Server 2014 と 2016 では、アクティビティモニターの基盤となるデータ収集に段階的な改善が加えられましたが、外観の変更はほとんどありませんでした。

10.2.1 改善と機能強化

これらのバージョンでの主な改善点は次のとおりです。

数千のキャッシュされたプランを持つサーバーを監視する際のパフォーマンスが向上
プロセスペインのフィルタリング機能が強化されました
待機統計集計の精度が向上
大規模な結果セットでの列の並べ替えとフィルタリングの処理が改善されました
より効率的な DMV クエリにより監視オーバーヘッドが削減されます

コアインターフェースは、 SQL Server 2008年、管理者にとっての親しみやすさを維持。

10.3 アクティビティモニター SQL Server 2019/2022

最近の SQL Server バージョンは、パフォーマンスと安定性に重点を置いて、アクティビティモニターの進化を続けています。

10.3.1 最新の機能と性能

SQL Server 2019 および 2022 アクティビティモニターには以下が含まれます。

これらのバージョンで導入された新しい待機タイプのサポート
WPF テクノロジを使用した SSMS のレンダリングパフォーマンスの向上
多数のアクティブセッションをより適切に処理
クラウドSQLプラットフォームとの互換性の強化
より正確なCPUおよびI/Oメトリック

10.3.2 最近のバージョンにおける既知の問題

SQL Server 2019 年にはアクティビティモニターのバグがいくつか発生しました。

永続的な一時停止状態: アクティビティモニターが頻繁に一時停止状態になり、再開しなくなります。特にSSMS 18.0～18.3で顕著です。この問題はSSMSのそれ以降のバージョンで修正されています。
リモート接続の失敗: 一部の構成では、リモートインスタンスでアクティビティモニターが開けません。回避策としては、特定のトレースフラグを有効にするか、新しいSSMSビルドを使用する方法があります。
権限の問題: 新しいシステムビューには、明確に文書化されていない追加の権限が必要であるため、VIEW SERVER STATE を使用しても空白が表示されます。

作業時には必ず最新のSSMSバージョンを使用してください。 SQL Server これらの問題を回避するには、2019 年と 2022 年までに実施してください。

11. 実用的なユースケースと例

実際の例を使用して、一般的なトラブルシューティングのシナリオでアクティビティモニターを効果的に適用する方法を示します。

11.1 ケーススタディ: 遅いWebアプリケーションの診断

開発チームから、Web アプリケーションの速度が許容できないほど遅くなり、ページの読み込みに通常の 2 ～ 3 秒ではなく 20 ～ 30 秒かかるようになったという報告がありました。

11.1.1 概要ペインを使用した初期調査

アクティビティモニターを開き、概要ペインを調べます。

% プロセッサ時間グラフには、CPU 使用率が 85 ～ 95% であることが示されています。これは、通常の 30 ～ 40% のベースラインよりも大幅に高い値です。
待機中のタスクは、通常のベースラインである 0 ～ 3 に対して、10 ～ 20 タスクの間で変動します。
データベース I/O は、約 50 MB/秒で中程度のアクティビティを示します。
バッチリクエスト数/秒は、営業時間中の通常の 300 ～ 400/秒に対して、予想より低い 100/秒です。

このパターンは、CPUのボトルネックとリソース競合によりスループットが低下していることを示しています。サーバーは負荷をかけていますが、多くのリクエストを処理できていません。

11.1.2 問題のあるクエリの特定

[最近の高コストクエリ] ペインを展開し、実行回数/分で並べ替えます。

上位のクエリでは、1 分あたり 15,000 回の実行が示されています。
右クリックして選択 クエリテキストの編集 クエリを調べます。
クエリは、単一のユーザーレコードを取得する単純な SELECT ステートメントです。 SELECT * FROM Users WHERE UserId = @UserId.
通常のアプリケーション使用では、このクエリは 1 分間に 15,000 回実行されることはありません。

クエリを右クリックして選択 実行プランを表示このプランには、Users テーブルに対するテーブルスキャンが表示され、UserId 列にインデックスがないという警告が表示されます。

プロセスペインをアプリケーションでフィルタリングすると、Webアプリケーションの接続のみが表示されます。複数のセッションでは、同じクエリが繰り返し実行されていることがわかります。

11.1.3 解決と検証

この問題は、クエリ実行の過剰とインデックスの不足という2つの問題に起因しています。解決手順：

不足しているインデックスを作成します。

CREATE NONCLUSTERED INDEX IX_Users_UserId 
ON Users (UserId);

開発チームに連絡する 過剰な実行について。調査の結果、アプリケーションコードにN+1クエリの問題があることが判明しました。このコードでは、ループによってリスト内の各項目のユーザー詳細が取得されます。
アプリケーションを変更する IN 句またはテーブル値パラメータを使用して、ユーザー検索を単一のクエリにバッチ処理します。
修正を確認する 展開後にアクティビティモニターを監視すると、CPU 使用率は 35 ～ 40% に低下し、1 分あたりの実行回数は 200 ～ 300 に減少し、アプリケーションの応答時間は正常に戻ります。

11.2 ケーススタディ: ブロッキング問題の解決

ユーザーからの報告によると、注文入力システムは、通常の操作を再開する前に、定期的に 30 ～ 60 秒間フリーズします。

11.2.1 ブロッキングチェーンの検出

これらのフリーズイベントのいずれかが発生したときにアクティビティモニターを開き、[プロセス] ペインを展開します。

並べ替え セッションID すべてのセッションの開催状況を確認します。
複数のセッションでは、 ブロックされた 列はすべてセッション ID 73 を指しています。
セッション73では「1」が表示されます ヘッドブロッカー 列を確認し、それが根本原因であることを確認します。
その 待機タイプ ブロックされたセッションの場合、排他ロックを待機していることを示す LCK_M_X が表示されます。
その 待機リソース 列を見ると、ブロックが Orders テーブルにあることがわかります。

11.2.2 原因の分析

セッション73を右クリックして Details コマンドを表示するには:

UPDATE Orders 
SET Status = 'Processing', 
    LastModified = GETDATE()
WHERE OrderId IN (SELECT OrderId FROM #TempOrders);

この更新は、1時間ごとに実行されるバッチ処理ジョブの一部です。 ログイン 列は、セッションがバッチ処理サービスアカウントに属していることを確認します。

クエリは数千の注文を処理しながらOrdersテーブルをロックしています。 待ち時間 ブロックされたセッションの数が着実に増加しており、この長時間実行される操作が問題であることが確認されています。

11.2.3 修正の実装

短期的な解決策:

クエリテキストと期間を含むセッション 73 の詳細を文書化します。
これは正当なバッチ処理なので、更新が自然に完了するようにしてください。
完了後、ブロックされたセッションがクリアされ、通常の操作が再開されることを確認します。

実施された長期的な解決策:

バッチジョブを再スケジュールする オフピーク時間（営業時間中ではなく、午前 2 時から午前 4 時）に実行します。
バッチ処理を変更する 一度に 100 件のレコードの小さなバッチで注文を更新し、バッチ間でロックを解除します。
インデックスを追加する 更新操作を高速化するために、OrderId 列に追加します。
SNAPSHOT分離を検討する 読み取り操作の場合、ブロックの影響を軽減します。

11.3 ケーススタディ: 過剰なクエリ実行の特定

データベースのモニタリングでは、CPU 使用率は過去 1 か月間で徐々に増加していますが、アプリケーションコードには明らかな変更は発生していません。

11.3.1 異常な実行回数の検出

アクティビティモニターを開き、[最近のコストの高いクエリ] ペインを調べます。

並べ替え 実行回数/分 mを見るost 頻繁に実行されるクエリ。
上位のクエリでは 1 分あたり 37,000 回の実行が示されており、これは他のどのクエリよりもはるかに高い数値です。
右クリックして選択 クエリテキストの編集.

クエリは製品カテゴリ情報を取得します。

SELECT CategoryId, CategoryName 
FROM ProductCategories 
WHERE CategoryId = @CategoryId;

この単純なクエリは高速かつキャッシュ可能であるはずですが、1 分間に数万回も実行されています。

11.3.2 アプリケーションコードへのトレース

[プロセス] ペインで、次のクエリを実行しているセッションを見つけます。

注意してください用途列には「ProductCatalogService」と表示されます。
これらのセッションのいずれかを右クリックして選択 トレースプロセス SQL Server プロファイラー.
SQL プロファイラーは、クエリが異なる CategoryId 値で連続して繰り返し実行されていることを明らかにします。
コードレビューについては、ProductCatalogService を管理している開発チームにお問い合わせください。

コードレビューで問題が判明しました。最近の変更により、商品リストをカテゴリ付きで取得するようになりました。結果セット内の商品（多くの場合1,000点以上）ごとに、コードはカテゴリ情報を取得するために個別のデータベース呼び出しを実行しています。これは典型的なN+1クエリ問題です。

11.3.3 アプリケーションの最適化

適切な修正を実施します。

アプリケーションクエリを変更する JOIN を使用して、単一のデータベース呼び出しで製品とそのカテゴリを取得します。

SELECT p.ProductId, p.ProductName, c.CategoryId, c.CategoryName
FROM Products p
INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId
WHERE p.Active = 1;

更新されたコードをデプロイする アクティビティモニターを監視します。
修正を確認します。 カテゴリクエリの 1 分あたりの実行回数は 37,000 から 100 未満に減少し、全体的な CPU 使用率は 40% 減少します。
学んだ教訓を文書化する 開発チームと共有して、将来のコード変更で同様の問題が発生しないようにします。

12. 潜在的なデータベース破損を検出する

アクティビティモニターはデータベースの破損を検出するために特別に設計されているわけではありませんが、表示される特定のパターンから、さらに調査する必要がある根本的な破損の問題が示唆される場合があります。

12.1 潜在的なデータベース破損の症状

データベースの破損が存在し、アクセスされている場合、次のようなメッセージが表示されることがあります。

1. プロセスペインで:

異常な待機タイプにより、セッションが SUSPENDED 状態で停止する
エラー状態を示すプロセス
クエリが繰り返し失敗する

2. リソース待機ペインで次の操作を実行します。

ディスクの問題を示している可能性のある異常な I/O 関連の待機タイプ (ただし、これは論理的な破損ではなくハードウェアの問題を示している可能性が高い)

3. 最近の高価なクエリの場合:

破損したページを繰り返し読み取ろうとしている場合、異常に高い物理読み取りを伴うクエリ

12.2 DBCC CHECKDBによる追加チェック

アクティビティモニターに破損の可能性を示唆する症状が表示された場合は、直ちにDBCC CHECKDBを実行してデータベースの整合性を確認してください。このコマンドは、すべてのデータベースページをスキャンし、チェックサムを検証し、論理的な整合性エラーがないか確認します。

DBCC CHECKDBを使用してデータベースの破損をチェックして修復する方法の詳細については、包括的なDBCC CHECKDBガイド.

12.3 専門ツールによる修理

DBCC CHECKDB でデータベースの破損が確認された場合、修復にはいくつかのオプションがあります。

推奨される方法は、既知の正常なバックアップから復元することです。バックアップと復元の方法に関する包括的なガイド SQL Server データベースを追加しました.
軽度の破損の場合、REPAIR_REBUILD を使用した DBCC CHECKDB によって問題が解決される可能性があります。
最近のバックアップがない重要なデータベースの場合、専門家 SQLリカバリソフトウェアまた、これらのサービスを使用すると、組み込みの修復オプションでは回復できないデータを回復できる場合が多くあります。

13. 結論

SQL Server アクティビティモニターは、データベース管理者にとって非常に貴重なツールであり、サーバーのパフォーマンスを即座に把握し、問題を迅速かつ効果的に診断するのに役立ちます。

13.1 重要なポイントのまとめ

このガイドでは、アクティビティモニターがどのように理解し、トラブルシューティングするのに役立つかを説明しました。 SQL Server パフォーマンス：

アクティビティモニターは、整理されたグラフィカルインターフェイスを通じて、プロセス、待機、クエリ、および I/O をリアルタイムで可視化します。
「概要」、「プロセス」、「リソース待機」、「データファイル I/O」、「最近の高コストのクエリ」の 5 つのペインはそれぞれ、サーバーのアクティビティに関する独自の視点を提供します。
過剰なクエリ実行、ブロッキングチェーン、高い CPU 使用率などの一般的なトラブルシューティングシナリオは、体系的なアクティビティモニター調査によって管理可能になります。
アクティビティモニターは強力ですが、履歴データの不足、待機タイプのグループ化、監視オーバーヘッドなどの制限があり、アプリケーションに影響を及ぼします。cab性。
DMV クエリ、sp_WhoIsActive、拡張イベント、および場合によってはサードパーティ製のツールでアクティビティモニターを補足すると、包括的な監視戦略が作成されます。
更新間隔に関するベストプラクティスに従い、使用していないときにアクティビティモニターを閉じ、相関関係のために複数のペインを組み合わせると、影響は最小限に抑えられながら、その価値は最大化されます。

13.2 ツールキットの一部としてのアクティビティモニター

アクティビティモニターは、パフォーマンス調査の唯一のツールではなく、最初の対応ツールとして活用すべきです。その強みは、トラブルシューティングの最中に即座に可視化を提供し、データベースがボトルネックになっているかどうかを迅速に判断し、より詳細な調査が必要な特定の側面を特定できることです。

アクティビティモニターは、車のダッシュボードのようなものだと考えてください。何か異常があればすぐに知らせてくれ、大まかな問題箇所を特定するのに役立ちます。車のダッシュボードではチェックエンジンランプが点灯した理由を正確には教えてくれないのと同じように、アクティビティモニターは問題の根本原因を完全には明らかにせず、問題点を指摘してくれます。より深い分析には、追加のツールと専門知識が必要です。

Activity Monitorを、実行計画分析、待機統計の追跡、履歴監視ソリューション、パフォーマンスのベストプラクティスを含む、より広範なツールキットに統合します。適切なインデックス戦略、クエリ最適化手法、キャパシティプランニングと組み合わせて使用してください。

13.3 学習の旅を続ける

Activity Monitor をマスターすることは、効果的なデータベース管理者になるためのほんの一歩に過ぎません。以下の方法でスキルを磨き続けましょう。

実行計画を解釈し、非効率的な操作を特定することを学ぶ
理解する SQL Server 待機統計とその意味
インデックス設計と最適化技術の研究
探る SQL Serverのアーキテクチャとクエリの処理方法
体系的なトラブルシューティング手法の実践
詳細なトレースのための拡張イベントを使用したエクスペリエンスの構築
トランザクション分離レベルとそのパフォーマンスへの影響を理解する

アクティビティモニターによるパフォーマンス調査は、 SQL Server アプリケーションがデータベースとどのように連携するか、そしてその仕組みについて学びます。発見したことを文書化し、同僚と知識を共有し、ライブラリを構築しましょう。rar一般的な問題に対する解決策の y。

13.4 追加リソース

以下の貴重なリソースで知識を広げましょう:

アクティビティモニターを開く SQL Server 管理スタジオ (SSMS) : 公式 SQL Server アクティビティモニターを開く方法に関するドキュメント SQL Server 管理スタジオ (SSMS)。
活動モニター ：公式 SQL Server アクティビティモニターの使用方法に関するドキュメント。

14. よくある質問 (FAQ)

Q：とは SQL Server アクティビティモニター?

A: SQL Server アクティビティモニターは、 SQL Server 実行中のプロセスに関するリアルタイム情報を表示する管理スタジオ SQL Server インスタンスの状態と、それらがサーバーリソースに与える影響を把握できます。5つのペインで構成されるグラフィカルなダッシュボードでは、プロセッサ使用率、待機タスク、I/Oレート、アクティブセッション、高負荷なクエリなど、サーバーアクティビティのさまざまな側面が表示されます。

Q: SSMS でアクティビティモニターを開くにはどうすればよいですか?

A: アクティビティモニターを開くには、次の4つの方法があります: (1) SSMSツールバーのアクティビティモニターアイコンをクリックする、(2) SQL Server オブジェクトエクスプローラーでインスタンス名を選択し、 活動モニター、（３）押す Ctrlキー + 他の + A、または（4）SSMSを自動的に起動するように設定 ツール -> オプション -> 環境 -> Starタップ.

Q: アクティビティモニターを使用するにはどのような権限が必要ですか?

A: 必要なのは サーバーの状態を表示 閲覧許可ost アクティビティモニターの情報。データファイルI/Oパネルでは、次のいずれかも必要です。 データベース作成, 任意のデータベースを変更するまたは 任意の定義を表示 権限が必要です。これらの権限がない場合、アクティビティモニターは開いても空白のペインが表示されることがあります。

Q: アクティビティモニターが一時停止されたり、動作しないのはなぜですか?

A: アクティビティモニターが一時停止する原因として、権限の問題、SSMSのバージョンが古い、またはリモート接続が無効になっていることが挙げられます。解決するには、(1) SSMSの最新バージョンに更新する、(2) VIEW SERVER STATE権限があることを確認する、(3) リモート接続が有効になっていることを確認する、のいずれかを実行してください。 SQL Server 例えば、（4）RestarSSMS、（5）SQL認証の代わりにWindows認証で接続してみてください。cabそれら。

Q: アクティビティモニターと sp_WhoIsActive の違いは何ですか?

A: アクティビティモニターはSSMSに組み込まれたグラフィカルツールで、様々な監視項目を整理したペインを提供します。sp_WhoIsActiveはコミュニティが作成した無料のストアドプロシージャで、アクティビティモニターよりも詳細な待機タイプ、ブロックの詳細、カスタマイズオプションを含む詳細なセッション情報を単一の結果セットで返します。アクティビティモニターは視覚的な調査に適しており、sp_WhoIsActiveはスクリプトによる監視に優れており、より詳細な情報を提供します。

Q: アクティビティモニターはサーバーのパフォーマンスに影響しますか?

A: はい、アクティビティモニターは更新間隔ごとにシステムDMVを照会するため、測定可能なオーバーヘッドが発生します。更新間隔が低いほど影響は大きくなります。Microsoftは、10秒未満の更新間隔ではサーバーのパフォーマンスに影響が出る可能性があると警告しています。アクティビティモニターを頻繁に使用していないときは必ず閉じてください。また、高負荷の運用サーバーでは、更新間隔を30～60秒にすることを検討してください。

Q: T-SQL を使用してアクティビティモニターのデータを取得できますか?

A: はい。アクティビティモニターは、sys.dm_exec_requests、sys.dm_exec_sessions、sys.dm_os_wait_stats、sys.dm_exec_query_statsなどのシステム動的管理ビューをクエリします。T-SQLを使用してこれらのDMVを直接クエリし、同等の情報をプログラムで取得することで、カスタム監視スクリプトの作成とデータ収集の自動化が可能になります。

Q: デフォルトの更新間隔は何ですか?

A: デフォルトの更新間隔は10秒です。概要パネルの任意の場所を右クリックし、 更新間隔定義済みのオプション（1秒、5秒、10秒、30秒、1分、1時間）から選択できます。間隔を短くすると、よりリアルタイムなビューが得られますが、監視のオーバーヘッドが増加します。

Q: SSMS でアクティビティモニターを自動的に開くにはどうすればいいですか?tarタップ？

A: SSMSオプションで自動起動を構成するには、次の場所に移動します。 ツール -> オプション -> 環境 -> Starタップ、その後、選択し オブジェクトエクスプローラーとアクティビティモニターを開く sでtarタップ ドロップダウン。SSMS でサーバーに接続するたびに、アクティビティモニターが自動的に開きます。

Q: アクティビティモニターの制限は何ですか?

A: 主な制限事項は次のとおりです。(1) 履歴データの保存や傾向分析機能がない、(2) 待機タイプが具体的に表示されるのではなく、カテゴリにグループ化されている、(3) CXPACKETなどの一部の待機タイプが表示されない、(4) ポイントインタイムスナップショットで一時的な問題が見逃される可能性がある、(5) 監視のオーバーヘッドがビジー状態のサーバーに影響を与える可能性がある、(6) プロアクティブな監視のためのアラートメカニズムがない、(7) 複数のサーバー間でデータを集約できない SQL Server インスタンス。これらのニーズには、アクティビティモニターを拡張イベント、データ収集セット、またはサードパーティの監視ツールで補完します。

著者について

袁勝 10年以上の経験を持つ上級データベース管理者（DBA）です。 SQL Server 環境およびエンタープライズデータベース管理に精通しており、金融サービス、医療、製造業など、様々な組織において数百件のデータベース復旧シナリオを解決してきました。

ユアンの専門は SQL Server データベースの復旧、高可用性ソリューション、パフォーマンス最適化など、幅広い実務経験を有しています。マルチテラバイト規模のデータベース管理、Always On可用性グループの実装、ミッションクリティカルなビジネスシステム向けの自動バックアップおよびリカバリ戦略の開発など、幅広い実務経験を有しています。

Yuanは、技術的な専門知識と実践的なアプローチを通じて、データベース管理者やITプロフェッショナルが複雑な問題を解決するのに役立つ包括的なガイドの作成に重点を置いています。 SQL Server 効率的に課題に取り組みます。常に最新の SQL Server リリースと Microsoft の進化するデータベーステクノロジを活用し、定期的にリカバリシナリオをテストして、推奨事項が実際のベストプラクティスを反映していることを確認します。

について質問があります SQL Server 回復または追加のデータベーストラブルシューティングガイダンスが必要ですか？Yuanは歓迎しますフィードバックと提案これらの技術リソースを改善するためです。