実際の戦闘ケースの共有を待機する高いログファイル同期パフォーマンスの最適化

障害状態

AWR は次のように報告しています。

 

 

 

 

ビジネスの大部分が停止された後も、ログ ファイルの同期待機イベントは依然として非常に多くなっています。

昨日と今日の同じ時間の AWR を比較すると、ビジネス量が非常に少ない場合、待ち時間が依然として非常に長いことがわかります。

診断プロセス

ログファイル同期待機イベントは、まず現在のシステム IO に問題があるかどうかを判断し、関連するエラーがないかオペレーティング システム ログをチェックして、IO テストを実行します。また、IO が正常な状態であることを示し、AWR をチェックします。 AWR は、データベースの書き込み IO と読み取り IO が比較的良好で正常であることを示しています。昨日の AWR レポートと今日の AWR レポートを比較すると、IO の読み取りおよび書き込みのパフォーマンスが昨日とあまり変わらないことがわかります。今日収集された期間は、ビジネスの大部分が停止したためです。IO は昨日よりも優れています。ただし、ログ切り替えの待ち時間が発生するため、その代わりに時間が 8 秒増加します。

 シニア Tanel Poder が作成した診断マニュアル「ログ ファイル同期、LGWR」のコミット ログ ファイル同期フローによると

 

上の図から、コミット プロセス全体がはっきりとわかります。

1. ユーザーがコミットを開始するとき。

2. フロントエンド プロセス (つまり、サーバー プロセス) は、lgwr プロセスにメッセージをポストし、REDO バッファーに書き込むように指示します。

3. LGWR プロセスが指示されると、物理書き込みを実行するためにオペレーティング システムの関数の呼び出しが開始されますが、物理書き込みの間、ログ ファイルの並列書き込み待ちが発生します。

4. LGWR が書き込み操作を完了すると、LGWR プロセスはフロントエンド プロセス (サーバー プロセス) にメッセージを返し、私が書き込みを終了したので送信を完了できることを伝えます。

5. ユーザーはコミット操作を完了します。

上記のフローチャートから、AWR におけるログ ファイルの並列書き込み、ユーザー IO、システム IO の待ち時間が短いことと合わせて、問題は IO パフォーマンスにあるものではないと判断できます。その場合、問題はステージ 2 とステージ 5 にあるはずです。

Mosの記事によると:

トラブルシューティング: 「ログ ファイルの同期」が待機する (Doc ID 1376916.1)

適応型ログファイル同期の最適化 (Doc ID 1541136.1)

ログ書き込みメソッド間の適応的な切り替えにより、「ログ ファイル同期」の待機が発生する可能性があります (Doc ID 1462942.1)

Oracle11g の発見後、Oracle はアダプティブ方式と呼ばれる新しいログ同期方式を導入しました。これは Oracle 11.2.0.3 バージョン以降で有効になります。

最初に、LGWR は post/wait を使用し、内部アルゴリズムに従ってポーリングの方が優れているかどうかを評価します。システム負荷が高い場合、post/wait 実装は通常、適切に拡張できないため、ポーリングのパフォーマンスが向上する可能性があります。システム負荷が低い場合、post/wait は良好なパフォーマンスを発揮し、ポーリングよりも優れた応答時間を実現します。Oracle は内部統計に基づいて、どの方法を使用するかを決定します。post/wait とポーリングの間の切り替えにはオーバーヘッドが発生するため、切り替えが頻繁に行われないように安全対策が講じられています。

資料の記載によれば、システムの負荷を確認したところ、本日14時の時点で業務システムが高負荷となっており、ログスイッチが136回に達し、その後正常に戻ったとのことです。

 

現在のシステムを確認し、現在のシステムLGWRがポーリング方式を使用していることを確認します

SQL> select name,value from v$sysstat where name in ('redo synch poll writes','redo synch polls');

同期ポーリング書き込みをやり直します 6248

同期ポーリングをやり直す 8843

故障原因の分析

14 時に業務システムの負荷が非常に高くなるため、Oracle は高いパフォーマンスを維持するために LGWR 書き込みモードをポーリングモードに切り替えますが、業務負荷が低下すると、通常の状況ではLGWR は元のPost/Theに切り替える必要があります。wait 方式ですが、今回はスイッチがなく、ポーリング方式が使用されています。バグがあると判断され切り替えが行われないためパフォーマンスが低下しますオンライン記事のポーリング間隔は10ms、Post/wait の間隔は1~2msです。mosの記事は見つかりません)今回書いた人)

関連するバグ:

 

バージョン 11.2.03 では、DATABASE PATCH SET UPDATE 11.2.0.3.14 (CPUAPR2015 を含む) を適用すると、このバグを解決できます。

解決

回避策

「_use_adaptive_log_file_sync」=false を設定して、アダプティブ ログ ファイル同期を無効にします。

ALTER SYSTEM SET "_use_adaptive_log_file_sync"=FALSE ;

または、インスタンスを再起動することで解決することもあります。

おすすめ

転載: blog.csdn.net/m0_37723088/article/details/130998306