SQL Server のアクティビティを簡単に監視します。 誰がアクティブですか? SQL Server アクティビティ モニターの使用 ms SQL サーバーのパフォーマンスの監視

これは、SQL Server と連携して動作し、サーバーのパフォーマンスに関するさまざまな情報をグラフィック形式で提供する Sybase のソフトウェア製品です。 この情報は、パフォーマンス低下の理由を分析するのに非常に役立ちます。

バージョン 11.0.1 には、新しいバージョンを以前のすべてのバージョンと大きく区別する多くの新しい重要な機能があります。 11.0.1 は、4.9.2 から System 11 までの SQL Server のどのバージョンでも動作します。

ただし、データベース オブジェクトの使用パターンやサーバーとネットワークの相互作用に関する最も興味深い種類の情報の一部は、SQL Server システム 10 およびシステム 11 を監視する場合にのみ提供されます。当然のことながら、名前付きキャッシュ バッファーのパフォーマンスに関するデータは、 SQL Server System 11 のパフォーマンスを監視する場合にのみ提供されます。

以前のバージョンとの互換性を確保するために、11.0.1 では、サーバーのパフォーマンスに関する統計情報をファイルに出力し、その後の比較や分析に使用できるモードもサポートしています。 この機能は実際には非常に便利ですが、使用するとインストール プロセスが複雑になります。

は 2 つのコンポーネントで構成されています。1 つは SQL Server と同じマシン上で実行され、サーバーの共有メモリ領域へのアクセスを提供するサーバー モジュール、もう 1 つは任意のコンピュータ上で実行できるクライアント モジュールです。 クライアント モジュールの主なタスクは、サーバー モジュールによって蓄積された情報を読み取り、それをグラフィック形式でユーザーに提示することです。

このコマンドはサーバーの速度を大幅に低下させるため、起動時に dbcc memusage コマンドによって実行されるサーバー メモリ チェックをキャンセルする必要があります。 これを行うには、sqlmon (クライアント モジュール) を開始するときに、パラメーター nomem を指定する必要があります。

デフォルト設定では、1 つのサーバー モジュールに最大 5 つのクライアント モジュールを同時に接続できます。 つまり、1 つのサーバー モジュールは、各クライアントに 1 つのウィンドウを持つ 5 つのクライアント モジュールに接続することも、5 つのウィンドウが開いている 1 つのクライアントに接続することもできます。

同時に開くクライアント ウィンドウの最大数は、サーバー モジュールの起動時に設定されます。

したがって、サーバー モジュールを起動するためのコマンド ファイルで 20 のウィンドウをサポートするには、パラメーター p2 0 を指定する必要があります。この場合、サーバーの共有メモリ領域の先頭のアドレスを、 buildmaster コマンドとその他のアクション。 これらのアクションは、SQL Server の実行中は決して実行しないでください。 (サポートされる同時クライアント数を拡張するプロセスの詳細については、Server Supplement マニュアルを参照してください。)

にはいくつかの欠点があります。 たとえば、進行中の I/O 操作の数やサーバー デバイスのその他のパフォーマンス特性を示す棒グラフでは、一度に限られた数のデバイスのデータしかレポートできません。

これは、多数のサーバー機器を備えた大規模なサーバーを監視する場合に不便です。 さらに、ユーザーは、チャートに情報が含まれるデバイスを選択したり、異なるデバイスのセットを切り替えたりすることはできません。

図と同時に画面に表示されるテキスト テーブルには、すべてのサーバー デバイスのリストが含まれていますが、各デバイスの I/O 操作の合計数のみが含まれています。 これは、パフォーマンスを向上させるためにユーザー データベース セグメントをサポートする多数のサーバー デバイスを備えた大規模サーバーを操作する場合に特に困難です。 この場合、既存のすべてのセグメントの動作を分析することは不可能です。

また、パフォーマンス指標の変化のダイナミクスを長時間画面に表示することもできません。

60 回の連続したパフォーマンス測定間隔のデータを表示できます。 各間隔の選択された期間に応じて、このような統計はかなり長い期間をカバーできます。 ただし、この手法では現在のデータを 1 か月または 1 年前の指標と比較することはできません。

もちろん、プログラム ウィンドウのイメージをプリンタに出力することはできますが、その場合は、サーバーの将来のパフォーマンスを評価するために、一連のファイルや大量の印刷物を保存する必要があります。 実際には、サーバー管理者は、実際のサーバーのパフォーマンスを把握するために、企業のビジネス サイクルのさまざまな時期に収集されたデータや、連続するビジネス サイクルの同様の期間にわたる相互参照情報を再調査する必要があることがよくあります。

起動によりサーバーの速度が若干低下するため、測定を開始する前に、特定のハードウェアおよびソフトウェア プラットフォームでのこの速度の低下の大きさを判断する必要があります。 測定するための良い方法は、テスト トランザクションの標準セットを実行することです。

これは、サーバー マシン上に存在する場合と存在しない場合の両方で使用できます。 クライアント モジュールがない場合でも、プログラムのサーバー モジュールは動作し続けるため、別のコマンドで停止する必要があります。

を使用すると、サーバーの機能の特定の側面に関する情報を含む複数の異なるグラフィック ウィンドウを表示できます。

メインウィンドウ
これには、プログラムでサポートされているウィンドウのリストが含まれています。 クライアント モジュールである sglmon を起動するときにパラメータ nomem が指定されていない場合、このウィンドウにはサーバー マシンのメモリ使用量の円グラフも表示されます。

キャッシュバッファ (キャッシュ)
このウィンドウには、プロシージャおよびデータ キャッシュ バッファの動作を特徴付けるグラフが表示されます。 データ キャッシュ バッファー内の物理 I/O 操作と論理 I/O 操作の数を制御することにより、ユーザーはサーバーがバッファー内の既存のページを使用して実行するデータ ページ アクセスの量を決定できます。 データ バッファーとプロシージャ バッファーについて取得されたこれらの統計により、サーバーのキャッシュ バッファーに必要なメモリの合計量と、データ キャッシュ バッファーとプロシージャ キャッシュ バッファーの比率を判断できます。

データ バッファ キャッシュ、SQL Server System 11 のみ (データ キャッシュ)
このウィンドウには、サーバー上に構成されている名前付きキャッシュ バッファーごとの物理および論理 I/O 操作の数が報告されます。

ディスクI/O
ここには、ディスク アクセスの現在および合計数のグラフと概要表が表示されます。 これらは、既存のサーバー デバイス間の I/O 負荷分散を最適化するのに役立ちます。 出力情報を分析するときは、物理ディスクの対応するセクションの名前に基づいてサーバー デバイスの名前を選択するための標準スキームを使用すると便利です。これは、サーバー デバイスとの交換レートを監視しながら、どのディスク コントローラーがどのディスク コントローラーであるかを知る必要があるためです。これらの各デバイスはに接続されています。

ネットワークの操作 (SQL Server システム 10 および 11 のみ) (ネットワーク アクティビティ)
このウィンドウには、ネットワークの入出力に関する統計情報 (パケット サイズ、トラフィック量など) がレポートされます。

オブジェクトへのアクセスのブロック (SQL Server システム 10 および 11 のみ) (オブジェクト ロック ステータス)
これには、使用されているロックの種類の詳細な内訳、ロックを保持しているプロセスの名前など、データ テーブルのアクセス ロックに関する情報が表示されます。

オブジェクト ページ I/O、SQL Server システム 10 および 11 のみ (オブジェクト ページ I/O)
このウィンドウには、サーバー データ テーブルの 1 つの I/O ページの強度に関する情報が含まれています。 最も一般的に使用されるサーバー テーブルのリストをコンパイルするときは、効率に注意してください。 このタイプの情報は、sp_sysmon によって返されません。

パフォーマンスの概要
これにより、SQL Server のパフォーマンスの全体像 (使用されている CPU 時間の割合、1 秒あたりに処理されるトランザクション数、ネットワーク トラフィックの量、ディスク I/O、ロックの使用状況) がわかります。

パフォーマンスの傾向
このウィンドウには、「パフォーマンス概要」ウィンドウに表示されるサーバーのパフォーマンス指標と時間の連続グラフがプロットされます。

サーバープロセスアクティビティ（Process Activit）
このウィンドウでは、1 つ以上のサーバー プロセスを選択し、各プロセスの CPU 使用率と I/O ボリュームを監視できます。

プロセスの詳細
ウィンドウには、選択したサーバー プロセスに関する詳細情報が表示されます。

プロセス一覧
ウィンドウには、現在使用可能なすべてのサーバー プロセスのリストとそのステータスが表示されます。 sp_who サーバー コマンドの発行と非常によく似ています。

プロセスロックアクティビティの使用
このウィンドウには、選択したサーバー プロセスによるロックの使用に関する情報が表示されます。

ストアド プロシージャ アクティビティの使用
このウィンドウには、ストアド プロシージャの実行と各プロシージャの実行時間に関する情報が含まれています。

トランザクションアクティビティ
ウィンドウには、処理中のトランザクション数をさまざまなトランザクション タイプごとに示す棒グラフが表示されます。 たとえば、Update in place メカニズムを使用してトランザクションのどの部分を完了できるかを確認できます。

2006/12/26 ケビン・クライン

DBA が尋ねたい最後の質問は何ですか? おそらく、アプリケーションの劣化に関するユーザーからのメッセージ、またはデータベースに何が起こったのかについての質問です。 私たちはすべてを横に置き、これがいつまで続くのかを考えながら「緊急モード」に入らなければなりません。 データベース管理者の主な責任の 1 つは産業用データベースの高品質な機能を保証することなので、残っているのは誤動作をできるだけ早く取り除くことだけです。 原則として、失敗の原因を突き止める時間はありません。

急ぎの仕事はもう必要ありません - 体系的な観察だけです

しかし、これしかできることはないのでしょうか？ システムのベースライン、ベンチマーク、継続的な監視を使用するシンプルな管理手順である、プロアクティブなパフォーマンス監視を実行する機能があります。 この記事では、プロアクティブな監視の使用方法と、Windows システム モニターを使用して無料の監視システムを作成する方法について説明します。

プロアクティブな監視

プロアクティブなパフォーマンス監視は、問題が重大になる前に解決するのに役立つシンプルなシステムです。 おそらくすでに例外監視を使用している人もいるでしょう。例外監視では、異常を認識するだけで、詳細な情報や問題を防ぐ機能は提供しない自動プロセスを作成します。 一方、プロアクティブなパフォーマンス監視は、短期および長期の両方で、作業環境とアプリケーションに関するあらゆる種類の情報をユーザーに提供します。 データベースのパフォーマンス カウンターが取得され、ベンチマーク メトリックが確立され、アクティブな監視が維持されます。

名前が示すように、プロアクティブなパフォーマンス監視にはアクションが必要です。 インストールには少し時間がかかり、データベースとアプリケーションがどのように動作するかを理解するのにも時間がかかります。 プロアクティブなパフォーマンス監視を効果的に行うには、収集された豊富なデータを活用できるようにメッセージを確認する必要があります。

基本パラメータ、標準、モニタ

いくつかの用語を定義することから始めましょう。 基本パラメータ（ベースライン）通常の状態でのサーバーとアプリケーションの動作を反映するパラメーターのセットです。 基本パラメータは、同じ条件下で複数の測定を行った結果に基づいて平均値として取得されました。 それらは比較のためのベンチマークです。

基準は、特定のサーバー負荷レベルでのシステムのパフォーマンスを示します。これにより、このレベルでの産業用サーバーのパフォーマンスを比較し、サーバーのパフォーマンスが通常よりどの程度高いか低いかを判断できます (つまり、サーバーのパフォーマンスが低下しています)。 基本パラメータと同様に、基準値は制御された環境で取得され、主要な値は事前定義された指標に関連して決定されます。 サーバーとアプリケーションが複数のレベルまたは種類の負荷でどのように動作するかを確認する必要がある場合は、通常、(基本パラメータに関連して) いくつかの参照値を取得します。

監視- これは、事前定義された条件 (さらなる調査または警告のために定義された一連の条件) の下で、サーバーをリアルタイムで計画的に監視することです。 たとえば、重要なビジネス アプリケーションが正常に実行されるまでにかかる時間、バックアップにかかる時間、または特定のパフォーマンス マイルストーンに達した時期を知りたい場合は、それらの特定のイベントが監視されます。

次に、プロアクティブな監視に移りましょう。 サードパーティ製品を使用することも、System Monitor を使用する無料のソリューションを使用することもできます。 サードパーティのソリューションは、プロアクティブな監視を設定するプロセスを簡素化し、無料の組み込みソリューションが提供するものとは異なる機能を備えている場合があります。 ただし、始める前に、System Monitor を使用してプロアクティブな監視を開始する方法を説明します。

ステップ 1: パフォーマンスのベースラインを定義します。

プロアクティブ監視モードを確保する最初のステップでは、データベース サーバーの動作のための基本パラメータのセットが確立されます。 この集計は、通常の条件下でのサーバーのパフォーマンスを示し、重要なバックグラウンド プロセスをすべて文書化して理解するのに役立ちます。また、今後無視できるように介入が必要ない状況を特定するのにも役立ちます。 つまり、データベース管理者は、システム メッセージを無視するオプションを定義できます。そうしないと、大量の誤った通知が生成されてしまいます。

動作の品質を明確に示すために、最良のベースラインではいくつかのグラフ (理想的には 1 つ) が使用され、サーバーのパフォーマンスが一目でわかるようになります。 基本パラメータを決定したら、次のことを行う必要があります。 まず、パフォーマンス データをシステム ログに保存するか、リアルタイムで表示するかを選択します。 両方を持つことが理想的です。ログを使用すると、いつでも測定値を振り返って、システムを直接監視していないときにパフォーマンスがどのようなものであったかを分析できます。 リアルタイム監視はディスク容量やサーバーリソースを消費しませんが、システムに 100% の注意を払う必要があります。 次に、データ収集とデータ I/O 操作のパフォーマンス コストを考慮して監視を実行する間隔を決定し、必要な領域のコストを見積もる必要があります。 間隔が長くなるほど、目的のパフォーマンスデータが取得できない可能性が高くなります。 最後に、ローカル監視またはリモート監視を選択します。 監視プロセスが監視対象サーバーを使用するローカル監視では、サーバーに CPU とディスクのオーバーヘッドが追加されます。 別のサーバーを使用するリモート監視では、これらの問題を解決できますが、ネットワーク上の負荷が大幅に増加します。

ベースラインを決定するために使用することをお勧めするシステム モニターのメトリックまたはカウンターをリストします。 特定のアプリケーションのコンテキストにおける「正しい」値はシステムごとに異なるため、何とも言えません。 さまざまなベースラインの平均を使用して通常のベースライン パフォーマンスを設定し、これが使用されているシステムにとって正しいオプションであることを示します。

システムモニターを使用した基本設定の定義

ここで、基本的なパラメータを収集するために、システム モニターを呼び出してみましょう。 [コントロール パネル]、[管理ツール]、[パフォーマンス] を開いてみましょう。 左側のペインで「パフォーマンス ログとアラート」をダブルクリックします。 [カウンター ログ] を右クリックし、[新しいログ設定] を選択しましょう。 グラフの名前を入力し、「OK」をクリックします。 [カウンターの選択] ダイアログ ボックスで、最初のカウンターを選択し、[追加] をクリックします。 すべてのカウンタを追加するまでこれらの手順を繰り返し、[閉じる] をクリックします。

まず、デフォルトの 15 秒間隔を試してください。 または、[プロパティ] をクリックして (またはキーボード ショートカット Ctrl + Q を使用して) 別の間隔を選択し、[自動的にサンプル] というラベルの値を入力します: _ 秒。 間隔が長いほど使用するスペースは少なくなりますが、提供されるデータの詳細は低くなります。

「ログ ファイル」テーブルを選択し、データを保存する場所を決定します。 データは、[ログ ファイル データの表示] ビューを使用して後で表示できます。 システム モニターは、ベースライン パフォーマンス データを収集すると、図 1 のようになります。 多数のメーターを同時に監視することで多くのデータを収集できることがわかりますので、本線用のメーターは慎重に選択する必要があります。

ステップ 2: 基準値の設定

サーバーのパフォーマンスのベースラインが確立されたら、ベンチマークの設定を開始できます。これにより、事前に定義されたいくつかの状況で実行するときのサーバーのパフォーマンスを理解しやすくなります。

標準の場合、基本パラメータの決定と同じ監視モードが使用されます。 独自のソリューション、または TPC-C や SAP などの一般的な業界ツールの 1 つを使用できますが、ベンチマーク値を計算するための最良の結果は、特定のデータベース サーバーとそのアプリケーションを使用するように構成された共通のカスタム スクリプトを開発することによって得られます。 。

T-SQL スクリプト スイート、osql ユーティリティ、クエリ アナライザー、SQL プロファイラー、システム モニターを使用して、独自のスクリプトを作成できます。 T-SQL での負荷テスト スクリプトの開発には通常、数日かかります。 負荷テストの実行データを収集し、結果のデータを分析するにはさらに時間がかかる場合があります。

事前定義されたワークロードの下でサーバーのパフォーマンスのベースラインを確立したら、システムに何を期待するかを知ることができます。 基準値を取得する際に収集されたデータは、日常的な監視の基礎を形成するために使用されます。 たとえば、サーバーは、速度が低下し始める前に、1 秒あたり最大 249 件のトランザクションを配信できることが判明しました。 この場合、サーバーが約 200 TPS に達すると低優先度の通知を設定し、サーバーが 235 TPS に達すると高優先度の通知を設定できます。 この方法により、管理者はサーバーに問題がある可能性を発見し、ユーザーが気付く前に必要な措置を講じることができます。 そして危機的な状況もありません。 それが可能になりました。

ステップ 3: スケジュールされた監視

おそらく、プロアクティブな監視体制の最も重要な要素は、計画された監視です。 これがなければ、データベースのパフォーマンスを監視したり、パフォーマンスの問題を検出したりすることはできません。

SQL Server エージェントとシステム モニターを組み合わせて使用​​すると、安価な SQL Server 監視ツールを作成できます。 SQL Server エージェントを使用すると、モニターに表示されるエラーの原因となったイベントを特定し、イベントに関する通知を受信するユーザーを特定し、エラー イベントの発生時に通知を自動的に送信することができます。

SQL Server エージェントのインストールは時間がかかり、複雑になる場合があるため、詳細については「SQL Server のアラート」セクションを参照する必要があります。 オンライン書籍 (BOL)。 SQL Server エージェントは通常、データベース サーバーのエラー メッセージを監視し、実行は監視しません。

サーバーのパフォーマンスを監視するには、システム モニターを使用して現在のカウンターを監視します (ポーリング頻度を 15 分以内に設定します)。

メモリページ/秒

ネットワーク インターフェイス - 合計バイト数/秒

物理ディスク間の転送数/秒

プロセッサ - プロセッサ時間の割合

SQLServer:アクセス方法 - フルスキャン/秒

SQLServer:バッファ マネージャ - バッファ キャッシュ ヒット率

SQLServer:データベース アプリケーション データベース - トランザクション数/秒

SQLServer:一般統計 - ユーザー接続

SQLServer:ラッチ - 平均ラッチ待機時間

SQLServer:ロック - 平均待機時間

SQLServer:ロック - ロック タイムアウト/秒

SQLServer:Locks - デッドロック数/秒

SQLServer:メモリ マネージャー - 保留中のメモリ許可

各カウンタの値をベースライン値とテストで示された基準値の間に設定します。 たとえば、メーターが最高負荷値の 75% に達したときに通知を設定し、90% を超えたときに警告メッセージを設定することができます。

アラートを実行するには、SQL Server アラートと通知、システム モニターなどの無料ツールを使用するか、Microsoft Operations Manager (MOM) またはその他のツールを購入できます。 少なくとも次の状況に対してアラートを設定することをお勧めします。

  • 操作に影響するエラー、特に重大度スコアが 19 ～ 25 のエラー
  • ブロッキング
  • CPU使用率
  • ディスクの使用状況
  • スキャン (SQLServer:アクセス方法)

アラームを送信して、電子メール、ポケベル、またはネットワーク経由で管理者に通知できます。 次のメッセージ ソースに対して自動アラートを設定できます。

  • SQLサーバーのログ
  • SQLエージェントのログ
  • Windows アプリケーション ログ、セキュリティ、およびシステム
  • SQL Serverジョブ実行ログ

最後に、独自のアプリケーションがエラーを正しく記録し、他の開発アプリケーションからのエラー メッセージに応答することを確認する必要があります。

SQL Server のパフォーマンスをプロアクティブに監視するということは、サーバーとアプリケーションの両方のベースライン パフォーマンス パラメーターを確立することを意味します。 使用中の事前定義されたシナリオに従ってサーバーの動作をシミュレートするベンチマークを設定し、スケジュールされた監視を実行して、理想的には問題が検出されたときにアラートをトリガーします。 無料ツールや組み込みツールを使用する場合でも、サードパーティのソリューションを選択する場合でも、制御を行うことで、SQL Server 上でアプリケーションがどのように実行されているかについて必要な情報を必要なときに確実に取得できます。

表 1. 基本パラメーターを決定するためのシステム モニターのオブジェクトとカウンター
オブジェクトとカウンター 説明
メモリページ/秒1 秒あたりのディスクへの読み取りまたは書き込みのページ数。 このカウンタは、システムの遅延やパフォーマンスの問題によって引き起こされるエラーの種類を示す主な指標です。
ネットワーク インターフェイス - 合計バイト数/秒1 秒あたりにネットワーク インターフェイスを通過するバイト数。 このカウンタが減少するか、この傾向になる場合は、ネットワークの問題がアプリケーションに影響を与えている可能性があることを示しています。
PhysicalDisk-ディスク転送数/秒ディスクの読み取り/書き込み操作の見積もり。 サーバー上の各物理ディスクにカウンターを設定する
プロセッサ - プロセッサ時間の割合プロセッサがワーカー スレッドの実行に費やす時間の割合。 このカウンターは、プロセッサーのアクティビティーの主な指標として機能します。 SQL Server 上で実行されているすべてのプロセッサの使用率が 100% を示している場合、エンド ユーザーのクエリは無視されている可能性があります。
SQLServer:アクセス方法 - フルスキャン/秒1 秒あたり無制限のテーブルまたはインデックスのスキャン。 ビューはリソース不足やキャッシュの問題を引き起こすことが多いため、このカウンタを下げることは良いことです。
SQLServer:バッファ マネージャ - バッファ キャッシュ ヒット率ディスク読み取りを必要としなかったページの割合。 数値が大きいほど、実行されるディスク I/O が少なくなります。 適切に調整されたシステムでは、この値は 80 以上になるはずです。
SQLServer:データベース - ログの増加特定のデータベースのトランザクション ファイルはどのくらい増加しましたか? 適切に調整されたシステムでは、このカウンターは低くなり、おそらく数日ごとに 1 未満になるはずです。
SQLServer:データベース アプリケーション データベース - 使用されたログの割合ログ ファイル内の空き領域の割合。 このカウンタは計画どおりに変化しますが、100 に達しないようにする必要があります。
SQLServer:データベース アプリケーション データベース - トランザクション数/秒データベース内で確認されたトランザクションの数。 このカウンタは標準から省略される場合があります。 トランザクションがキューイングを開始するタイミングを監視します。これは、ディスク I/O が遅い可能性があることを示しています。
SQLServer:ラッチ - 平均ラッチ待機時間リクエストが満たされるまでの平均時間。 サーバーでリソース、特にメモリや I/O の競合が発生している場合、このカウンタ値が高くなる可能性があります。
SQLServer:ロック - 平均待機時間、ロック待機数/秒、デッドロック数/秒一時ロックは SQL Server リソースを保持します。 これらのロック関連のカウンターの上昇傾向に注意してください。これは、パフォーマンス上の問題の可能性を示しています。
SQLServer:一般統計 - ユーザー接続データベースサーバーへのユーザー接続の数。 このカウンターの値に目立った変化がないか確認してください。 ネットワークの問題や負荷と速度の低下を示している可能性があります。
SQLServer:メモリ マネージャー - 保留中のメモリ許可メモリ空間の割り当てを待機しているプロセスの現在の数。 値が高い、または増加している場合は、メモリ容量が不足していることを示している可能性があります
SQLServer:User Settable-Query (トレーサ クエリ)特殊なカウンター。クエリ インデックスとも呼ばれます。 このカウンターは、システムの全体的な速度または効率を示すユーザー生成のクエリです。 この値を設定するには、アプリケーションは sp_user_counter1 を呼び出し、数値を返します。


データベース管理者なら誰でも、すべての動作が遅い、またはまったく動作しないという事実に対処しなければならなかったことがあるのではないでしょうか。 まず最初に知る必要があるのは、現時点で SQL Server で実際に何が起こっているのかということです。 管理者は便利なものをたくさん持っているようです。間抜けなアクティビティ モニター、多数の動的管理ビュー (dmv)、SQL Server 7 や SQL Server 2000 の時代から継承したストアド プロシージャ sp_who および sp_who2 などです。
でも、考えてみましょう...

監視ツール

アクティビティモニター

それは素晴らしいことのように思えるかもしれません。アクティビティを監視するという、まさに必要なことを実行します。 重いアカウンティング レポートを起動し、アクティビティ モニターに何が表示されるかを確認します。
スクリーンショットは、SQL Server 2005 のアクティビティ モニターを示しています。

SQL Server Denali (2012) CTP 3 より。


うーん。 十数人がそのようなレポートを実行したらどうなるでしょうか? そして、これは珍しいことではありません...もちろん、進歩は明らかですが、それを理解するのは非常に不便です。 デナリのアクティビティ モニターでは、さらに役立つ情報 (たとえば、どの特定のリソースで待機が発生しているかなど) が表示されるほか、たとえば、必要なセッションのプロファイラーをモニターから直接起動し、すでにプロファイラーで追跡することもできます。 、しかし、なんと、追加で負荷がかかり、すでに過負荷になっているサーバーが追加されます。 さらに、ブレーキにすでに問題があり、プロファイラーの起動時にすでに実行が開始されていたリクエストは表示されません。
そして、これはまさに私が見たいものです - 誰が今何をしているのか。

sp_who と sp_who2

スクリーンショットは、同じ不運なレポートの作成中に実行された sp_who (上) と sp_who2 (下) の実行結果を示しています。


うん。 とても有益です。 sp_who を見ると、何かが実行されていることがわかります。 もちろん実行されます。それが私たちが注目する理由ですが、ある種の SELECT が実行されていることがわかります。 または複数の SELECT。
sp_who2 には詳細情報が表示されます。 これで、セッションで費やされたプロセッサ時間 (おそらく、列内の合計時間を合計)、I/O 操作の数、これらすべてが実行されたデータベースの名前、および実行者がわかります。セッションはブロックされています (ブロックされている場合)。
ご覧のとおり、アクティビティ モニターはさらに多くの情報を提供します。

DMV

SQL Server 2005 以降、サーバーの状態に関する情報を取得する新しい機能である動的管理ビューが追加されました。 MSDN には次のように記載されています。「動的管理ビューと関数は、サーバー インスタンスの健全性の監視、問題の診断、パフォーマンスの調整に使用できるサーバーの健全性データを返します。」
実際、SQL Server 2005 には、現時点でのクエリの実行に関連する一連のビューがあります (ただし、「履歴」を表示するためのビューもあります): ここにあり、その数はバージョンごとに増加し続けています。
確かに、経験豊富な管理者は、サーバーの現在の状態に関する情報を取得するためのスクリプトを大量に用意していますが、DMV の操作経験がまだなく、すでに問題が発生している場合はどうすればよいでしょうか?

sp_WhoIsActive

Adam Machanic (SQL Server MVP および MCITP) は、同じ DMV に依存し、非常に使いやすい sp_WhoIsActive ストアド プロシージャを開発し、継続的に改良しています。 sp_WhoIsActive の最新バージョンをダウンロードできます。 Adam 自身が sp_WhoIsActive に特化した一連の記事を持っており、30 (30!) もの記事で構成されています。それを読むこともできますが、私はこの資料を読むことに興味を持っていただけるように努めます :)。
したがって、このスクリプトをテスト サーバーの 1 つ (2005 からデナリまでの任意のバージョン) にダウンロードして実行したと仮定します。 Adam は、任意のデータベースのコンテキストで呼び出せるように、マスター システム データベースに保存することをお勧めしますが、これは必須ではありません。別のデータベースのコンテキストで呼び出す場合は、名前を完全に記述する必要があります - DB .schema.sp_whoIsActive。
それでは、試してみましょう。 スクリーンショットは、同じレポートの作成中に実行された結果を示しています。

exec sp_whoIsActive クエリの結果は、残念ながら 1 つの画面に収まらないため、パラメータなしで呼び出されたストアド プロシージャの出力をテキストで説明します。

  • - アクティブなリクエストの場合は実行時間を示し、「スリープ」セッションの場合は「スリープ」時間を示します。
  • - 実際には、スピッド。
  • - 現在実行中のリクエストのテキスト、またはセッションがスリープ中の場合は最後に完了したリクエストのテキストを表示します。
  • - まあ、わかります。
  • - 非常に興味深いコラムです。 (Ax:Bms/Cms/Dms)Eの形式で出力されます。 A はリソース E で待機しているタスクの数です。B/C/D はミリ秒単位の待機時間です。 リソースの解放を待っているセッションが 1 つだけの場合 (スクリーンショットのように)、その待ち時間が表示されます。セッションが 2 つある場合は、その待ち時間が B/C 形式で表示されます。 3 つ以上が待機している場合は、このリソースの最小、平均、最大待機時間が B/C/D 形式で表示されます。
  • - アクティブなリクエストの場合 - このリクエストによって費やされた合計 CPU 時間、スリープ セッションの場合 - このセッションの「全期間」の合計 CPU 時間。
  • - アクティブなクエリの場合、これはクエリ実行中の TempDB への書き込み操作の数です。 スリープ セッションの場合 - セッションの存続期間全体にわたる TempDB 内のレコードの総数。
  • - アクティブなリクエストの場合 - このリクエストに割り当てられた TempDB 内のページ数。 スリープ セッションの場合 - セッションの全存続期間中に割り当てられた TempDB 内のページの合計数。
  • - 突然誰かにブロックされた場合、ブロックした人の spid (session_id) が表示されます。
  • - アクティブなリクエストの場合 - このリクエストの実行時に実行された論理読み取りの数。 スリープセッションの場合 - このセッションの全期間中に読み取られたページ数。
  • - すべて同じですが、記録についてです。
  • - アクティブなリクエストの場合 - このリクエストの実行時に実行された物理読み取りの数。 睡眠セッションの場合 - 伝統的に、セッションの全期間にわたる物理的な測定値の合計数。
  • - アクティブなリクエストの場合 - このリクエストの実行時に使用される 8 キロバイトのページ数。 スリープ セッションの場合 - 存続期間全体で割り当てられた合計メモリ ページ数。
  • - セッションステータス - 実行中、スリープ中など。
  • - このセッションによってオープンされたトランザクションの数を示します。
  • - 可能であれば、操作の進行状況を表示します (バックアップ、復元など)。 SELECT が何パーセント完了したかは決して表示されません.

の残りの列 標準出力 sp_WhoIsActive にはあまり興味がないので説明しません。その目的は誰にとっても明らかだと思います (host_name、database_name、program_name、start_time、login_time、request_id、collection_time)。

そして何？ これで全部ですか？

いいえ、それだけではありません。 また、sp_WhoIsActive を呼び出すことができるパラメータ (私の観点から見て、最も興味深く便利なパラメータ) と、それによって何が起こるかについても説明します。

  • @help は非常に便利なオプションです。 sp_whoIsActive @help = 1 を呼び出すと、すべてのパラメータに関する情報と画面上の出力列が取得されます。 不明な点がある場合は、いつでも「ヘルプ」を参照してください。
  • @filter_type と @filter - 実行結果をフィルタリングできます。 @filter_type は、「セッション」、「プログラム」、「データベース」、「ログイン」、および「ホスト」の値を取ることができます。 @filter パラメータでは、選択したタイプのどのオブジェクトに興味があるかを示します。 たとえば、master データベースで実行されているすべてのセッションを確認したい場合は、 exec sp_whoIsActive @filter_type = "database", @filter = "master" を呼び出します。 @filter パラメータでは「%」を使用できます。
  • @not_filter_type と @not_filter - 「逆の」フィルタリングを可能にします。 つまり、たとえば、「database」フィールドに「master」が含まれるセッション以外のすべてを表示したいとします。このためには、 exec sp_WhoIsActive @not_filter_type = “database”, @not_filter = “master” を実行します。 そうですね、または、ユーザー sa を除くすべてのユーザーが何をしているかを確認したいと考えています... 多くのアプリケーションが考えられます。 @not_filter パラメータでは「%」の使用が許可されます。
  • @show_system_spids = 1 - システムセッションに関する情報を表示します。
  • @get_full_inner_text = 1 - sql_text フィールドには、バッチ (バッチ) 内の現在のリクエスト (ステートメント) のテキストだけでなく、バ​​ッチ全体のテキストも含まれます。
  • @get_plans - クエリ実行プランを含む列を出力に追加します。
  • @get_transaction_info = 1 - トランザクション ログ内のエントリの数とボリューム、および最後のトランザクションの開始時刻を出力に追加します。
  • @get_locks = 1 - リクエストの実行中に適用されるすべてのロックに関する情報を出力に追加します。
  • @find_block_leaders = 1 - ブロックのチェーンを追跡し、現在のセッションがブロックを削除するのを待機しているセッションの総数を表示します。
  • @output_column_list = "[%]" - sp_whoIsActive 出力に tempDB 情報を表示したくない場合はどうすればよいですか? このオプションを使用すると、出力内容を制御できます。
  • @destination_table = "table_name" - 実行結果をテーブルに挿入しようとしますが、このテーブルが存在するかどうか、およびテーブルに挿入するための十分な権限があるかどうかはチェックしません。

これですべてです

その結果、SQL Server 上の現在のアクティビティを監視するための、非常に便利で柔軟なツールがもう 1 つ誕生しました。 通常の操作では、VIEW SERVER STATE 権限と dmv にアクセスする権限があれば十分です。
サーバーが経由でのみ接続できる場合にも追加する価値があります。

パフォーマンス監査チェックリスト

結果を上の表に入力します。

パフォーマンス モニターを使用して SQL Server ハードウェアのボトルネックを特定する

SQL Server のパフォーマンスの監査を開始するには、パフォーマンス モニター (システム モニター) を使用するのが最適です。 いくつかの主要なカウンターを 24 時間にわたって監視すると、SQL Server のパフォーマンスに影響を与えている主要なハードウェアの問題をかなり把握できます。

理想的には、パフォーマンス モニターを使用して、24 時間分の主要なメーター測定値のログ ファイルを作成する必要があります。 ログ ファイルを作成する「標準的な」24 時間を選択します。 たとえば、週の終わりや休日ではなく、通常の平日を選択します。

24 時間のパフォーマンス モニター データをログ ファイルに記録したら、パフォーマンス モニター グラフ モードで推奨カウンターを表示し、平均値、最小値、および最大値を上の表に記録します。 これを完了したら、結果を以下の分析結果と比較してください。 この比較により、SQL Server に影響を与える潜在的なハードウェア ボトルネックを特定することができます。

主要パフォーマンス モニターのカウンターを解釈する方法

以下では、基本的なパフォーマンス モニター カウンター、その推奨値、およびハードウェアの問題の特定と解決に役立ついくつかのオプションについて説明します。 考慮するパフォーマンス モニター カウンタの数を制限していることに注意してください。 この記事の目的は、生産性の低下という単純かつ明白な問題を検出することであるため、これが行われます。 他の多くのパフォーマンス モニター カウンタについては、この Web サイトの他の場所で説明されています。

メモリ: ページ/秒

このカウンタは、RAM からディスクにフラッシュされる、またはディスクから RAM に読み込まれる 1 秒あたりのページ数を測定します。 ページ スワップが多く発生すると、サーバーで発生する I/O 負荷が増加し、SQL Server のパフォーマンスに悪影響を与える可能性があります。 目標は、ページのスワップを排除することなく最小限に抑えることです。

サーバー上で実行されているメイン アプリケーションが SQL Server のみであると仮定すると、この数値は 0 ～ 20 の間であることが理想的です。20 をはるかに超える外れ値が表示される可能性が非常に高くなりますが、これはごく普通のことです。 ここで重要なのは、平均ページ交換率を 20 未満に抑えることです。

サーバーの平均ページ数が 1 秒あたり 20 ページを超えている場合、最も考えられる原因の 1 つは、必要な RAM の不足です。 一般に、利用可能な RAM が多いほど、実行するページ スワップの回数は少なくなります。

ほとんどの場合、適切な RAM を備えた SQL Server 専用の物理サーバーでは、平均ページ スワップは 20 未満になります。SQL Server に適切な RAM は次の基準によって決定できます。サーバーにはバッファ キャッシュ ヒット率 (バッファヒットキャッシュ率) 99% 以上。 このカウンタについては、この記事で後ほど説明します。 24 時間でこの比率が 99% 以上である SQL Server を使用しているにもかかわらず、同じ期間で平均ページ交換率が 20 を超えている場合は、SQL Server で他のアプリケーションを実行している可能性があります。 SQL Server 以外の物理サーバー。 この場合、理想的にはこれらのアプリケーションを削除し、SQL Server が物理サーバー上の唯一のマスター アプリケーションになるようにする必要があります。

SQL Server が他のアプリケーションを実行しておらず、ページ スワップが 24 時間で平均 20 を超えている場合は、SQL Server のメモリ設定が変更された可能性があります。 SQL Server は、「SQL Server メモリを動的に構成する」オプションが設定され、「最大メモリ」設定が最高の設定に設定されるように構成する必要があります。 最適なパフォーマンスを得るには、SQL Server が他のアプリケーションと RAM を競合することなく、SQL Server 自身のニーズに応じて必要な量の RAM を使用できるようにする必要があります。

メモリ：空き容量

SQL Server に十分な物理 RAM があるかどうかを確認するもう 1 つの方法は、Memory Object: Available Bytes カウンタをチェックすることです。 その値は 5 MB を超える必要があります。 それ以外の場合、SQL Server にはさらに多くの物理 RAM が必要になります。 SQL Server に特化したサーバーでは、後者は 4 ～ 10MB の空き物理メモリを維持しようとします。 残りの物理 RAM は、オペレーティング システムと SQL Server によって使用されます。 使用可能なメモリの量が 5 MB に近いか、それ以下の場合は、メモリ不足による SQL Server の過負荷が発生している可能性が高くなります。 この場合は、サーバーの物理 RAM の量を増やすか、サーバーの負荷を軽減するか、SQL Server のメモリ構成設定をそれに応じて変更する必要があります。

物理ディスク: ディスク稼働時間 %

このカウンタは、物理ディスク アレイ (論理パーティションやアレイ内の個々のディスクではありません) がどの程度ビジーであるかを示します。 これは、ディスク アレイがどの程度ビジーであるかを相対的に測定するのに役立ちます。

経験則として、ディスク時間カウンターの読み取り値は 55% 未満である必要があります。 カウンタの読み取り値が連続して 55% を超える場合 (24 時間の監視中に 10 分を超える場合)、SQL Server で I/O の問題が発生している可能性があります。 24 時間の監視中にこの動作がたまにしか見られない場合は、あまり心配する必要はありませんが、頻繁に発生する場合 (たとえば、1 時間に数回)、I/O パフォーマンスを向上させる方法を探し始めるでしょう。サーバー上の負荷を軽減するか、サーバーの負荷を軽減します。 ディスク I/O を増やす方法としては、アレイに新しいディスクを追加する (可能な場合)、ディスクをより高速なものに交換する、コントローラー ボードにキャッシュを追加する (可能な場合)、異なるバージョンの RAID を使用する、またはより高速なコントローラーをインストールするなどがあります。 。

NT 4.0 でこのカウンタを使用する前に、コマンド プロンプトに「diskperf-y」と入力して、カウンタを手動で有効にする必要があります。 この後、サーバーを再起動する必要があります。 したがって、Windows NT 4.0 ではディスク カウンタをすぐに有効にする必要があります。 Windows 2000 を実行している場合、このカウンタはデフォルトで有効になっています。

物理ディスク: 平均ディスクキュー長

「物理ディスク: ディスク稼働時間」カウンタの値を監視することに加えて、平均ディスク キュー長カウンタ (Avg. Disk Queue Length) の値も監視することをお勧めします。 アレイ内の各ドライブでこの値が連続期間 (24 時間の監視期間中 10 分を超える) で 2 を超える場合、アレイがシステム パフォーマンスのボトルネックになっている可能性があります。 ディスク タイマーと同様に、これが 24 時間の監視期間中に時々発生する場合は、あまり心配する必要はありませんが、頻繁に発生する場合は、説明したようにサーバーの I/O パフォーマンスを向上させる方法を探し始めることになります。その上。

パフォーマンス モニターではアレイ内の物理ディスクの数がわからないため、この数値を計算する必要があります。 たとえば、6 つの物理ディスクのアレイがあり、そのアレイの平均キュー長が 10 の場合、ディスクあたりの実際の平均ディスク キューは 1.66 (10/6=1.66) となり、推奨される 2 の範囲内に十分収まります。 by-1 物理ディスク。

NT 4.0 でこのカウンタを使用する前に、NT コマンド プロンプトで「diskperf-y」と入力し、サーバーを再起動して、必ず手動でカウンタを有効にしてください。 したがって、Windows NT 4.0 をインストールした直後にディスク カウンタを有効にする必要があります。 Windows 2000 を使用している場合、このカウンタはデフォルトで有効になります。

サーバーで I/O 問題が発生しているかどうかを正確に確認するには、上記の両方のカウンターを使用します。 たとえば、ディスク稼働時間が 55% を超える期間が多く、物理ディスクあたりの平均ディスク キュー長が 2 を超えている場合は、サーバーに I/O 問題があると確信できます。

プロセッサ: CPU 時間 %

Processor Object: % Processor Time カウンタは各 CPU で使用でき、個々の CPU の使用量を推定します。 同様のカウンタは、中央プロセッサのセット全体 (合計数) にも使用できます。 これは、CPU 使用率を監視するための重要なカウンターです。 このカウンターの合計プロセッサー負荷時間が連続して 80% を超える場合 (24 時間の監視期間で 10 分を超える場合)、CPU がシステムのボトルネックであると考えることができます。 このような高負荷の期間が時々発生し、それを許容できると思われる場合は、すべて問題ありません。 ただし、この問題が頻繁に発生する場合は、より高速な CPU を購入する、より多くの CPU をインストールする、またはより大規模な L2 キャッシュが内蔵された CPU を購入するなど、サーバーの負荷を軽減するオプションを検討する必要があります。

システム: CPU キューの長さ

CPU 時間カウンタとともに、プロセッサ キュー長カウンタも監視する必要があります。 このレートが継続的に CPU あたり 2 を超える場合 (24 時間の監視期間中に 10 分を超える場合)、システムのボトルネックである可能性があります。 たとえば、サーバーに 4 つの CPU がある場合、CPU キューの長さは合計 8 を超えてはなりません。

CPU キューの長さが定期的に推奨最大値を超えているが、CPU 使用率がそれほど高くない場合 (これが典型的なケースです)、SQL Server の「最大ワーカー スレッド」構成パラメーターの値を減らすことを検討してください。 CPU キューの長さが長くなる原因としては、順番を待っている過剰な数のワーカー スレッドが存在することが考えられます。 このパラメータを使用してその数を減らすと、(まだ使用されていない場合は) スレッド プーリングを使用するか、その役割を増やす必要があります。

CPU に問題があるかどうかを正確に判断するには、説明されている両方のカウンタを一緒に使用してください。 両方の指標が同じ継続期間にわたって推奨値を超えている場合は、CPU がシステムの弱点であると確信できます。

SQL Server バッファ: バッファ キャッシュ ヒット率

このカウンター (SQL Server バッファ: バッファ キャッシュ ヒット率) は、SQL Server がデータを取得するためにハード ドライブではなくバッファにアクセスする頻度を示します。 OLTP アプリケーションでは、この比率は 90% を超える必要があり、理想的には 99% を超える必要があります。 バッファ キャッシュ ヒット率が 90% 未満の場合は、今すぐ RAM を追加購入する必要があります。 この比率が 90% から 99% の間にある場合は、RAM の追加購入を真剣に検討する必要があります。これは、99% に近づくほど SQL Server の実行速度が速くなるからです。 場合によっては、データベースが非常に大きい場合、サーバーに最大量の RAM を搭載しても 99% に近づけることができないことがあります。 その場合、できる限り多くのメモリを追加し、現状を受け入れることしかできません。

OLAP アプリケーションでは、OLAP アプリケーションの性質により、この比率が大幅に低くなる可能性があります。 いずれにしても、RAM を増やすと SQL Server の速度が向上します。

SQL Server: ユーザー接続

SQL Server のユーザー数はパフォーマンスに影響するため、ユーザー接続カウンター (SQL Server 一般統計オブジェクト: ユーザー接続カウンター) を監視することをお勧めします。 これは、特定の時点で SQL Server に接続しているユーザーの数ではなく、ユーザーの接続数を示します。

このカウンタが 255 より大きい場合は、「最大ワーカー スレッド」構成パラメータを増やす必要があります。デフォルトは 255 です。接続数が使用可能なワーカー スレッドの数を超えると、SQL Server はワーカー スレッドの共有を開始し、悪影響を及ぼす可能性があります。インパクトのあるパフォーマンス。 このパラメータの設定は、サーバー上で到達できる最大接続数より大きくする必要があります。

次は何ですか

ここで説明したものよりも多くのカウンターがありますが、後者はパフォーマンス監査プロセス中に発生する監視の鍵となります。 パフォーマンス モニターの分析が完了したら、この記事シリーズ全体で提供される推奨事項を使用して、SQL Server が適切に動作するように必要な変更を加えます。

データベース管理者なら誰でも、すべての動作が遅い、またはまったく動作しないという事実に対処しなければならなかったことがあるのではないでしょうか。 まず最初に知る必要があるのは、現時点で SQL Server で実際に何が起こっているのかということです。 管理者は便利なものをたくさん持っているようです。間抜けなアクティビティ モニター、多数の動的管理ビュー (dmv)、SQL Server 7 や SQL Server 2000 の時代から継承したストアド プロシージャ sp_who および sp_who2 などです。
でも、考えてみましょう...

監視ツール

アクティビティモニター
それは素晴らしいことのように思えるかもしれません。アクティビティを監視するという、まさに必要なことを実行します。 重いアカウンティング レポートを起動し、アクティビティ モニターに何が表示されるかを確認します。
スクリーンショットは、SQL Server 2005 のアクティビティ モニターを示しています。

SQL Server Denali (2012) CTP 3 から。


うーん。 十数人がそのようなレポートを実行したらどうなるでしょうか? そして、これは珍しいことではありません...もちろん、進歩は明らかですが、それを理解するのは非常に不便です。 デナリのアクティビティ モニターでは、さらに役立つ情報 (たとえば、どの特定のリソースで待機が発生しているかなど) が表示されるほか、たとえば、必要なセッションのプロファイラーをモニターから直接起動し、すでにプロファイラーで追跡することもできます。 、しかし、なんと、追加で負荷がかかり、すでに過負荷になっているサーバーが追加されます。 さらに、ブレーキにすでに問題があり、プロファイラーの起動時にすでに実行が開始されていたリクエストは表示されません。
そして、これはまさに私が見たいものです - 誰が今何をしているのか。

sp_who と sp_who2
スクリーンショットは、同じ不運なレポートの作成中に実行された sp_who (上) と sp_who2 (下) の実行結果を示しています。


うん。 とても有益です。 sp_who を見ると、何かが実行されていることがわかります。 もちろん実行されます。それが私たちが注目する理由ですが、ある種の SELECT が実行されていることがわかります。 または複数の SELECT。
sp_who2 には詳細情報が表示されます。 これで、セッションで費やされたプロセッサ時間 (おそらく、列内の合計時間を合計)、I/O 操作の数、これらすべてが実行されたデータベースの名前、および実行者がわかります。セッションはブロックされています (ブロックされている場合)。
ご覧のとおり、アクティビティ モニターはさらに多くの情報を提供します。
DMV
SQL Server 2005 以降、サーバーの状態に関する情報を取得する新しい機能である動的管理ビューが追加されました。 MSDN には次のように記載されています。「動的管理ビューと関数は、サーバー インスタンスの健全性の監視、問題の診断、パフォーマンスの調整に使用できるサーバーの健全性データを返します。」
実際、SQL Server 2005 には、現時点でのクエリの実行に関連する一連のビューがあります (ただし、「履歴」を表示するためのビューもあります): ここにあり、その数はバージョンごとに増加し続けています。
確かに、経験豊富な管理者は、サーバーの現在の状態に関する情報を取得するためのスクリプトを大量に用意していますが、DMV の操作経験がまだなく、すでに問題が発生している場合はどうすればよいでしょうか?

sp_WhoIsActive

Adam Machanic (SQL Server MVP および MCITP) は、同じ DMV に依存し、非常に使いやすい sp_WhoIsActive ストアド プロシージャを開発し、継続的に改良しています。 sp_WhoIsActive の最新バージョンをダウンロードできます。 Adam 自身が sp_WhoIsActive に特化した一連の記事を持っており、30 (30!) もの記事で構成されています。それを読むこともできますが、私はこの資料を読むことに興味を持っていただけるように努めます :)。
したがって、このスクリプトをテスト サーバーの 1 つ (2005 からデナリまでの任意のバージョン) にダウンロードして実行したと仮定します。 Adam は、任意のデータベースのコンテキストで呼び出せるように、マスター システム データベースに保存することをお勧めしますが、これは必須ではありません。別のデータベースのコンテキストで呼び出す場合は、名前を完全に記述する必要があります - DB .schema.sp_whoIsActive。
それでは、試してみましょう。 スクリーンショットは、同じレポートの作成中に実行された結果を示しています。

exec sp_whoIsActive クエリの結果は、残念ながら 1 つの画面に収まらないため、パラメータなしで呼び出されたストアド プロシージャの出力をテキストで説明します。
  • - アクティブなリクエストの場合は実行時間を示し、「スリープ」セッションの場合は「スリープ」時間を示します。
  • - 実際には、スピッド。
  • - 現在実行中のリクエストのテキスト、またはセッションがスリープ中の場合は最後に完了したリクエストのテキストを表示します。
  • - まあ、わかります。
  • - 非常に興味深いコラムです。 (Ax:Bms/Cms/Dms)Eの形式で出力されます。 A はリソース E で待機しているタスクの数です。B/C/D はミリ秒単位の待機時間です。 リソースの解放を待っているセッションが 1 つだけの場合 (スクリーンショットのように)、その待ち時間が表示されます。セッションが 2 つある場合は、その待ち時間が B/C 形式で表示されます。 3 つ以上が待機している場合は、このリソースの最小、平均、最大待機時間が B/C/D 形式で表示されます。
  • - アクティブなリクエストの場合 - このリクエストによって費やされた合計 CPU 時間、スリープ セッションの場合 - このセッションの「全期間」の合計 CPU 時間。
  • - アクティブなクエリの場合、これはクエリ実行中の TempDB への書き込み操作の数です。 スリープ セッションの場合 - セッションの存続期間全体にわたる TempDB 内のレコードの総数。
  • - アクティブなリクエストの場合 - このリクエストに割り当てられた TempDB 内のページ数。 スリープ セッションの場合 - セッションの全存続期間中に割り当てられた TempDB 内のページの合計数。
  • - 突然誰かにブロックされた場合、ブロックした人の spid (session_id) が表示されます。
  • - アクティブなリクエストの場合 - このリクエストの実行時に実行された論理読み取りの数。 スリープセッションの場合 - このセッションの全期間中に読み取られたページ数。
  • - すべて同じですが、記録についてです。
  • - アクティブなリクエストの場合 - このリクエストの実行時に実行された物理読み取りの数。 睡眠セッションの場合 - 伝統的に、セッションの全期間にわたる物理的な測定値の合計数。
  • - アクティブなリクエストの場合 - このリクエストの実行時に使用される 8 キロバイトのページ数。 スリープ セッションの場合 - 存続期間全体で割り当てられた合計メモリ ページ数。
  • - セッションステータス - 実行中、スリープ中など。
  • - このセッションによってオープンされたトランザクションの数を示します。
  • - 可能であれば、操作の進行状況を表示します (バックアップ、復元など)。 SELECT が何パーセント完了したかは決して表示されません.
の残りの列 標準出力 sp_WhoIsActive にはあまり興味がないので説明しません。その目的は誰にとっても明らかだと思います (host_name、database_name、program_name、start_time、login_time、request_id、collection_time)。

そして何？ これで全部ですか？

いいえ、それだけではありません。 また、sp_WhoIsActive を呼び出すことができるパラメータ (私の観点から見て、最も興味深く便利なパラメータ) と、それによって何が起こるかについても説明します。
  • @help は非常に便利なオプションです。 sp_whoIsActive @help = 1 を呼び出すと、すべてのパラメータに関する情報と画面上の出力列が取得されます。 不明な点がある場合は、いつでも「ヘルプ」を参照してください。
  • @filter_type と @filter - 実行結果をフィルタリングできます。 @filter_type は、「セッション」、「プログラム」、「データベース」、「ログイン」、および「ホスト」の値を取ることができます。 パラメータでは、選択したタイプのどのオブジェクトに興味があるかを示します。 たとえば、master データベースで実行されているすべてのセッションを確認したい場合は、 exec sp_whoIsActive @filter_type = "database", = "master" を呼び出します。 パラメータには「%」を使用できます。
  • @not_filter_type と @not_filter - 「逆に」フィルタリングできるようにします。 つまり、たとえば、「database」フィールドに「master」が含まれるセッション以外のすべてを表示したいとします。このためには、 exec sp_WhoIsActive @not_filter_type = “database”, @not_filter = “master” を実行します。 そうですね、または、ユーザー sa を除くすべてのユーザーが何をしているかを確認したいと考えています... 多くのアプリケーションが考えられます。 @not_filter パラメータでは「%」の使用が許可されます。
  • @show_system_spids = 1 - システムセッションに関する情報を表示します。
  • @get_full_inner_text = 1 - sql_text フィールドには、バッチ (バッチ) 内の現在のリクエスト (ステートメント) のテキストだけでなく、バ​​ッチ全体のテキストも含まれます。
  • @get_plans - クエリ実行プランを含む列を出力に追加します。
  • @get_transaction_info = 1 - トランザクション ログ内のエントリの数とボリューム、および最後のトランザクションの開始時刻を出力に追加します。
  • @get_locks = 1 - リクエストの実行中に適用されるすべてのロックに関する情報を出力に追加します。
  • @find_block_leaders = 1 - ブロックのチェーンを追跡し、現在のセッションがブロックを削除するのを待機しているセッションの総数を表示します。
  • @output_column_list = "[%]" - sp_whoIsActive 出力に tempDB 情報を表示したくない場合はどうすればよいですか? このオプションを使用すると、出力内容を制御できます。
  • @destination_table = "table_name" - 実行結果をテーブルに挿入しようとしますが、このテーブルが存在するかどうか、およびテーブルに挿入するための十分な権限があるかどうかはチェックしません。

これですべてです

その結果、SQL Server 上の現在のアクティビティを監視するための、非常に便利で柔軟なツールがもう 1 つ誕生しました。 通常の操作では、VIEW SERVER STATE 権限と dmv にアクセスする権限があれば十分です。
サーバーが経由でのみ接続できる場合にも追加する価値があります。

関連記事