適用対象: SQL Server
SQL Server インスタンスまたは特定のアプリケーションに対してクエリを実行すると、すべてのクエリが遅くなります。 この問題を解決するには、次の手順に従います。
手順 1: アプリケーションの問題のトラブルシューティング
アプリケーション レイヤーを確認します。 アプリケーションからクエリを実行し、SQL Server インスタンスで手動で実行し、その実行方法を確認します。 この方法で複数のクエリをテストします。 SQL Server インスタンスでのクエリの速度が速い場合は、アプリケーションまたはアプリケーション サーバーのレイヤーに問題がある可能性があります。
Note
データベース アプリケーションと SSMS のクエリのパフォーマンスの違いに注意してください。
アプリケーションが別のサーバーで実行されている場合は、アプリケーション サーバーのパフォーマンスを確認します (トラブルシューティングについては、「 手順 2: OS の問題のトラブルシューティング を参照してください)。 場合によっては、アプリケーション開発チームに問い合わせて、アプリケーションに関する問題を確認する必要があります。
手順 2: OS の問題のトラブルシューティング
SQL Server が実行されているオペレーティング システムの応答が遅くなっているかどうかを確認します。 たとえば、マウスの移動が遅い、ウィンドウが長時間応答しない、サーバーへのリモート デスクトップ アクセスが遅い、サーバー上の共有への接続が遅いなどです。
この問題は、別のサービスまたはアプリケーションによって発生する可能性があります。 Perfmon を使用してトラブルシューティングを行います。
その他の OS パフォーマンスの問題については、 Windows Server のパフォーマンスのトラブルシューティングに関するドキュメントを参照してください。
次のような一般的な問題があります。
この問題は、システム上で実行されている他のアプリケーション、OS、またはドライバーによって発生する可能性があります。
この問題をトラブルシューティングするには、タスク マネージャー、パフォーマンス モニター、またはリソース モニターを使用してこの問題を特定します。 詳細については、「 CPU 使用率の高いトラブルシューティング ガイダンスを参照してください。
手順 3: ネットワークの問題のトラブルシューティング
この問題はネットワーク層内にあり、アプリケーションと SQL Server の間の通信が遅くなる可能性があります。 この問題をトラブルシューティングするには、次の方法を使用します。
その症状の 1 つは、SQL Server 側で待機
ASYNC_NETWORK_IO可能性があります。 詳細については、「 待機の種類ASYNC_NETWORK_IO起因する低速クエリのトラブルシューティングを参照してください。ネットワーク管理者と協力して、ネットワークの問題 (ファイアウォール、ルーティングなど) を確認します。
network トレースを収集しネットワーク リセットイベントと再送信イベントを確認します。 アイデアのトラブルシューティングについては、「 Intermittent または定期的なネットワークの問題を参照してください。
Perfmon カウンターを有効にして、ネットワーク インターフェイス レベル (NIC) でネットワーク パフォーマンスを確認します。 破棄されたパケットとエラー パケットはゼロにする必要があります。 ネットワーク インターフェイスの帯域幅を確認します。
- ネットワーク インターフェイス\パケット受信破棄済み
- ネットワーク インターフェイス\パケット受信エラー
- ネットワーク インターフェイス\パケット送信破棄済み
- ネットワーク インターフェイス\パケット送信エラー
- Network Interface\Bytes Total/Sec
- ネットワーク インターフェイス\現在の帯域幅
手順 4: SQL Server での CPU 使用率の高いトラブルシューティング
CPU を集中的に使用するクエリがシステムで実行されている場合、他のクエリの CPU 容量が不足する可能性があります。 ただし、より頻繁に、クエリからの CPU 使用率が高い場合は、クエリを最適化する必要があることを示している可能性があります。 問題のトラブルシューティングを行うには、次の手順に従います。
- まず、SQL Server が CPU 使用率の高い原因になっているかどうかを調べる (Perfmon カウンターを使用)。
- CPU 使用率に影響するクエリを特定します。
- 統計情報を更新する。
- 不足しているインデックスを追加します。
- パラメーターに依存する問題を調査して解決します。
- SARGability の問題を調査して解決します。
- 重いトレースを無効にします。
- スピンロック
SOS_CACHESTORE競合を修正しました。 - 仮想マシンを構成します。
- CPU を追加してシステムをスケールアップします。
詳細なトラブルシューティング手順については、「 SQL Server での CPU 使用率の高い問題をトラブルシューティングするを参照してください。
手順 5: SQL Server で過剰な I/O が原因で低速になる問題をトラブルシューティングする
SQL Server ワークロードの全体的な遅さが認識されるもう 1 つの一般的な理由は、I/O の問題です。 I/O の速度低下は、システム上のほとんどのクエリまたはすべてのクエリに影響を与える可能性があります。 次の方法を使用して問題のトラブルシューティングを行います。
-
- SAN の構成ミス (スイッチ、ケーブル、HBA、ストレージ)。
- I/O 容量を超えました (バックエンド ストレージだけでなく、SAN ネットワーク全体で不均衡です。SAN を共有するすべてのサーバーの I/O スループットを確認します)。
- ドライバーまたはファームウェアの問題または更新プログラム。
I/O 要求で大量の I/O とディスク ボリュームの飽和を引き起こしている最適でない SQL Server クエリを確認します。
- 多数の論理読み取り (または書き込み) を引き起こしているクエリを見つけ、適切なインデックスを使用してディスク I/O を最小限に抑えるためにそれらのクエリを調整するのが最初の手順です。
- 最適なプランを選択するのに十分な情報がクエリ オプティマイザーに提供されるため、統計は更新された状態に保ちます。
- クエリやテーブルの再設計は、I/O の向上に役立つ場合があります。
フィルター ドライバー: ファイル システム フィルター ドライバーが大量の I/O トラフィックを処理する場合、SQL Server I/O 応答に重大な影響を与える可能性があります。
- ウイルス対策スキャンからデータ フォルダーを除外し、ソフトウェア ベンダーによるフィルター ドライバーの問題を修正して、I/O パフォーマンスへの影響を防ぎます。
その他のアプリケーション: SQL Server を使用する同じコンピューター上の別のアプリケーションは、過剰な読み取りまたは書き込み要求で I/O パスを飽和させる可能性があります。 この状況では、容量制限を超えて I/O サブシステムがプッシュされ、SQL Server の I/O 速度が低下する可能性があります。 アプリケーションを特定してチューニングするか、別の場所に移動して、I/O スタックへの影響を排除します。 この問題は、他のマシンで実行されているが、この SQL Server マシンと同じ SAN を共有しているアプリケーションによっても発生する可能性があります。 SAN 管理者と連携して、I/O トラフィックのバランスを取ります (ハードウェアの問題の確認 を参照してください)。
SQL Server に関する I/O 関連の問題の詳細なトラブルシューティングについては、「 I/O の問題が原因で SQL Server のパフォーマンスが低下するをトラブルシューティングする」を参照してください。
手順 6: メモリの問題のトラブルシューティング
システム全体または SQL Server 内のメモリが不足すると、クエリがメモリ許可 (RESOURCE_SEMAPHORE) またはコンパイル メモリ (RESOURCE_SEMAPHORE_QUERY_COMPILE) を待機しているときに、速度が低下する可能性があります。 次の方法を使用して問題のトラブルシューティングを行います。
Perfmon カウンターを使用して、OS レベルで外部メモリを確認します。
- Memory\Available MBytes
- Process(*)\Working Set (すべてのインスタンス)
- Process(*)\Private Bytes (すべてのインスタンス)
内部メモリ不足の場合は、SQL Server クエリを使用して sys.dm_os_memory_clerks クエリを実行するか、 DBCC MEMORYSTATUS を使用します。
SQL Server エラー ログで、 701 エラーを確認します。
詳細なトラブルシューティング手順については、「 SQL Server のメモリ不足またはメモリ不足の問題をトラブルシューティングするを参照してください。
手順 7: ブロックの問題のトラブルシューティング
ロックの取得は、データベース システム内のリソースを保護するために使用されます。 ロックが長時間取得され、その他のセッションがそれらのロックを待機する場合は、ブロックシナリオに直面します。
ショート ブロッキングは、SQL Server などのデータベース システムで常に発生します。 ただし、ブロックが長時間続くと、特にほとんどのクエリまたはすべてのクエリがロックを待機している場合は、サーバー全体が応答していないと認識される可能性があります。
問題のトラブルシューティングを行うには、次の手順に従います。
DMV 出力の列
blocking_session_idまたはストアド プロシージャ出力の列BlkBysys.dm_exec_requests調べることで、ヘッド ブロッキング セッションsp_who2識別します。ヘッド ブロッキング チェーンが実行するクエリ (長時間ロックを保持しているもの) を見つけます。
ヘッド ブロッキング セッションでアクティブに実行されているクエリがない場合は、アプリケーションの問題が原因で孤立したトランザクションが発生している可能性があります。
ヘッド ブロッキング クエリを再設計または調整して、実行速度を上げるか、トランザクション内のクエリの数を減らします。
クエリで使用されるトランザクションの分離を調べて調整します。
ブロックシナリオの詳細なトラブルシューティングについては、「 SQL Server のブロックの問題を理解して解決するを参照してください。
手順 8: スケジューラの問題のトラブルシューティング (非生成、デッドロックされたスケジューラ、非生成 IOCP リスナー、リソース モニター)
SQL Server では、協調スケジューリング メカニズム (Schedulers) を使用して、CPU 上のスケジュール設定のためにスレッドを OS に公開します。 SQL スケジューラに関連する問題がある場合、SQL Server スレッドはクエリ、ログイン、ログアウトなどの処理を停止する可能性があります。 その結果、影響を受けるスケジューラの数によっては、SQL Server が応答しない、部分的または完全に見える場合があります。 スケジューラの問題は、製品のバグ、外部ドライバーとフィルター ドライバー、ハードウェアの問題など、さまざまな問題が原因で発生する可能性があります。
これらの問題をトラブルシューティングするには、次の手順に従います。
SQL Server からの応答不足が報告された時点で、SQL Server エラー ログで次のようなエラーがないか確認します。
-
*********************************************** * * BEGIN STACK DUMP: * 03/10/22 21:16:35 spid 22548 * * Non-yielding Scheduler * *********************************************** -
********************************************** * * BEGIN STACK DUMP: * 03/25/22 08:50:29 spid 355 * * Deadlocked Schedulers * * ******************************************** -
* ******************************************************************************* * * BEGIN STACK DUMP: * 09/07/22 23:01:04 spid 0 * * Non-yielding IOCP Listener * * ******************************************************************************* -
* ******************************************** * * BEGIN STACK DUMP: * 07/25/22 11:44:21 spid 2013 * * Non-yielding Resource Monitor * * ********************************************
-
これらのエラーのいずれかが発生した場合は、使用している SQL Server の累積的な更新プログラム (CU) のバージョンを特定します。 現在の CU の後に出荷された CU に修正された問題があるかどうかを確認します。 SQL Server の修正については、「 現在サポートされているバージョンの SQL Server で使用可能な最新の更新プログラムを参照してください。 詳細な修正リストについては、この Excelファイルをダウンロードできます。
SQL Server のスケジュール設定と生成を使用して、より多くのアイデアを得られます。
デッドロック スケジューラにつながる可能性がある大量のブロック シナリオまたは大規模な並列処理クエリを確認します。 詳細については、「 デッドロックされたスケジューラのタオ」を参照してください。
生成されない IOCP リスナーの場合は、システムのメモリが不足していて、SQL Server がページ アウトされているかどうかを確認します。もう 1 つの理由は、ウイルス対策または侵入防止ソフトウェアが I/O API 呼び出しをインターセプトし、スレッド アクティビティを遅くする可能性があります。 詳細については、「 IOCP リスナーが実際にリッスンしているか」を参照してください。 と 特定のモジュールまたはフィルター ドライバーが読み込まれるときのパフォーマンスと整合性の問題。
リソース モニターの問題の場合、場合によっては必ずしもこの問題に関係しているとは限りません。 詳細については、「 リソース モニターが SQL Server を実行しているサーバーで非生成条件を入力するを参照してください。
これらのリソースが役に立たない場合は、\LOG サブディレクトリで作成されたメモリ ダンプを見つけ、分析のためにメモリ ダンプをアップロードして Microsoft CSS でサポート チケットを開きます。
手順 9: リソースを集中的に使用するプロファイラーまたは XEvent トレースを探す
アクティブな拡張イベントまたはSQL Server プロファイラー トレースを探します。特に、テキスト列 (データベース名、ログイン名、クエリ テキストなど) をフィルター処理しているトレースを探します。 可能であれば、トレースを無効にして、クエリのパフォーマンスが向上するかどうかを確認します。 選択したイベントによっては、各スレッドが追加の CPU を消費して全体的な速度低下を引き起こす可能性があります。 拡張イベントのアクティブなトレースを識別するには、「 sys.dm_xe_sessions と Profiler トレース」を参照してください。 sys.tracesを参照してください。
SELECT * FROM sys.dm_xe_sessions
GO
SELECT * FROM sys.traces