[Oracle] REDOログ関係の待機イベント | Archive Redo Blog

Archive Redo Blog

DBエンジニアのあれこれ備忘録

大量のデータを更新した時、V$SYSTEM_EVENT、V$SESSION_EVENT、Statspackレポート、AWRレポートなどを参照すると、REDOログ関係の待機イベントが上位に出現しやすくなります。

とりわけ上位に出現しやすいのは以下の2つでしょうか。

log file parallel write
ログ・ファイルへの書き込み待ちです。
ログ・バッファからログファイルへのデータの書き込みに物理I/Oが追いついていない時に発生します。
この待機イベントは、ログ・ファイルへのI/Oを高速化するか、無駄なデータの更新によるログ・ファイルへの書き込みを減らすことにより改善します。
log buffer space
ログ・バッファへの書き込み待ちです。
セッションからログ・バッファへのデータの書き込みに、ログ・バッファからログ・ファイルへのデータの書き込みが追いついていない時に発生します。
この待機イベントは、ログ・バッファを拡張する(初期化パラメータ'log_buffer'のサイズを大きくする)か、log_file_parallel_writeと同様のアプローチで改善します。

この2つの待機イベントは、いずれもREDOログの書き込み時(つまりデータの更新時)に発生する待機イベントで、待ちが発生している箇所が違うだけです。


その他、REDOログ関係では以下のような待機イベントも発生します。

log file sync
セッションとLGWRの同期待ちです。(OLTP系の処理で発生しやすいようです。)
log file parallel writeと同様のアプローチで改善します。
log file switch ~
ログ・スイッチに関する待ちです。(待ちが発生する状況・タイミングによって、待機イベントが細かく分けられています。)
ログ・スイッチの回数(アラートログやV$LOGHISTを参照)が多くてこの待機イベントが多発している場合は、ログファイルのサイズを大きくすることによって改善します。
※ログ・スイッチはチェックポイント処理を伴うため、ログ・スイッチの回数が多い場合は、データファイルや制御ファイルへの書き込み待ちイベントを併発する可能性も高くなります。
log file sequential read
ログ・ファイルからの読み取り待ちです。


物理I/Oの効率やREDOログのデータ量については改善が困難なケースも多いですが、綿密な設計を行っていない環境では、ログ・バッファやログファイルの不足によって待機イベントが多発し、データ更新のパフォーマンスに深刻な影響を与えている可能性も多いと思われますので、データ更新が遅いと感じたらこれらの待機イベントをチェックしてみるべきかと思います。



これらの待機イベントについては、以下のサイトの検証報告が大変参考になります。

インサイトテクノロジー ☆おら!オラ!Oracle -どっぷり検証生活-★
<待ちイベントに関する検証 その9>
<待ちイベントに関する検証 その10>


また、REDOログに関する問題の切り分けについては、以下の記事が参考になります。

@IT Oracleパフォーマンス障害の克服(6) 気付きにくいREDOログの問題切り分けテクニック