1. 概要 SQL Server パフォーマンスモニタ
1.1とは SQL Server パフォーマンスモニター?
SQL Server パフォーマンスモニターは、コンピュータのパフォーマンスと健全性を追跡、分析、管理するプロセスです。 SQL Server データベース。データベースシステムのさまざまな側面に関するデータを収集・解釈し、最適なパフォーマンスを確保し、問題を防止し、データベースの健全性を維持します。
パフォーマンス監視には、クエリ実行時間、リソース使用率、インデックスパフォーマンス、ブロックとデッドロック、データベースの拡張パターンの追跡が含まれます。この継続的な監視により、管理者は潜在的な問題がユーザーや業務に影響を与える前に特定することができます。
1.2 パフォーマンス監視の主な利点
効果的な SQL Server パフォーマンス モニターには、いくつかの重要な利点があります。
- 積極的な問題検出: 潜在的な問題がユーザーや業務運営に影響を与える前に特定し、対処する
- パフォーマンスの最適化： ボトルネックと非効率性を特定し、データベース全体のパフォーマンスを向上します
- 容量計画: 過去のデータに基づいてリソースのニーズを予測し、将来の成長を計画する
- コンプライアンスとセキュリティ: 規制要件の遵守を確保し、疑わしい活動を検出する
1.3 一般的なパフォーマンスの課題
適切な SQL データベース パフォーマンス モニターがないと、組織は次のようないくつかのリスクに直面します。
- 業務運営を中断させる予期せぬダウンタイム
- アプリケーションのパフォーマンスが悪く、ユーザーエクスペリエンスに影響する
- データの損失または破損
- 非効率的な資源利用は不必要なコストにつながる
- ユーザーの不満と潜在的な収益損失
2023 年の IDC の調査によると、データベース パフォーマンスの問題の 65% は、監視または最適化の実施が不十分なことに起因しています。
2. Windows パフォーマンス モニター (PerfMon) について
2.1 Windows パフォーマンス モニターとは何ですか?
Windowsパフォーマンスモニター（PerfMon）は、システムリソースとアプリケーションのパフォーマンスを監視するWindows組み込みツールです。 SQL Server 管理者にとって、PerfMonはオペレーティングシステムと SQL Server メトリックであり、包括的なパフォーマンス分析に不可欠です。
PerfMonは定期的にパフォーマンス統計を測定し、後で分析するためにファイルに保存します。データベース管理者は、時間間隔、ファイル形式、監視する統計を選択できます。このツールは SQL Server-固有 - システム管理者はこれを使用して、Windows 自体、Exchange、ファイル サーバー、およびボトルネックが発生する可能性のあるアプリケーションを監視します。
2.2 パフォーマンスモニターの起動
パフォーマンス モニターは、いくつかの方法で起動できます。
- 詳しくはこちら お気軽にご連絡ください、タイプ パフォーマンスモニタ 検索ボックスで、検索結果の「パフォーマンスモニター」をクリックします。
- メディア掲載 Windowsの+ R、タイプ パフォーマンスモニタ、プレス Enter
- MFAデバイスに移動する コントロールパネル -> システムとセキュリティ -> [管理ツール] -> パフォーマンスモニタ
3。 不可欠 SQL Server パフォーマンスカウンター
3.1 メモリパフォーマンスカウンタ
メモリカウンタは監視に重要 SQL Server これらは、データベースに十分なメモリ リソースがあるかどうかを示すため、パフォーマンスに影響します。
利用可能なMB
このカウンタは、割り当て可能な物理メモリの容量を示します。この値はほぼ一定で、理想的には4096MBを下回らないはずです。値が低い場合は、 SQL Serverの最大メモリ設定がデフォルトのままになっているか、SQL Server アプリケーションがメモリを消費しています。
ページの寿命
ページ寿命予測値は、ページがバッファプール内で参照されずに留まる時間（秒単位）を測定します。通常値は300秒以上です。この値が低い場合、メモリ負荷が高く、バッファのターンオーバーが過剰になり、キャッシュの有効性が低下していることを示します。
バッファキャッシュヒット率
このカウンタは、ディスクからの読み取りではなくSQLバッファキャッシュ（メモリ）を使用して応答されたデータ要求の割合を示します。通常は99%以上になります。値が低い場合は、 SQL Server メモリが不足しているか、再起動後まだウォームアップ中です。
保留中のメモリ付与
これは、メモリを待機しているプロセスの数を示します。 SQL Server通常の状況では、この値は常に0であるはずです。値が大きい場合は、メモリの割り当てが不十分であることを示します。 SQL Server.
ターゲットサーバーメモリと合計サーバーメモリ
ターゲットサーバーメモリは、理想的なメモリ容量を示します。 SQL Server 使用したい。サーバーメモリの合計は SQL Server 現在使用しているメモリ量です。これらの値の比率はおよそ1になるはずです。大きな差がある場合は、メモリ不足またはメモリ不足を示している可能性があります。
3.2 プロセッサパフォーマンスカウンタ
CPUカウンターはプロセッサのボトルネックを特定し、 SQL Server コンピューティング リソースを活用します。
% プロセッサ時間
これは、プロセッサがアイドル状態ではないスレッドの実行に費やした経過時間の割合を測定します。アクティブなサーバーでは、値が100%まで急上昇する可能性がありますが、70～75%を超える使用率が持続する場合は、通常、ユーザーにとってパフォーマンスの問題を示しています。インデックスの欠落や不適切なインデックスは、多くの場合、CPU使用率の上昇を引き起こします。
特権時間の割合
プロセッサ時間は、ユーザーモードと特権（カーネル）モードの処理に分割されます。すべてのディスクアクセスとI/Oはカーネルモードで実行されます。このカウンタが25%を超える場合、システムのI/O実行が過剰である可能性があります。正常値は5%から10%の範囲です。
プロセッサキューの長さ
このカウンタはCPUリソースを待機しているスレッド数を示します。値が常に1より大きい場合（ SQL Server バックアップ圧縮など）はCPU負荷が高いことを示します。これは多くの場合、他のアプリケーションがCPUにインストールされていることを意味します。 SQL Server マシンはベストプラクティスに違反します。
コンテキストスイッチ/秒
これは、プロセッサがスレッドを切り替える頻度を測定します。コンテキストスイッチが多すぎるとパフォーマンスに影響し、システム負荷が高くなることを示します。
3.3 ディスクI/Oパフォーマンスカウンタ
ディスク I/O はデータベース システムの主なボトルネックになることが多いため、ディスク カウンターは SQL パフォーマンスの監視に不可欠です。
ディスク時間の割合
これは、ディスクが読み取り/書き込み操作でビジー状態だった時間の割合を記録します。値が常に85%を超える場合は、I/Oボトルネックが発生していることを示します。ディスクはメモリよりもはるかに遅いため、この指標を下げることでパフォーマンスが向上します。
平均ディスク秒/読み取りと平均ディスク秒/書き込み
これらのカウンターは、読み取りおよび書き込み操作の平均時間（秒単位）を測定します。平均値が10～20ミリ秒を超える場合、ディスクのデータ処理に時間がかかりすぎていることを示します。トランザクションログドライブでは、特に高速な書き込みパフォーマンスが求められます。
ディスクキューの長さ
これは、ディスクへの未処理の読み取り/書き込み要求を示します。値が常に2（またはRAIDアレイの場合はディスクあたり2）を超える場合、ディスクがI/O要求に対応できないことを示します。
ディスクバイト/秒
ディスクとの間のデータ転送速度を監視します。この速度がディスクの定格容量を超えると、ディスクキューの長さが増加し、データのバックログが始まります。
ディスク転送数/秒
これは、ディスク上で実行された読み取り/書き込み操作の数を追跡します。 SQL Server データアクセスは通常ランダムであり、ドライブヘッドの動きにより速度が低下します。この値がディスクドライブの最大速度（標準的なドライブでは通常100/秒）を下回っていることを確認してください。
3.4 SQL Server 特定のカウンター
3.4.1 バッファマネージャカウンタ
バッファマネージャカウンタモニター SQL Serverのメモリバッファ操作:
- ページ読み取り数/秒: 物理データベースページ読み取りの累積数
- ページ書き込み数/秒: 物理データベースページ書き込みの累積数
- 遅延書き込み/秒: レイジーライターによって空きメモリに書き込まれたバッファの数
- チェックポイントページ数/秒: チェックポイントまたはすべてのダーティページのフラッシュを必要とするその他の操作によってフラッシュされたページ
3.4.2 SQL統計カウンタ
これらのカウンターは、 SQL Server クエリ処理:
- バッチリクエスト数/秒: サーバーが受信したSQLバッチリクエストの数。これはサーバーのアクティビティのベンチマークとして機能します。
- SQLコンパイル/秒: SQLコンパイルの数。1秒あたりのバッチリクエスト総数の10%以下にする必要があります。
- SQL再コンパイル/秒: SQL再コンパイル回数。1秒あたりのバッチリクエスト総数の10%以下にする必要があります。
3.4.3 一般統計カウンタ
- ユーザー接続: システムに接続しているユーザー数。時間の経過に伴う接続数の増加を追跡するためのベンチマークとして使用されます。
- ブロックされたプロセス: 現在ブロックされているプロセスの数。理想的には0であるべきである。
3.4.4 メモリマネージャカウンタ
- 保留中のメモリ付与: ワークスペースメモリの許可を待機しているプロセスの総数。理想的には0です。
4. パフォーマンスモニターの設定 SQL Server(Windows Vista / Server 2008以降)
まず、カウンターをより簡単に管理するためのコンテナーを作成する必要があります。
- Windows Vista / Server 2008 以降のバージョンでは、このセクションでデータ コレクター セットを作成できます。
- Windows XP / Server 2003以前のバージョンでは、カウンターログを次のように作成できます。 次のセクション.
4.1 データコレクターセットとは何ですか?
データコレクターセットは、パフォーマンスカウンター、イベントトレースデータ、システム構成情報を単一の収集ユニットにまとめます。単純なカウンターログよりも柔軟性が高く、自動化されたスケジュールされたデータ収集により、包括的なSQLデータベースパフォーマンス監視を実現します。
4.2 データコレクターセットの作成
監視するカスタムデータコレクターセットを作成する SQL Server パフォーマンスカウンター:
- パフォーマンスモニターを開く
- 研究開発を拡張 データコレクターセット
- 右クリックする ユーザー定義
- 選択 New -> データコレクターセット
- わかりやすい名前を入力してください（例：「SQL Server パフォーマンスメトリック
- 選択 手動で作成する（詳細）
- 詳しくはこちら 次へ
- チェック データログの作成 -> パフォーマンスカウンター
- 詳しくはこちら 次へ
- 詳しくはこちら 追加 カウンターを選択する
- 追加 希望 SQL Server およびシステムカウンター.
- 作成セッションプロセスで サンプル間隔
- 定期的なモニタリングには1分（60秒）を使用します
- アクティブなトラブルシューティングには15～30秒かかります
- 高頻度のキャプチャを長期間実行することは、パフォーマンスに影響を与え、過剰なデータを生成する可能性があるため、避けてください。
- 詳しくはこちら 次へ
- ログを保存する場所を選択します
- 詳しくはこちら 仕上げ新しいデータ コレクター セットが作成されます。
- デフォルトでは、新しいデータコレクターセットは NOT 自動的に開始されます。左側のパネルの下にある パフォーマンス -> データコレクターセット -> ユーザー定義 -> データコレクターを右クリックして選択 お気軽にご連絡ください
4.3 追加するキーカウンター
- メモリ -> 利用可能なMB
- 物理ディスク -> 平均ディスク秒/読み取り (_Total を除くすべてのインスタンス)
- 物理ディスク -> 平均ディスク秒/書き込み (_Total を除くすべてのインスタンス)
- 物理ディスク -> ディスク読み取り/秒 (_Total を除くすべてのインスタンス)
- 物理ディスク -> ディスク書き込み/秒 (_Total を除くすべてのインスタンス)
- プロセッサ -> % プロセッサ時間 (_Total を除くすべてのインスタンス)
- SQLServer: 一般統計 -> ユーザー接続
- SQLServer: メモリ マネージャー -> メモリ許可が保留中
- SQLServer: SQL 統計 -> バッチ要求数/秒
- SQLServer: SQL 統計 -> SQL コンパイル/秒
- SQLServer: SQL 統計 -> SQL 再コンパイル/秒
- システム -> プロセッサキューの長さ
4.4 停止条件の設定
無制限のデータ増加を防ぐために停止条件を設定します。
- データコレクターセットを作成したら、それを右クリックして 特性
- クリック 停止条件 タブ
- 有効にする 全体の所要時間
- 期間を1日（24時間）に設定する
- 詳しくはこちら OK 保存する
これにより、ログファイルが大きくなりすぎるのを防ぎ、スケジュールされている場合は自動的に再起動します。
4.5 データ収集のスケジュール設定
一貫した監視を確実にするためにデータ収集を自動化します。
- データコレクターセットを右クリックして、 特性
- クリック スケジュール タブ
- 詳しくはこちら 追加 新しいスケジュールを作成する
- 開始日時を設定する
- 繰り返しパターンを設定する（例：毎日）
- 詳しくはこちら OK スケジュールを保存する
自動起動させるには、Windowsタスクスケジューラで起動トリガーを作成し、サーバー起動時にデータコレクターセットが起動するように構成します。
5. パフォーマンスモニターの設定 SQL Server(Windows XP / Server 2003 以前)
Windows XP / Server 2003 以前のバージョンでは、カウンター ログを作成して、パフォーマンス カウンターのセットを選択し、定期的にファイルに記録することができます。
5.1 カウンターログの作成
新しいカウンター ログを作成するには、次の手順に従います。
- パフォーマンスモニターを開く
- 研究開発を拡張 パフォーマンスログと警告 左ペイン
- 右クリックする カウンターログ
- 選択 新しいログ設定
- ログにデータベースサーバー名（例：「ProductionSQL01」）の名前を付けます。
- 詳しくはこちら OK 設定を開始する
サーバーごとに個別のカウンター ログを作成すると、すべてのサーバーのデータを同時に収集せずに、個々のサーバーのパフォーマンスをテストできます。
5.2 パフォーマンスカウンターの追加
カウンター ログを作成したら、監視する特定のパフォーマンス カウンターを追加します。
- クリック カウンターを追加する (Comma Separated Values) ボタンをクリックして、各々のジョブ実行の詳細（開始/停止時間、変数値など）のCSVファイルをダウンロードします。
- コンピュータ名を変更して、 SQL Server
- メディア掲載 タブ 利用可能なパフォーマンスオブジェクトをロードする
- ドロップダウンからパフォーマンスオブジェクトを選択します（例： メモリ)
- 特定のカウンターを選択する リスト
- 該当する場合はインスタンスを選択してください（例：個々のプロセッサまたはディスク）。
- 詳しくはこちら 追加 カウンターを含める
- 必要なすべてのカウンターについて繰り返します
- 詳しくはこちら 閉じる 終了時
5.3 サンプル間隔の設定
サンプル間隔は、パフォーマンスモニターがデータを収集する頻度を決定します。監視のニーズに応じて適切な間隔を設定してください。
- カウンターログのプロパティで、 サンプルデータ毎
- 間隔を設定します（デフォルトは15秒）
- ベースラインモニタリングでは、毎日の収集に1分間隔を使用します。
- トラブルシューティングには、15～30秒間隔で短いバーストを使用してください。
- 詳しくはこちら OK 応募する
間隔が狭いほどデータ量が多くなり、レンダリングや分析が難しくなる可能性があることに注意してください。間隔が長いと、重要なスパイクを見逃してしまう可能性があります。データの粒度と、ストレージおよび分析要件のバランスをとってください。
5.4 ログファイルの設定
ログ ファイルを適切に構成すると、データが効率的に保存され、アクセスしやすくなります。
- クリック ログファイル カウンターログのプロパティのタブ
- ログファイルの種類を変更する テキストファイル（カンマ区切り） Excelへの簡単なインポート
- 詳しくはこちら 構成
- ファイルパスを専用の場所（共有PerformanceLogsフォルダなど）に設定します。
- 詳しくはこちら OK 確認するために
ログの保存にはネットワークアクセス可能な共有を使用すると、ファイルにリモートでアクセスして他のユーザーと共有できます。
5.5 資格情報の設定
パフォーマンスモニターがリモートにアクセスできるように適切な資格情報を設定します。 SQL Server インスタンス:
- カウンターログのプロパティで、 実行者として実行
- 次の形式でドメインユーザー名を入力します。 ドメイン\ユーザー名
- 詳しくはこちら パスワードを設定
- パスワードを入力して確認します
- 詳しくはこちら OK 保存する
これにより、PerfMon サービスは独自の資格情報ではなくドメイン権限を使用して統計を収集できるようになります。
6. パフォーマンスモニターデータの分析
6.1 パフォーマンスモニターでログファイルを表示する
パフォーマンス モニターは、保存されたログ ファイルから履歴データを表示できます。
- パフォーマンスモニターを開く
- 左側のペインで、をクリックします。 監視ツール -> パフォーマンスモニタ.
- グラフ領域の任意の場所を右クリック
- 選択 特性
- クリック ソース タブ
- 選択 ログ·ファイルの ラジオボタン
- 詳しくはこちら 追加
- ログファイル（.blg または .csv）に移動します
- ファイルを選択してクリック 店は開いています
- 時間範囲 分析したい期間を選択するためのスライダー
- 詳しくはこちら OK プロパティダイアログを閉じる
- 緑のプラスアイコンをクリックして、ログファイルからカウンターを追加します
- 表示するカウンターを選択してください
- 詳しくはこちら OK
グラフにはログファイルの履歴データが表示されます。「プロパティ」の「時間範囲」スライダーを使用して、特定の期間を絞り込み、詳細な分析を行うことができます。
6.2 Excelへのデータのエクスポート
Excel は、パフォーマンス カウンター データに対する強力な分析機能を提供します。
- ログファイルを読み込んだ状態でパフォーマンスモニターを開きます
- グラフ領域の任意の場所を右クリック
- 選択 名前を付けてデータを保存
- ファイルの場所を選択してください
- 選択 テキストファイル（カンマ区切り）（.csv） ドロップダウンから
- 詳しくはこちら Save
- CSVファイルをExcelで開く
エクスポートしたデータをフォーマットして、分析を効率化します。
- 半分空いている行2を削除し、セルA1をクリアします。
- 列Aを日付/時刻としてフォーマットする
- 数値列を小数点ゼロと桁区切りでフォーマットする
- ヘッダー内のサーバー名を検索して置換します（例：「\\SERVERNAME」を空白に置換します）
- ヘッダー内のオブジェクト名を整理する（例：「Memory」、「PhysicalDisk」、「Processor」）
- 視認性を高めるためにヘッダーのフォントサイズを8ポイントに縮小します
6.3 カウンタ値の解釈
6.3.1 メモリカウンタ分析
メモリ カウンターを分析するときは、次の指標を探します。
- 利用可能なMB数: 常に4096MB以上を維持する必要があります
- ページの寿命: 300秒を超える値はメモリが正常であることを示します。これより低い値はメモリ不足を示唆します。
- バッファキャッシュヒット率: 99%以上である必要があります。値が低い場合は、ディスクの読み取りが多すぎることを示します。
- 保留中のメモリ付与: 常に0であるべきです。正の値はメモリ不足を示します。
6.3.2 CPUカウンタ分析
CPU パフォーマンス指標には次のものがあります:
- % プロセッサ時間: 75%を超える使用率が継続している場合は、パフォーマンスに問題があることを示しています。100%への急上昇は正常ですが、持続するべきではありません。
- プロセッサキューの長さ: 1を超える値はCPU負荷を示します。タスクマネージャーでCPUを消費しているプロセスを確認してください。
- % 特権時間: 5～10%の範囲に収まるようにしてください。25%を超える値は過剰なI/O操作を示しています。
6.3.3 ディスクカウンタ分析
ディスク パフォーマンスのしきい値:
- 平均ディスク秒数/読み取りおよび書き込み: 10～20ミリ秒未満に抑える必要があります。値が高い場合は、ディスクサブシステムが遅いことを示します。
- ディスクキューの長さ: 常に2を超える値（またはRAIDのディスクごとに2）は、I/Oボトルネックを示します。
- ディスク時間の割合: 85%を超える持続的な値はディスク飽和を示す
6.4 数式と統計の使用
簡単な分析のために Excel に統計式を追加します。
- スプレッドシートの上部に7つの空白行を挿入します
- 列Aにラベルを追加します: 平均、中央値、最小値、最大値、標準偏差
- セルB2に次のように入力します: =AVERAGE(B9:B100) (B100を最後のデータ行に調整します)
- セルB3に「=MEDIAN(B9:B100)」と入力します。
- セルB4に「=MIN(B9:B100)」と入力します。
- セルB5に「=MAX(B9:B100)」と入力します。
- セルB6に「=STDEV(B9:B100)」と入力します。
- すべてのカウンター列に数式をコピーする
- セルB9を選択し、Alt+W+F+Enterを押してウィンドウ枠を固定します。
これらの統計は、各カウンターの傾向、外れ値、および通常の動作範囲を識別するのに役立ちます。
7. ログのパフォーマンス分析（PAL）ツール
7.1 PALの紹介
パフォーマンス分析ログ（PAL）は、クリント・ハフマン氏が開発した無料ツールで、パフォーマンスモニターのログを分析し、しきい値分析を含むHTMLレポートを生成します。PALはパフォーマンスデータを既知のしきい値と比較し、詳細な推奨事項を提供します。 SQL Server パフォーマンスの最適化。
GitHub リポジトリから PAL をダウンロードします。 https://github.com/clinthuffman/PAL 
7.2 PALの設定
次の手順に従って PAL をインストールします。
- GitHubからPALセットアップファイルをダウンロードする
- インストーラを実行します。
- 詳しくはこちら 次へ ようこそ画面で
- インストールディレクトリを確認して承認する
- 詳しくはこちら 次へ 続行します
- 詳しくはこちら インストールを開始する インストールを開始する
- インストールが完了するまで待ちます
- 詳しくはこちら 仕上げ
7.3 PALによるログファイルの処理
PAL を使用してパフォーマンス モニターのログを分析します。
- スタートメニューまたはインストールディレクトリからPALを起動します。
- クリック カウンターログ タブ
- 詳しくはこちら ブラウズ .blgファイルを選択するには
- パフォーマンスモニターのログファイルに移動します
- 詳しくはこちら 店は開いています
- クリック しきい値ファイル タブ
- ドロップダウンからしきい値ファイルを選択します（例：「SQL Server 2016”）
- クリック 質問（FAQ） タブ
- システム構成に関する質問に答えます
- あなたの SQL Server OLTPかデータウェアハウスか
- 利用可能なRAMの合計を入力してください
- クリック 出力オプション タブ
- HTMLレポートの出力ディレクトリを選択します
- チェック HTML 出力フォーマット
- クリック 実行する タブ
- 選択内容を確認する
- チェック 今すぐ実行を開始
- 詳しくはこちら 仕上げ
7.4 PALレポートの分析
PAL は分析を完了すると、次の内容を含む HTML レポートを生成します。
- パフォーマンスの問題の概要
- チャートによる詳細なカウンター分析
- しきい値違反は色で強調表示されます
- 各問題に対する具体的な提言
- 歴史的な傾向とパターン
このレポートでは、重大度を色分けで示しています。重大な問題は赤、警告は黄色、正常な指標は緑で表示されます。各セクションを確認してパフォーマンスのボトルネックを把握し、PALの最適化に関する推奨事項に従ってください。
8.代替 SQL Server 監視ツール
8.1ビルトイン SQL Server ツール
8.1.1 SQL Server 活動モニター
SQL Server 活動モニター リアルタイムの情報を表示します SQL Server プロセスとパフォーマンス:
- 店は開いています SQL Server Management Studio(SSMS) を起動し、サーバーインスタンスに接続します。
- オブジェクトエクスプローラーでサーバー名を右クリックします。
- 選択 活動モニター
アクティビティモニターは、プロセス、リソースの待機時間、データファイルのI/O、最近の高負荷クエリを表示します。現在のデータベースアクティビティに関する迅速な洞察を提供しますが、履歴データは保存しません。
8.1.2 SQL Server パフォーマンスダッシュボード
SQL Server Management Studio には、パフォーマンス レポートが組み込まれています。
- In SQL Server Management Studio(SSMS)で、 SQL Server オブジェクトエクスプローラーのインスタンス
- 選択 レポート -> 標準レポート
- 利用可能なレポートから選択してください パフォーマンスダッシュボード
パフォーマンスダッシュボードでは、 SQL Server インスタンスのパフォーマンス（システムCPU使用率、現在待機中のリクエスト、パフォーマンス指標など）を表示します。標準レポートメニューからアクセスできます。
8.1.3 SQL Server プロファイラー
SQL Server プロファイラー キャプチャして分析する SQL Server クエリ実行、トランザクション操作、ログイン アクティビティなどのイベント。
始めること SQL Server プロファイラー:
- In SQL Server Management Studio、クリック ツール -> SQL Server プロファイラー
プロファイラはかなりのパフォーマンスオーバーヘッドを発生させるため、使用は慎重に行い、できればピーク時以外の時間帯に使用してください。ほとんどのシナリオでは、拡張イベントの方がパフォーマンスが向上し、影響も少なくなります。
8.1.4 拡張イベント
延長イベント 軽量なパフォーマンス監視システムです。 SQL Server. 置き換え SQL Server パフォーマンスが向上し、オーバーヘッドが低減されたプロファイラー。
主な機能は次のとおりです。
- 特定のイベントのきめ細かな監視
- パフォーマンスへの影響は最小限
- カスタマイズ可能なイベントセッション
- SSMSおよびその他のツールとの統合
- 複雑なフィルタリングと集計のサポート
SSMS を通じて拡張イベント セッションを作成します。
- In オブジェクトエクスプローラー、サーバーを展開して 管理 -> 拡張イベント -> セッション
- 右クリックして セッションズ 選択して 新しいセッションウィザード
- 新しいセッションを開始するには、指示に従ってください。
8.1.5 動的管理ビュー（DMV）
DMVは、サーバーの健全性の監視、問題の診断、パフォーマンスの調整に役立つ詳細なサーバー状態情報を提供します。主なDMVには以下が含まれます。
- sys.dm_exec_query_stats: クエリパフォーマンス統計
- sys.dm_os_wait_stats: サーバーのパフォーマンスに影響を与える待機の種類
- sys.dm_os_performance_counters: SQL Server パフォーマンスカウンターデータ
- sys.dm_exec_requests: 現在実行中のリクエスト
- sys.dm_exec_sessions: アクティブなユーザーセッション
T-SQL を使用してこれらのビューをクエリし、リアルタイムのパフォーマンス データと履歴メトリックにアクセスします。
基本的な使い方
-- See all active connections
SELECT * FROM sys.dm_exec_connections;
-- View current sessions
SELECT * FROM sys.dm_exec_sessions;
-- Check database file stats
SELECT * FROM sys.dm_io_virtual_file_stats(NULL, NULL);8.2 サードパーティの監視ソリューション
Redgate SQLモニター
Redgate SQL Monitorは監視に特化しています SQL Server およびAzure SQL Database環境に対応しています。資産全体の監視、カスタマイズ可能なアラートとダッシュボード、詳細なレポート機能、そして他のRedgateツールとの統合を提供します。
SolarWinds SQL Server 監視ツール
ソーラーウィンズ SQL Server SQL Sentry とも呼ばれる監視ツールは、重大なパフォーマンス問題を診断、解決、防止するように設計されています。 SQL Server.
イデラさん SQL Server パフォーマンス監視ツール
IDERA SQL Diagnostic Managerは強力な SQL Server パフォーマンス監視ツール。プロアクティブなパフォーマンス監視、診断、およびチューニングを支援するために設計されています。
Applications Manager の SQL 監視
アプリケーション マネージャーは、Microsoft の SQL Server 便利なITソリューションを提供する監視ツール。 SQL データベースのパフォーマンスを監視すると同時に、組織の運用の停止につながる可能性のあるバグを特定し、問題を解決するように設計されています。
8.3 オープンソース監視ツール
DBAダッシュ
DBA Dashは、次のような洞察を提供する無料のオープンソース監視ツールです。 SQL Server 健全性、パフォーマンス、アクティビティを管理します。特に小規模から中規模の環境に役立ち、毎日のDBAチェック、パフォーマンス監視、構成追跡が含まれます。
SQLウォッチ
SQLWATCHは分散型のほぼリアルタイムの SQL Server 5秒単位の粒度でワークロードの急上昇を捉える監視機能を備えています。リアルタイムダッシュボード用のGrafanaと、詳細な分析のためのPower BIをサポートしています。豊富な設定オプション、メンテナンス不要、そして無制限のスケーラビリティを提供します。
オプサーバー
Stack Exchangeによって開発されたOpserverは、以下を含む複数のシステムを監視します。 SQL Server、Redis、Elasticsearch に対応しています。インフラストラクチャ全体の CPU、メモリ、ネットワーク、ハードウェアの統計情報を「全サーバー」ビューで表示します。
sp_WhoIsActive
sp_WhoIsActiveは、Adam Machanicによって作成された包括的なアクティビティ監視ストアドプロシージャです。すべての SQL Server 2005年から現在のリリースまでのバージョンで広く使用されており、 SQL Server リアルタイムのアクティビティ監視を行う DBA。
sp_WhoIsActive を使用するには、http://whoisactive.com/ からダウンロードし、データベースにインストールして、次のコマンドを実行します。
EXEC sp_WhoIsActive
この手順では、現在実行中のクエリ、待機情報、ブロックの詳細、およびリソースの消費量が表示されます。
9. ベストプラクティス SQL Server パフォーマンスモニタ
9.1 パフォーマンスベースラインの確立
パフォーマンスベースラインは、お客様の通常の動作パラメータを確立します。 SQL Server 環境。ベースラインがないと、現在の指標が問題を示しているのか、それとも一般的な動作を表しているのかを判断できません。
次の方法でベースラインを作成します。
- 少なくとも1週間の通常運用中にパフォーマンスデータを収集する
- ピーク時とオフピーク時の両方で指標をキャプチャする
- キーカウンターの典型的な値を文書化する
- 該当する場合は季節変動を記録する
- 将来の指標と比較するためのベースラインデータを保存する
ベースラインは四半期ごとに更新するか、インフラストラクチャの大幅な変更、アプリケーションの更新、データベースの変更があった後に更新します。
9.2 適切なアラートしきい値の設定
通知に圧倒されることなく、意味のあるアラートを受信できるようにインテリジェントなしきい値を設定します。
- メモリ許可保留 > 0 はメモリ不足を示します
- プロセッサキューの長さがコアあたり2を超えるとCPUのボトルネックになる可能性がある
- ディスク秒/読み取りまたは書き込み > 20ms は遅い I/O を示します。
- ブロックされたプロセス > 5 は競合の問題を示します
- ページ寿命が300秒未満の場合、メモリ不足を示します。
ベースラインデータと特定のワークロード特性に基づいてしきい値を調整します。環境における通常の変動を考慮した適応型しきい値を使用します。
9.3 定期的なデータのレビューと分析
傾向と新たな問題を特定するために定期的なパフォーマンス レビューをスケジュールします。
- 毎日: 高レベルの指標と最近のアラートを確認する
- 毎週: パフォーマンスの傾向を詳細に分析する
- 月次: 包括的なレポートを生成し、ベースラインと比較します
- 四半期ごと: キャパシティプランニングと長期傾向を確認する
調査結果を文書化し、時間の経過に伴うパフォーマンスの改善を追跡します。
9.4 監視オーバーヘッドのバランスをとる
監視自体もリソースを消費するため、データ収集とパフォーマンスへの影響のバランスをとる必要があります。
- 継続的な監視には30～60秒間隔を使用してください
- アクティブなトラブルシューティングにのみ15秒間隔を使用してください
- データ収集の制限 過剰なデータを避けるために期間を設定する
- ログをデータベースファイルとは別のドライブに保存する
- 管理可能なファイルサイズを維持するために古いパフォーマンスデータをアーカイブします
パフォーマンス モニターは、適切に構成されている場合、通常はシステム リソースの 2% 未満の最小限のオーバーヘッドを追加します。
9.5 長期データ保持
意味のある傾向分析と容量計画のためにパフォーマンス データを保持します。
- 少なくとも1～2年分のパフォーマンスデータを保存する
- 3～6か月後にデータを別のストレージにアーカイブする
- 古いログファイルを圧縮してスペースを節約する
- パフォーマンスに影響を与える重要なイベントや変更を文書化する
パフォーマンス カウンター データのサイズは比較的小さいため、それを無期限に保持することは多くの場合実現可能であり、長期的な分析に役立ちます。
9.6 DevOpsプラクティスとの統合
データベース パフォーマンス監視を CI/CD パイプラインに組み込みます。
- デプロイメント検証にデータベースパフォーマンスメトリックを含める
- 新しいリリースのパフォーマンステストを自動化する
- コードの変更がパフォーマンスに悪影響を与えないことを検証する
- 各リリースのパフォーマンスベンチマークを作成する
- 監視アラートをインシデント管理システムと統合する
10. 一般的なパフォーマンス問題のトラブルシューティング
10.1 CPUボトルネックの特定
CPUのボトルネックは、クエリの応答時間が遅くなり、プロセッサ使用率が高くなるという形で現れます。CPUの問題を診断するには、以下の手順を実行してください。
- プロセッサキュー長カウンタを確認してください。コアあたりの値が2を超える場合はCPU負荷が高いことを示します。
- プロセッサ時間の割合を確認します。75%を超える値が継続している場合はCPUのボトルネックが考えられます。
- リモートデスクトップ SQL Server
- タスクマネージャーを開く（Ctrl+Shift+Esc）
- クリック プロセス タブ
- チェック すべてのユーザーのプロセスを表示する
- クリック CPU CPU使用率で並べ替える列ヘッダー
- CPUリソースを消費するプロセスを特定する
非SQL Server アプリケーションがCPUを大量に消費している場合は、データベースサーバーから削除してください。sqlservr.exeのCPU使用率が高い場合は、以下の方法で調査してください。
- SQLコンパイル/秒とSQL再コンパイル/秒を確認してください。バッチリクエスト/秒の10%を超える値は、過剰なコンパイルを示しています。
- sys.dm_exec_query_stats をクエリして CPU を集中的に使用するクエリを特定する
- 欠落したインデックスや非効率的な操作がないか実行プランを確認する
- テーブルスキャンを減らすためにインデックスの追加を検討する
10.2 メモリの問題の診断
メモリの問題は大きな影響を与える SQL Server パフォーマンス。以下の指標を使用してメモリの問題を診断します。
利用可能なメモリドロップ
利用可能なMBが継続的に100MBを下回ると、オペレーティングシステムはメモリ不足に陥ります。Windowsがページアウトする可能性があります。 SQL Server メモリがディスクにコピーされ、パフォーマンスが低下します。
ページの寿命が短い
ページ寿命予測値が300秒未満の場合、バッファキャッシュの回転率が高いことを示します。これは、メモリ割り当てが不十分であるか、クエリによるメモリ負荷が過大であることを示しています。
バッファキャッシュヒット率が低い
バッファキャッシュヒット率が99%未満の場合、 SQL Server メモリではなくディスクから頻繁にデータを読み込みます。これはバッファプールが小さすぎるか、 SQL Server 再起動後、まだウォームアップ中です。
保留中のメモリ付与
メモリ許可保留の値が0より大きい場合、クエリがメモリ許可を待機していることを示します。これは、緊急の対応が必要な重大なメモリ不足を示しています。
メモリの問題を解決するには:
- 構成 SQL Server オペレーティング システムに十分な RAM を残すための最大メモリ設定 (サーバーのサイズに応じて通常 4 ～ 8 GB)
- 「メモリ内のページのロック」権限を有効にする SQL Server サービスアカウント
- メモリ不足が続く場合は、サーバーに物理 RAM を追加します。
- メモリを大量に消費するクエリを識別して最適化する
10.3 ディスクI/O問題の解決
ディスクI/Oは、データベースシステムにおける主要なパフォーマンスボトルネックとなることがよくあります。以下の方法を用いてディスクの問題を診断してください。
ディスクキューの長さが長い
ディスクキューの長さが常に2（RAIDの場合はディスクあたり2）を超える場合、ディスクサブシステムがI/O要求に対応できないことを示します。これにより、保留中の操作のバックログが発生します。
過剰なディスク遅延
平均ディスク秒/読み取りおよび平均ディスク秒/書き込みの値が10～20ミリ秒を超える場合、ディスクの応答速度が遅いことを示します。トランザクションログドライブでは、特に高速なパフォーマンスが求められ、書き込み速度は理想的には5ミリ秒未満です。
ディスク時間の割合が高い
ディスク使用率が85%以上で推移している場合、ディスクが飽和状態にあることを示しています。ディスクはほとんどの時間をI/Oリクエストの処理に費やしており、アイドル状態の容量はほとんど残っていません。
ディスクの問題に対処する前に、それがメモリの問題によるものではないことを確認してください。メモリ不足は SQL Server ディスクからより多くのデータを読み取り、ディスク メトリックを人為的に増加させます。
本物のディスク I/O 問題を解決するには:
- より高速なディスク（HDDではなくSSD）にアップグレードする
- パフォーマンス向上のためにRAID構成を実装する
- データベースファイル、トランザクションログ、tempdbを異なる物理ドライブに分離する
- ディスク読み取りを減らすためにメモリを追加する
- 不要なI/Oを削減するためにインデックスを最適化する
- パフォーマンスの低いクエリを確認して最適化する
10.4 ブロッキングとデッドロックへの対処
ブロッキングは、あるセッションが他のセッションの進行を妨げるロックを保持している場合に発生します。ブロッキングの問題を特定するには、以下のカウンターを監視してください。
- ブロックされたプロセス: 理想的には0であるべきである
- ロック待機/秒: 待機を必要とするロック要求の数
- 平均待ち時間: ロック待機の平均時間
ブロックを調査するには:
- SSMSでアクティビティモニターを開く
- 拡大する プロセス
- ゼロ以外のプロセスを探す ブロックされた 値
- ブロックしているセッションIDを特定する
- ブロックの原因となっているクエリを確認する
より詳細なブロック分析には、sp_WhoIsActive を使用してください。wait_info エントリが過剰に発生する場合、多くの場合、tempdb の競合またはブロックの問題が示唆されます。
ブロックを減らすには:
- 取引期間を最小限に抑える
- 適切な分離レベルを使用する
- ロック期間を短縮するためにインデックスを追加する
- READ_COMMITTED_SNAPSHOT分離を検討する
- 長時間実行されるクエリを確認して最適化する
10.5 クエリパフォーマンスの問題
SQLパフォーマンス監視では、コストの高いクエリを特定することが不可欠です。問題のあるクエリを見つけるには、以下の方法があります。
アクティビティモニターの使用
- SSMSでサーバー名を右クリックします
- 選択 活動モニター
- 研究開発を拡張 最近の高額なクエリ
- CPU 使用率、実行時間、論理読み取りが高いクエリを確認する
DMVの利用
sys.dm_exec_query_stats をクエリして、リソースを大量に消費するクエリを特定します。
SELECT TOP 50
total_worker_time/execution_count AS avg_cpu_time,
total_logical_reads/execution_count AS avg_logical_reads,
execution_count,
SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.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) qt
ORDER BY total_worker_time DESC
実行計画の分析
- SSMSで新しいクエリウィンドウを開きます
- 詳しくはこちら 推定実行プランの表示 （Ctrl+L）または 実際の実行計画を含める （Ctrl+M）
- クエリを実行する
- コストのかかる操作の実行計画を確認する
- テーブルスキャン、インデックススキャン、または高コスト操作を探してください。
次の方法でクエリを最適化します。
- 適切なインデックスを追加する
- 高価な操作を避けるためにクエリを書き換える
- 統計を更新しています
- SELECT *の代わりに特定の列名を使用する
- 不要なDISTINCT句やORDER BY句を避ける
10.6 破損したデータベースの検出と修復
データベースの破損は、パフォーマンスの低下、データ損失、システム障害を引き起こす可能性があります。破損を迅速に検出し、対処することは、データベースの健全性を維持するために不可欠です。
データベース破損インジケーター
次のような潜在的な腐敗の兆候に注意してください。
- エラーメッセージ SQL Server エラーログ（エラー823、824、または825）
- 特定のテーブルにアクセスする際に予期しないアプリケーション エラーが発生する
- 以前は高速だったクエリのパフォーマンスが低下
- SQL Server クラッシュまたは予期しない再起動
- msdb.dbo.suspect_pages テーブルに疑わしいページが表示される
検出にDBCC CHECKDBを使用する
DBCCチェックDB データベースの破損を検出するための主要なツールです。問題を早期に発見するために、定期的に実行してください。
疑わしいページの監視
SQL Server 疑わしいページを msdb データベースに自動的に記録します。
SELECT
database_id,
file_id,
page_id,
event_type,
error_count,
last_update_date
FROM msdb.dbo.suspect_pages
WHERE event_type IN (1,2,3)
返された行は、すぐに対処する必要がある破損の問題を示しています。
汚職防止戦略
- CHECKSUMオプションでページ検証を有効にする
- 定期的にデータベースのバックアップを維持する
- エラー訂正機能を備えた信頼性の高いハードウェアを使用する
- メーカーのツールを使用してディスクの状態を監視する
- 定期的なDBCC CHECKDBの実行をスケジュールする
- キープ SQL Server 最新のパッチで更新されました
回復と修復のオプション
破損が検出された場合は、組み込みツールを試すことができます DBCCチェックDB 修正するには、サードパーティ製のツール（例： DataNumen SQL Recovery 深刻な汚職に対処できます。
11. 高度な監視技術
11.1 クエリストアの監視
クエリストアは、 SQL Server 2016年版では、クエリパフォーマンスデータを自動的に取得し、クエリの挙動、実行プラン、パフォーマンスの傾向に関する貴重な洞察を提供します。
クエリストアの有効化
- SSMSオブジェクトエクスプローラーで、データベースを右クリックします。
- 選択 特性
- クリック クエリストア ページ
- In 動作モード（要求）選択 読み書き
- 必要に応じて追加の設定を構成する
- 詳しくはこちら OK
クエリパフォーマンスの監視
オブジェクト エクスプローラーを通じてクエリ ストア レポートにアクセスします。
- オブジェクトエクスプローラーでデータベースを展開する
- 研究開発を拡張 クエリストア
- 利用可能なレポートから選択してください:
- 回帰クエリ
- 全体的なリソース消費
- 最もリソースを消費するクエリ
- 強制プランを使用したクエリ
- 追跡されたクエリ
計画回帰検出
クエリストアは、クエリ実行プランの変更とパフォーマンスの低下を自動的に検出します。「パフォーマンスが低下したクエリ」レポートを確認し、プラン変更の影響を受けるクエリを特定してください。
強制プラン管理
クエリストアがより良い実行プランを識別した場合、強制的に SQL Server 使用するには:
- クエリストアでクエリを開く
- 希望のプランを右クリック
- 選択 フォースプラン
これにより、コードを変更することなくパフォーマンスがすぐに向上します。
11.2 インデックスメンテナンス監視
インデックスの断片化は、時間の経過とともにクエリのパフォーマンスを低下させます。最適なパフォーマンスを確保するには、インデックスを定期的に監視およびメンテナンスしてください。
断片化チェック
インデックスの断片化を確認するには、次のクエリを使用します。
SELECT
OBJECT_NAME(i.object_id) AS table_name,
i.name AS index_name,
ps.avg_fragmentation_in_percent,
ps.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id
AND ps.index_id = i.index_id
WHERE ps.avg_fragmentation_in_percent > 10
AND ps.page_count > 1000
ORDER BY ps.avg_fragmentation_in_percent DESC
このクエリはリソースを大量に消費する可能性があるため、オフピーク時間帯に実行してください。
ページ密度分析
ページ密度は、インデックスページの使用率を示します。密度が低いとスペースが無駄になり、パフォーマンスが低下します。
SELECT
OBJECT_NAME(i.object_id) AS table_name,
i.name AS index_name,
ps.avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id
AND ps.index_id = i.index_id
WHERE ps.avg_page_space_used_in_percent < 75
再編と再構築の決定
断片化レベルに基づいてインデックスメンテナンス操作を選択します。
- 断片化10～30%: ALTER INDEX REORGANIZEを使用する
- 断片化 > 30%: ALTER INDEX REBUILD を使用する
- 断片化 < 10%: アクションは不要
再編成操作は必要なリソースが少なく、オンラインで実行できます。再構築操作はより徹底的ですが、多くのリソースを消費します。
11.3 データベース統計の更新
データベース統計ヘルプ SQL Serverのクエリオプティマイザーは効率的な実行プランを作成します。古い統計はクエリのパフォーマンスを低下させます。
自動統計再構築
自動統計更新を有効にする:
ALTER DATABASE DatabaseName SET AUTO_UPDATE_STATISTICS ON ALTER DATABASE DatabaseName SET AUTO_CREATE_STATISTICS ON
統計の健全性の監視
統計が最後に更新された日時を確認します。
SELECT
OBJECT_NAME(s.object_id) AS TableName,
s.name AS StatisticsName,
STATS_DATE(s.object_id, s.stats_id) AS LastUpdated,
sp.rows,
sp.modification_counter
FROM sys.stats s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE STATS_DATE(s.object_id, s.stats_id) < DATEADD(DAY, -7, GETDATE())
ORDER BY LastUpdated
必要に応じて統計を手動で更新します。
UPDATE STATISTICS TableName WITH FULLSCAN
11.4 カスタムパフォーマンスデータの収集
sys.dm_os_performance_counters を直接クエリし、結果をテーブルに保存することで、カスタム パフォーマンス監視ソリューションを作成します。
カスタムコレクションスクリプトの作成
パフォーマンス カウンター データを収集するためのストアド プロシージャを構築します。
CREATE PROCEDURE dbo.CollectPerformanceCounters
AS
BEGIN
INSERT INTO dbo.PerformanceHistory (
SampleTime,
CounterName,
CounterValue
)
SELECT
GETDATE(),
counter_name,
cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name IN (
'Page life expectancy',
'Batch Requests/sec',
'Buffer cache hit ratio'
)
END
sys.dm_os_performance_counters の使用
パフォーマンス カウンターを直接クエリします。
SELECT
object_name,
counter_name,
instance_name,
cntr_value,
cntr_type
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Buffer Manager%'
ORDER BY counter_name
履歴データの保存
時間の経過に伴うパフォーマンス メトリックを保存するテーブルを作成します。
CREATE TABLE dbo.PerformanceHistory (
ID INT IDENTITY PRIMARY KEY,
SampleTime DATETIME2 NOT NULL,
PageLifeExpectancy BIGINT,
BatchRequestsPerSec DECIMAL(18,4),
BufferCacheHitRatio DECIMAL(5,2)
)
CREATE CLUSTERED COLUMNSTORE INDEX CCI_PerformanceHistory
ON dbo.PerformanceHistory
ピボットデータ保存方法
データはピボット形式で保存し、サンプル時間ごとに1行、カウンターごとに1列で保存します。これにより、サンプルごとにカウンターごとに1行を保存する場合と比較して、ストレージ容量が削減され、クエリのパフォーマンスが向上します。
11.5 マルチサーバー監視
複数の SQL Server インスタンスごとに集中監視を実装します。
集中監視アプローチ
- 別のサーバーに専用の監視データベースを作成する
- すべてのサーバーから中央リポジトリにデータを収集する
- SQL Server 収集スクリプトを実行するエージェントジョブ
- ネットワークアクセス可能なパフォーマンスカウンタコレクションを実装する
リモートサーバー監視
カウンターを追加するときにサーバー名を指定して、パフォーマンスモニターがリモートサーバーからデータを収集するように設定します。ファイアウォールルールでパフォーマンスモニターのトラフィックが許可されていることを確認してください。
クロスサーバーレポート
複数のサーバー間でパフォーマンスを比較し、外れ値や容量の不均衡を特定するレポートを作成します。
12。 モニタリング SQL Server クラウド環境で
12.1 Azure SQL データベース監視
Azure SQL Databaseはオンプレミスとは異なる組み込みの監視機能を提供します SQL Server.
Azure モニターの統合
Azure Monitor は、次のようなメトリックを Azure SQL Database から自動的に収集します。
- DTU または vCore の使用率
- ストレージの使用状況
- 接続統計
- デッドロックとタイムアウト
これらのメトリックには、Azure Portal または Azure Monitor API を通じてアクセスします。
組み込みの監視機能
Azure SQL データベースには以下が含まれます。
- 自動チューニングの推奨事項
- クエリパフォーマンスインサイト
- 異常検出のためのインテリジェントインサイト
- 内蔵アラート機能と診断機能
クエリパフォーマンスインサイト
この機能は、リソース消費量の多いクエリ、クエリ実行時間分析、過去のパフォーマンス傾向を視覚化します。Azure Portal の SQL データベース リソースからアクセスできます。
12.2 クラウドネイティブ監視ツール
クラウド プラットフォームは、環境に合わせて最適化されたネイティブ監視ソリューションを提供します。
- Azure SQL Database 向けの Azure Monitor と Application Insights
- RDS 用の AWS CloudWatch SQL Server
- クラウド向け Google Cloud モニタリング SQL Server
これらのツールはクラウド インフラストラクチャとシームレスに統合され、すべてのクラウド リソースにわたる統合された監視を提供します。
ハイブリッド環境監視
オンプレミスとクラウドにまたがるハイブリッド展開の場合は、Redgate SQL Monitor、SolarWinds DPA、集中データ収集を使用するカスタム ソリューションなど、両方の環境をサポートするツールを使用します。
12.3 クラウドにおけるパフォーマンスの違い
クラウド SQL Server 環境には独自の特徴があります。
リソース割り当てモデル
クラウドプロバイダーは、パフォーマンスメトリックの解釈方法に影響を与える様々なリソース割り当て方法（DTU、仮想コア、サーバーレス）を採用しています。サービスレベルの制限と特性を理解しましょう。
スケーリングの考慮事項
クラウド環境は動的なスケーリング機能を提供します。リソース使用率を監視して、スケールアップまたはスケールダウンのタイミングを判断します。多くのクラウドプラットフォームは、パフォーマンスのしきい値に基づいた自動スケーリング機能を備えています。
13. パフォーマンス監視の自動化
13.1 SQL Server エージェントの仕事
データ収集を自動化する SQL Server 手動介入なしで一貫した監視を行うエージェント ジョブ。
スケジュールされたデータ収集
- SSMSで展開 SQL Server エージェント
- 右クリックする 求人 をクリックして 新しい仕事
- ジョブに名前を付けます（例：「パフォーマンスメトリックの収集」）
- 詳しくはこちら ステップ 新しいステップを追加する
- タイプを Transact-SQL スクリプト
- データ収集スクリプトを入力してください
- 詳しくはこちら 日程 スケジュールを追加する
- 頻度を設定する（例：5分ごと）
- 詳しくはこちら OK 仕事を作るために
自動レポート
パフォーマンス レポートを生成して電子メールで送信するジョブを作成します。
- レポートを生成するストアド プロシージャを作成する
- データベースメールを使用してレポートを電子メールで送信する
- ジョブを毎日または毎週実行するようにスケジュールする
13.2 PowerShell オートメーション
PowerShellは、次のような強力な自動化機能を提供します。 SQL Server パフォーマンスモニター。
パフォーマンスカウンター収集スクリプト
$counters = @(
'\Processor(_Total)\% Processor Time',
'\Memory\Available MBytes',
'\PhysicalDisk(_Total)\Avg. Disk sec/Read'
)
$data = Get-Counter -Counter $counters -ComputerName 'SQLServer01'
$data.CounterSamples | Export-Csv 'C:\PerfLogs\counters.csv' -Append
WMIクエリ
WMI を使用してリモート サーバーからパフォーマンス データを収集します。
$cpu = Get-WmiObject Win32_Processor -ComputerName 'SQLServer01' $memory = Get-WmiObject Win32_OperatingSystem -ComputerName 'SQLServer01' Write-Host "CPU Usage: $($cpu.LoadPercentage)%" Write-Host "Available Memory: $([math]::Round($memory.FreePhysicalMemory/1MB,2)) GB"
自動アラート
メトリックをチェックし、しきい値を超えたときにアラートを送信する PowerShell スクリプトを作成します。
$cpuThreshold = 80
$cpu = (Get-Counter '\Processor(_Total)\% Processor Time').CounterSamples.CookedValue
if ($cpu -gt $cpuThreshold) {
Send-MailMessage -To 'dba@company.com' -Subject 'High CPU Alert' `
-Body "CPU usage is $cpu%" -SmtpServer 'smtp.company.com'
}
13.3 監視ダッシュボードの作成
インタラクティブなダッシュボードでパフォーマンス データを視覚化し、より優れた洞察を得られます。
Power BI 統合
- Power BI をパフォーマンス データ テーブルに接続する
- 主要な指標の視覚化を作成する
- 時間範囲とサーバー選択用のスライサーを追加する
- ダッシュボードをPower BI サービスに公開する
- 自動更新スケジュールを設定する
リアルタイムダッシュボード作成
Grafana などのツールやカスタム Web アプリケーションを使用して、DMV とパフォーマンス カウンターを直接クエリするリアルタイム ダッシュボードを作成します。
歴史的傾向の可視化
次の時間の経過に伴う傾向を示す折れ線グラフを作成します。
- CPU使用率
- Memory usage
- ディスクI / O
- クエリのパフォーマンス
- 接続数
14. ケーススタディと実例
14.1 ケーススタディ: メモリ不足の解決
症状の特定
プロダクション SQL Server ピーク時にはクエリの応答時間が遅くなり、ユーザーからはアプリケーションのタイムアウトやパフォーマンスの低下について苦情が寄せられていました。
カウンター分析
パフォーマンス モニターのデータが明らかに:
- ページの寿命が 50 秒に短縮されました (通常: >300)
- バッファキャッシュヒット率が85%に低下しました（通常：>99%）
- 保留中のメモリ付与は5～10の値を頻繁に表示しました
- 物理ディスク読み取り/秒が大幅に増加しました
解決手順
- チェック済み SQL Server 最大メモリ設定 – デフォルト（無制限）に設定されていることが判明
- サーバーの総メモリとターゲットサーバーのメモリを比較したところ、大きな差が見られました。
- オペレーティングシステム用に8GBを残すように最大サーバーメモリを構成しました
- 「メモリ内のページのロック」権限を有効にする SQL Server サービスアカウント
- サーバーに32 GBのRAMを追加しました
- 1週間のパフォーマンス監視 – ページ寿命は500秒以上で安定
結果： クエリ応答時間は 60% 改善され、ユーザーからの苦情はなくなり、アプリケーションのパフォーマンスは正常に戻りました。
14.2 ケーススタディ: CPUパフォーマンスの最適化
症状の特定
A SQL Server 営業時間中は CPU 使用率が常に 90% を超え、アプリケーションのパフォーマンスが低下し、ユーザーの不満を招いていました。
カウンター分析
パフォーマンス監視により次のことが明らかになりました:
- プロセッサ時間の平均は 92% で、頻繁に 100% まで上昇します。
- プロセッサ キューの長さが常に 4 を超える (サーバーには 8 つのコアがある)
- SQL コンパイル/秒はバッチ リクエスト/秒の 25% でした (10% 未満である必要があります)
- SQL再コンパイル/秒はバッチリクエスト/秒の15%でした
解決手順
- DMVを使用してCPUを最も消費するクエリを特定しました
- 特定されたクエリの実行プランを分析した
- インデックスの欠落により、大きなテーブルで複数のテーブルスキャンが検出されました
- 実行プランの推奨事項に基づいて適切なインデックスを作成した
- 過剰なコンパイルを引き起こす動的SQLを特定しました
- パラメータ化されたクエリを使用するようにアプリケーション コードを変更しました
- 問題のあるストアド プロシージャのプラン ガイドを実装しました
- 頻繁に使用されるテーブルの統計情報を更新しました
結果： 営業時間中のCPU使用率は平均45%に低下しました。クエリ実行時間は70%改善され、アプリケーションの応答性も大幅に向上しました。
14.3 ケーススタディ: ディスクI/Oボトルネックの解決
症状の特定
ユーザーからは、データのロード操作中や夜間のバッチ処理中にアプリケーションの応答が非常に遅いという報告がありました。
カウンター分析
パフォーマンスデータは次のことを示しています:
- トランザクション ログ ドライブでの平均ディスク秒/書き込みが 45 ミリ秒を超えました
- データファイルドライブのディスクキューの長さは平均12です
- バッチジョブの実行中、ディスク時間の割合が何時間も 95% を超えていました
- ページ書き込み/秒は非常に高かった
解決手順
- メモリ設定が適切であることを確認しました。メモリの問題は見つかりませんでした。
- ディスク構成を分析 – 同じスピンドルセット上のすべてのファイルを検出
- トランザクションログを専用の高速 SSD ドライブに分離
- tempdbを別のSSDドライブに移動しました
- 複数の tempdb データ ファイルを実装しました (コアごとに 1 つ)
- データファイルドライブをRAID 10 SSD構成にアップグレード
- より小さなトランザクションバッチを使用するように最適化されたバッチジョブ
- バッチ操作中の不要なテーブルスキャンを削減するためにインデックスを追加しました
結果： 平均ディスク秒/書き込みが 3 ミリ秒に短縮されました。ディスク キューの長さの平均は 1 未満でした。バッチ ジョブの完了時間は 75% 短縮されました。
15. 今後の動向 SQL Server 監視
15.1 AIと機械学習の統合
人工知能と機械学習は変革を起こしている SQL Server パフォーマンスモニター。
予測分析
機械学習モデルは、過去のデータに基づいて将来のリソースニーズを予測します。これらのシステムでは、以下の予測が可能です。
- ストレージ容量が枯渇するとき
- ピーク時の予想されるCPUとメモリの要件
- ユーザーに影響を与える前にクエリパフォーマンスの低下を検知
- メンテナンス作業の最適な時間
異常検出
AI駆動型ツールは、パフォーマンス指標の異常なパターンを自動的に検出します。人間の管理者が見逃してしまう可能性のある異常を特定し、通常の変動と真の問題を区別します。
自動修復
自己修復システムは、一般的な問題が検出されると自動的に解決します。
- 停止したサービスを再起動します
- ピーク負荷時にリソースを再割り当てする
- 既知の問題に対する修正プログラムを適用する
- 断片化されたインデックスを自動的に再構築する
15.2 クラウドベースの監視の進化
クラウド監視は新しい機能とともに進化し続けています。
統合監視プラットフォーム
最新のプラットフォームは、以下を一元的に可視化します。
- オンプレミス SQL Server インスタンス
- クラウドホスト型データベース
- ハイブリッド環境
- アプリケーションのパフォーマンス
- インフラストラクチャメトリック
可観測性のトレンド
監視から観測可能性への移行では次の点が強調されます。
- 出力からシステムの動作を理解する
- メトリクス、ログ、トレースの相関関係
- 分散システムへの深い洞察
- リアルタイムの問題診断
15.3 自己修復データベースシステム
未来 SQL Server バージョンには、より多くの自律機能が含まれるようになります。
自動最適化
データベースは、次の方法で継続的に最適化されます。
- ワークロードに基づいてインデックスを自動的に作成および削除する
- 最適なパフォーマンスを得るための構成設定の調整
- 非効率なクエリを透過的に書き換える
- リソース割り当てを動的に管理する
インテリジェントチューニング
高度なシステムはパフォーマンス パターンを学習し、チューニングの推奨事項を自動的に適用するため、DBA による手動介入の必要性が軽減されます。
16. 結論と重要なポイント
16.1 必須モニタリングプラクティスの概要
効果的な SQL Server パフォーマンス モニターには、ツール、テクニック、ベスト プラクティスを組み合わせた包括的なアプローチが必要です。
クリティカルカウンターのまとめ
以下の重要なカウンターに監視の取り組みを集中させます。
- メモリ: ページ寿命、バッファキャッシュヒット率、保留中のメモリ許可
- CPU: % プロセッサ時間、プロセッサキューの長さ
- ディスク: 平均ディスク秒数/読み取りおよび書き込み、ディスクキューの長さ
- SQL Server: バッチリクエスト数/秒、コンパイル数/秒、ユーザー接続数
ベストプラクティスの概要
- 通常業務中にベースラインを確立する
- ベースラインに基づいてインテリジェントなアラートしきい値を設定する
- パフォーマンスデータを定期的に確認する
- 監視のオーバーヘッドとデータの粒度のバランスをとる
- 傾向分析のために長期データを保持する
- それぞれの監視シナリオに適したツールを使用する
16.2 継続的改善アプローチ
SQL Server パフォーマンス モニターは 1 回限りのアクティビティではなく、継続的な改良を必要とする継続的なプロセスです。
定期的なレビューサイクル
- 毎日: アラートと現在のパフォーマンスを確認する
- 毎週: 傾向を確認し、新たな問題を特定する
- 月次: 長期的なパターンと容量のニーズを分析
- 四半期ごと: ベースラインを更新し、監視の有効性を確認する
ツールを最新に保つ
監視ツールと技術を最新の状態に保ちます。
- 新しい監視機能を評価する SQL Server アップデート
- 新しいサードパーティツールをテストする
- 研修や会議に参加する
- 参加する SQL Server コミュニティフォーラム
- チームメンバーと知識を共有する
16.3 次のステップ
実施する SQL Server パフォーマンスを体系的に監視します。
実装ロードマップ
- Week 1： 必須カウンターを備えたパフォーマンスモニターを設定する
- Week 2： 自動収集用のデータコレクターセットを作成する
- Week 3： 通常業務中にベースラインを確立する
- Week 4： 重大なしきい値のアラートを設定する
- 月2： 追加の監視ツール（DMV、拡張イベント）を実装する
- 月3： カスタムダッシュボードとレポートを開発する
- 進行中： 経験と変化する要件に基づいて監視を改善する
その他のリソース
～について学び続ける SQL Server Microsoftのドキュメント、コミュニティブログ、実践的な演習を通じて、パフォーマンスモニターについて学びましょう。さまざまなツールとテクニックを試して、ご自身の環境に最適なものを見つけてください。
17. よくある質問 (FAQ)
17.1 最も重要なことは何ですか SQL Server 監視するパフォーマンス カウンターはありますか?
最も重要なのは SQL Server パフォーマンス カウンターには次のものが含まれます。
- メモリ: ページ寿命予測値（300秒以上）およびバッファキャッシュヒット率（99%以上）
- CPU: % プロセッサ時間 (持続値は 75% 未満) およびプロセッサ キューの長さ (コアあたり 2 未満である必要があります)
- ディスク: 平均ディスク秒数/読み取りおよび書き込み (<10 ～ 20 ミリ秒) およびディスク キューの長さ (ディスクあたり <2 である必要があります)
- SQL Server: バッチリクエスト/秒、SQLコンパイル/秒、および保留中のメモリ許可（0である必要があります）
これらのカウンターは、システムの健全性に関する包括的な洞察を提供し、ボトルネックを迅速に特定するのに役立ちます。
17.2 パフォーマンス データをどのくらいの頻度で収集する必要がありますか?
収集頻度は監視の目的によって異なります。
- ベースライン監視: 1分（60秒）ごと
- アクティブなトラブルシューティング: 短時間、15～30秒ごと
- 長期トレンド: 5分ごと
高頻度の収集を継続的に実行すると、パフォーマンスが低下し、過剰なデータが生成される可能性があります。定期的な監視には長い間隔を使用し、特定の問題を調査する場合のみ短い間隔を使用してください。
17.3 パフォーマンスモニターとの違いは何ですか？ SQL Server プロファイラー？
パフォーマンスモニターと SQL Server プロファイラーはさまざまな目的に使用されます:
パフォーマンスモニタ：
- システムを監視し、 SQL Server パフォーマンスカウンター
- リソース使用率（CPU、メモリ、ディスク）を追跡します
- オーバーヘッドが低く、継続的な監視に適しています
- 時間の経過に伴う集計指標を提供します
SQL Server プロファイラー:
- 個々の痕跡 SQL Server イベントとクエリ
- 詳細なクエリ実行情報を取得します
- オーバーヘッドが高く、継続的な使用には推奨されません
- 特定のクエリの問題のトラブルシューティングに最適
- 拡張イベントを優先するため非推奨
システム全体の監視にはパフォーマンス モニターを使用し、詳細なクエリ レベルの分析には拡張イベント (プロファイラーではない) を使用します。
17.4 パフォーマンスモニターの影響 SQL Server パフォーマンス？
適切に設定されていれば、パフォーマンスモニターは最小限の影響しか与えません。 SQL Server パフォーマンスは通常2%未満のオーバーヘッドです。ただし、過剰な監視は問題を引き起こす可能性があります。
- カウンターが多すぎるとオーバーヘッドが増加する
- 非常に短いサンプル間隔（15秒未満）のひずみリソース
- 継続的な高頻度収集により大きなログファイルが生成される
影響を最小限に抑えるには:
- 必要なカウンターだけを監視する
- 適切なサンプル間隔を使用してください（定期的なモニタリングの場合は60秒）
- ログをデータベースファイルとは別のドライブに保存する
- オフピーク時にリソースを集中的に使用する監視をスケジュールする
17.5 パフォーマンス監視データはどのくらいの期間保持する必要がありますか?
保持期間は分析のニーズとストレージ容量によって異なります。
- 最小： 最近の問題のトラブルシューティングに3か月
- 推奨： キャパシティプランニングとトレンド分析に1～2年
- 最適な： 履歴データは時間の経過とともに価値が増すため、保存できる場合は無期限に保存できます。
パフォーマンスカウンターデータは圧縮率が高く、比較的少ない容量で保存できます。古いデータは削除するのではなく、別のストレージにアーカイブすることを検討してください。多くの組織では、長年にわたる履歴データがキャパシティプランニングや長期的な傾向の特定に非常に役立つことが分かっています。
17.6 主要なパフォーマンス カウンターの適切なしきい値は何ですか?
警告の推奨しきい値:
- メモリ許可保留: > 0 の場合に警告
- ページの寿命: 300秒未満の場合アラート
- % プロセッサ時間: 5 分間 80% を超えると警告
- プロセッサキューの長さ: コアあたり 2 を超える場合に警告
- 平均ディスク秒/読み取りまたは書き込み: 20msを超えるとアラート
- ディスクキューの長さ: ディスクあたり 2 を超える場合に警告
- ブロックされたプロセス: 5を超えると警告
これらのしきい値は、ベースラインデータと特定のワークロード特性に基づいて調整してください。ある環境では正常であっても、別の環境では問題を示している可能性があります。
17.7 監視方法 SQL Server リモートでパフォーマンスできますか?
モニターリモコン SQL Server これらのメソッドを使用するインスタンス:
- パフォーマンスモニタ： カウンターを追加するときにリモート コンピュータ名を指定します
- パワーシェル： Get-Counterで-ComputerNameパラメータを使用する
- DMV: SSMS を介してリモート サーバーに接続し、DMV をクエリする
- サードパーティ製ツール: ほとんどの監視ツールはリモートサーバーの監視をサポートしています。
ファイアウォールルールでパフォーマンスモニターのトラフィックが許可されていること、およびリモートサーバーに対する適切な権限があることを確認してください。複数のサーバーがある場合は、専用の監視サーバーとデータベースを使用した集中監視の実装を検討してください。
17.8 最高の無料ツールは何ですか？ SQL Server パフォーマンスモニター?
監視には優れた無料ツールがいくつか利用可能 SQL Server パフォーマンス：
- Windows パフォーマンス モニター: 組み込み、包括的、信頼性
- SSMS アクティビティ モニター: 追加インストールなしでリアルタイム監視
- 拡張イベント: 軽量イベント監視機能を搭載 SQL Server
- sp_WhoIsActive: 詳細なアクティビティ監視のための人気の無料ストアドプロシージャ
- DBA ダッシュ: 包括的な機能を備えたオープンソースの監視ツール
- SQLウォッチ: ほぼリアルタイムの監視機能を備えたオープンソース
ほとんどの組織にとって、パフォーマンスモニターをSSMSツールおよびsp_WhoIsActiveと組み合わせることで、追加費用なしで優れた監視機能を利用できます。
17.9 分析用に PerfMon データをエクスポートするにはどうすればよいですか?
次の方法を使用してパフォーマンス モニターのデータをエクスポートします。
CSV にエクスポート:
- ログファイルを読み込んだ状態でパフォーマンスモニターを開きます
- グラフを右クリックして選択 名前を付けてデータを保存
- 選択する テキストファイル（カンマ区切り）（.csv）
- 場所を選択して保存
- Excelで開いて分析する
再ログコマンドを使用する:
relog input.blg -f csv -o output.csv
このコマンドライン ユーティリティは、バイナリ ログ ファイル (.blg) を CSV 形式に変換し、スプレッドシート アプリケーションでの分析を容易にします。
17.10 組み込みオプションの代わりにサードパーティの監視ツールを使用する必要があるのはどのような場合ですか?
次の場合はサードパーティ製ツールを検討してください。
- 多数の SQL Server インスタンス（10以上）
- 複数のデータセンターにわたる集中監視が必要
- 予測分析や異常検出などの高度な機能が必要
- インシデント管理システムとの統合アラートを希望
- コンプライアンス報告と履歴分析の要求
- カスタムソリューションを構築および維持するための DBA リソースが不足している
- 異機種データベース環境の監視（SQL ServerOracle、MySQLなど）
組み込みツールは、小規模な環境や、カスタム監視ソリューションを開発できる熟練したDBAがいる場合に適しています。サードパーティ製ツールは、時間の節約、高度な機能、そしてプロフェッショナルなサポートといった価値を提供します。
18.追加リソース
18.1 公式ドキュメント
Microsoftは、以下の詳細なドキュメントを提供しています。 SQL Server パフォーマンスモニター:
- SQL Server パフォーマンス モニターのドキュメント: https://learn.microsoft.com/en-us/sql/relational-databases/performance-monitor/
- 動的管理ビュー: https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/
- 拡張イベント: https://learn.microsoft.com/en-us/sql/relational-databases/extended-events/
- クエリストア: https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store
- パフォーマンスのチューニングと監視: https://learn.microsoft.com/en-us/sql/relational-databases/performance/
18.2 推奨ツールとダウンロード
必須ツール SQL Server パフォーマンスモニター:
- PALツール: https://github.com/clinthuffman/PAL
- sp_WhoIsActive: http://whoisactive.com/
- DBA ダッシュ: https://dbadash.com/
- SQLウォッチ: https://github.com/marcingminski/sqlwatch
- ファースト レスポンダー キット (ブレント オザー): https://www.brentozar.com/first-aid/
- SQL Server Management Studio： https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms
18.3 コミュニティリソース
から学ぶ SQL Server コミュニティ：
- SQL Server 中央： https://www.sqlservercentral.com/
- ブレント・オザールのブログ: https://www.brentozar.com/blog/
- SQL シャック: https://www.sqlshack.com/
- MSSQLヒント: https://www.mssqltips.com/
- Reddit r/SQLServer: https://www.reddit.com/r/SQLServer/
- スタックオーバーフロー SQL Server タグ： https://stackoverflow.com/questions/tagged/sql-server
これらのリソースは、経験豊富な専門家によるチュートリアル、トラブルシューティングのアドバイス、ベストプラクティスを提供します。 SQL Server 専門家。コミュニティフォーラムに参加することで、他の人の経験から学び、自分の知識を共有することができます。
著者について
袁勝 10年以上の経験を持つ上級データベース管理者（DBA）です。 SQL Server 環境およびエンタープライズデータベース管理に精通しており、金融サービス、医療、製造業など、様々な組織において数百件のデータベース復旧シナリオを解決してきました。
ユアンの専門は SQL Server データベースの復旧、 高可用性ソリューション、パフォーマンスの最適化など、幅広い実務経験を有しています。彼の豊富な実務経験には、マルチテラバイトデータベースの管理、 Always On 可用性グループ、ミッションクリティカルなビジネス システム向けの自動バックアップおよびリカバリ戦略を開発します。
Yuanは、技術的な専門知識と実践的なアプローチを通じて、データベース管理者やITプロフェッショナルが複雑な問題を解決するのに役立つ包括的なガイドの作成に重点を置いています。 SQL Server 効率的に課題に取り組みます。常に最新の SQL Server リリースと Microsoft の進化するデータベース テクノロジを活用し、定期的にリカバリ シナリオをテストして、推奨事項が実際のベスト プラクティスを反映していることを確認します。
について質問があります SQL Server 回復または追加のデータベーストラブルシューティングガイダンスが必要ですか？Yuanは歓迎します フィードバックと提案 これらの技術リソースを改善するためです。