SQL Server ディスク要求タイムアウト 833 エラーの原因と解決策_MsSql

この記事では、SQL Server ディスク要求タイムアウトの 833 エラーの原因と解決策を主に紹介します。必要な友達は参考にしてください。

最近、SQL Server サーバーの応答が非常に遅く、クライアント要求でエラーが発生しました。データベース内 ディスク要求が完了するまでに 15 秒以上かかったというエラー メッセージがエラー ログに表示されます。

この種の問題の場合、ストレージ システムやディスクの障害なのか、SQL Server 自体の問題なのか、それともアプリケーションが原因なのか?どうやって解決すればいいでしょうか？

この記事では、この問題を引き起こす特定の要因の簡単な分析を行いますが、潜在的な可能性をすべてカバーできるわけではないため、同様の問題が発生した場合は、具体的な分析を行う必要があります。

SQL Server のディスク リクエスト タイムアウト

英語版のエラー エラー メッセージ は次のとおりです:

SQL Server で %d 回の I/O リクエストが発生し、%d を超える時間がかかりましたデータベース ID %d のファイル [%ls] の完了まで秒です。OS ファイル ハンドルは 0x%p です。0
最新のロング I/O のオフセットは %#016I64x

中国語版のエラー メッセージは次のとおりです。以下の通り

SQL Server は、データベース ID %4! のファイル [%3!] に対して、完了までに %2! 秒以上かかる I/O 要求を検出しました。オペレーティング システムのファイル ハンドルは 0x%5! です。最新の長期 I/O のオフセットは %6!

メッセージ情報のエラーメッセージ No.833 を参照

具体的な 833 エラーアプリケーションディスクリクエストタイムアウト現象

具体的なエラー状況は次のとおりです:

SQL Server はデータベース n 内のファイル *** に対する m 個の I/O 要求を検出しましたが、完了するまでに 15 秒以上かかりました。オペレーティング システムのファイル ハンドルは *** です。最新の長期 I/O オフセットは次のとおりです: ***

つまり、データベース ファイルの自動拡張中にエラーが発生しました。

。

さらに興味深いのは、DBA がこのエラー メッセージをストレージ システムの障害または不安定性が原因である可能性があると考え、ストレージ (接続されたディスクではなく SAN ストレージ) を担当するエンジニアに報告したことです。

ストレージ エンジニアはストレージに問題はないと思ったが、サーバーを確認したところ、サーバーが異常でメモリが「ほぼ満杯」だったという。ストレージを担当するエンジニアが専門の DBA ではないことを考慮すると、SQL Server データベース サーバーのメモリ使用量についてあまり詳しくない可能性があるため、この質問をするのは当然のことです。

データベースサーバーが使用するストレージは高性能のSANストレージであるため、ストレージはサービスとして存在し、他のサーバーでディスクリクエストが発生する可能性は低いです。ストレージ障害」は、単にストレージ障害として識別されます。

それでは、その理由は何でしょうか？

データベースエンジンエラー833の意味

まず、この833エラーの具体的な意味を見てみましょう。これは古典的な本に非常に明確に書かれています。

要するに、SQL Server がディスクの読み取りと書き込みを要求したときに、ビジーなディスクまたはその他の要因が発生し、15 秒以上完了していないことを意味します
たとえば、データの読み取りと書き込みの場合、多忙またはその他の問題により、応答が遅すぎるか、応答が十分にタイムリーではありません。これは間違いなく SQL Server の外部サーバーの応答時間に重大な影響を及ぼします。

上記は単純な分析です。この問題は一般的ではなく、ストレージ システムに問題がある可能性は低いため、現在のサーバー自体の要因を突き止める可能性が非常に高くなります。

原因分析

専用の SQL Server サーバーであるため、他のアプリケーションからのリクエストはなく、おそらく sqlserver データベースへのリクエストに関連しています。

実際、この問題が発生する前に、サーバーは通常非常に安定しています (CPU が 60% を超えることはほとんどなく、メモリの PLE は 20 分以上安定しており、ディスク IO 遅延は低いなど)。 .)、しかし、時々、しばらくの間、けいれんが発生します

けいれんが発生すると、CPU が約 80% に急上昇し、メモリの PLE が大幅に低下し、IO 遅延が大幅に増加します。

SQL Server の Session からのみ開始できます。SQL Server でアクティブなセッションを観察すると、特定の種類の SQL ステートメントの query 時間が非常に長いことがわかりました。一定期間内の SQL クエリ 内部実行の頻度は比較的高いです。

しかし、通常の状況では、この種の SQL の実行効率はまだ比較的高いのに、なぜ突然非常に低くなるのでしょうか。

アクティブなセッションの対応する実行計画を確認したところ、このタイプのアクティブなセッションの待機ステータスは IO 待機 (PAGEIOLATCH_SH) であり、SQL の実行は完全に予期しないことがわかりました。

同様のクエリが比較的頻繁に実行されるため、SQLの実行効率が低下すると、そのようなSessionがサーバー上に大量に蓄積されることになります

なぜSQL文は正常に実行されるのでしょうか？突然非常に遅くなりました

その理由は、ある時点で SQL Server が統計情報の update を自動的にトリガーしたためです。これは比較的大きなテーブルですが、統計情報の更新のためのデフォルトのサンプリング率では十分ではありません、サンプリング率が十分でない場合、この統計情報は完全に利用できません。

統計情報の自動収集が完了すると、現在収集されている統計情報に基づいて、前の SQL ステートメントに対して効率的であると思われる方法 (インデックス シークではなくテーブル スキャン) を発行します。実際には、この方法は合理的ではありません。
これにより、対応する SQL がクエリを実装するために不当な実行プランを使用することになり、クライアントが大量のセッションを送信し、非効率な方法で実行が遅くなります。

そのため、CPU が急増し、IO レイテンシが増加し、メモリの PLE が大幅に低下します。

これを理解するのは難しくありません。何十ものクエリセッションが不当な方法でディスクにリクエストを行っており、ディスクはアクティブなセッションからのデータリクエストでビジー状態であり、データまたは index ファイルが原因で応答できません。自動拡張リクエストにより、冒頭で述べた問題が発生しました。

最終的には、インデックスの再構築により解決しました（統計情報の更新を促進する、もちろん純粋な統計情報の更新も可能です）。長期的な予防のためには、閾値とサンプリング率を人為的に定義するジョブを手配する必要があります。統計情報更新のお知らせです。

概要:

データベースサーバーの問題の多くは、観察された現象の一部に対応して連鎖反応プロセスであり、その反応は表面に現れているものとは異なる可能性が非常に高くなります (ディスク要求のタイムアウト、問題はストレージのせい？これらは問題の根本的な原因ではありません。
問題に直面したとき、私たちは根源に立ち返り、最も根本的な原因を見つけなければなりません。それが問題解決の鍵となります。

以上がSQL Server ディスク要求タイムアウト 833 エラーの原因と解決策_MsSqlの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。