パフォーマンスセラピー / REDOログ・バッファのチューニングを学ぶ

Oracleチューニング講座

第17章　REDOログ・バッファのチューニングを学ぶ

本章ではREDOログ・バッファのチューニングについて復習します。
Oracleの動作として、変更されたデータが障害によって損失しないように、変更履歴を取得しています。
変更履歴は一時的にREDOログ・バッファに保持され、オンラインREDOログ・ファイルに書き込まれます。
変更履歴を使用して損失したデータを復旧することができますので、障害時に役立てる事ができます。

REDOログ・バッファ

REDOログ・バッファはSGA内の領域で、データベースに対して行われた変更の内容であるREDOエントリ（REDOレコード）を格納し、領域が一杯になった後で再利用される循環バッファです。
REDOエントリには、INSERT、UPDATE、DELETE、CREATE、ALTER、DROPの各操作のよってデータベースに対して行われた変更の履歴などがあります。
また、REDOログ・バッファへREDOエントリを書き込む処理は、サーバー・プロセスが行います。
REDOログ・バッファのサイズは初期化パラメータLOG_BUFFER(バイト単位)で設定します。

以下の表1にLOG_BUFFERパラメータの設定概要を記します。
表1

LOG_BUFFERパラメータ
概要	REDOログ・バッファのサイズをバイトで設定
構文	LOG_BUFFER = 整数
デフォルト	512Kまたは128K×CPU_COUNTのいずれか大きいほう
変更の可/不可	可：静的

ログ・ライター・プロセス（LGWR）

ログ・ライター・プロセス(LGWR)は、最後の書込み以後にREDOログ・バッファ上に格納されているREDOエントリすべてを、ディスク上のREDOログ・ファイルに書き込む処理を行います。
REDOバッファは循環形式で利用されます。
具体的には、LGWRがREDOログ・バッファからREDOログ・ファイルにREDOエントリを書込みを行った後は、REDOログ・バッファ上にある書込み済みのREDOエントリを上書きし、新しいREDOエントリを格納するという利用方法です。

LGWRは、以下の場合にREDOログ・バッファからREDOログ・ファイルに書き込みます。
・ユーザー・プロセスがトランザクションをコミットした時。
・タイムアウト（3秒ごと）。
・REDOログ・バッファの3分の1が満杯になった時。あるいは1MBサイズが使用された時。
・DBWnが修正済みのバッファをデータ・ファイルに書き込む前。

REDOログバッファの利用について、以下の図1、2で説明します。

図1：LGWRの書き込み

図1の左下にサーバー･プロセスがありますが、このプロセスがREDOレコードをREDOログ・バッファに書込み、バッファ・キャッシュ内のデータを変更します。
図1の右側にLGWRプロセスがありますが、このプロセスがREDOログ・バッファの1/3が一杯になった時に、REDOレコードをオンラインREDOログ・ファイルに書込みます。

図2：サーバー・プロセスの書き込み

図2のサーバー・プロセスはLGWRの書込み中の場合でも、REDOログ・バッファに空きがあればREDOレコードをREDOログ・バッファに書込みます。
REDOログ・バッファが満杯になった時は、既にログ・ファイルに対して書込みが完了した領域を上書きして再利用します。

REDOログ・バッファのチューニング

REDOログ・バッファの利用について理解したところで、次はREDOログ・バッファのチューーニングについて復習しましょう。

(1)REDOログ・バッファの待機
CPUが高速でディスクの速度が遅い場合などでは、LGWRプロセスがREDOエントリをオンラインREDOログ・ファイルへコピーしている間に、REDOログ・バッファが満杯になることがあります。そのような場合、サーバー・プロセスはREDOログ・バッファへの書込みを待機します。
待機した回数は、V$SYSSTATビューのredo buffer allocation retries統計から確認できます。
待機回数の目安としては、redo buffer allocation retriesの値がredo entries（発生したREDOエントリ数）の1％を超えないようにします。
redo buffer allocation retries < redo entries/100
書き込み待機について以下の図3で説明します。

図3：サーバー・プロセスの書き込み待機

図3では、LGWRがオンラインREDOログ・ファイルへの書込み中に、サーバー・プロセスがREDOレコードをREDOログ・バッファに書き込もうとしていますが、REDOログ・バッファが満杯で循環利用できる領域が無いため、サーバー･プロセスの書き込み待機が発生しています。
このような状態をなるべく避けるために、REDOログ・バッファのサイズを適切に設定する必要があります。
適切なサイズを設定できるように、REDOログ・バッファに関連するイベントを知っておきましょう。

以下の表2にREDOログ・バッファに関連するイベントを記します。
表2：REDOログ・バッファに関連する待機イベント

イベント名	説明
log buffer space	REDOログ・バッファがいっぱいでサーバー・プロセスが書込みを待機。回数が多場合はログ・バッファが小さすぎるか、LGWRの書込みが遅い（I/Oの問題）。
log file parallel writ	LGWRプロセスのREDOログ・ファイルへの書込みに関する待機。
log file single write	REDOログ・ヘッダー書込みに関連する待機。チェックポイント中に発生しやすい。
log file switch completion	ログ・スイッチ時に発生する待機。実際に発生したログ・スイッチの回数よりも待機した回数が多い場合は、I/O負荷が高い可能性がある。
log file sync	COMMITまたはROLLBACKするとLGWRプロセスがREDO情報をREDOログ・ファイルにフラッシュする。 COMMITまたはROLLBACKを実行するプロセスは、LGWRプロセスが書出し中だった場合、その書出しが完了するまで待機する。このような待機はCOMMITの回数が多すぎるか、I/O負荷が高いのが原因。

REDOログ・ファイルに対する書込みが遅延すると、連鎖的にREDOログ・バッファへの待機が発生する可能性がありますので、注意が必要です。

(2)REDOログ・バッファのサイズ設定
LOG_BUFFERパラメータで、REDOログ・バッファのサイズを設定しましょう。
最初の見積りとしては、一般的に1MBで設定します。
REDOログ・バッファはSGA内の他の領域に比べ、非常に小さいサイズの領域です。
待機が発生している場合は、徐々にサイズを増加して調整してください。

以下に書き込み待機についての調査例を記します。
例）サーバー・プロセスがREDOログ・バッファへの書き込みを待機していないか調査する。

SQL> SELECT name,value FROM v$sysstat
2 WHERE name in('redo buffer allocation retries','redo entries');

NAME	VALUE
---------------------------	---------------
redo entries	356630
redo buffer allocation retries	129

以上でREDOログ･バッファのチューニングについての説明は終了です。
REDOログ・バッファへの書き込み待機が多い場合などに、ご活用いだだければと思います。
第18章では、チェックポイントのチューニングについて復習します。

　　　　　　　　　　　　　　　　　　　　　　　　第18章　チェックポイントのチューニングを学ぶ