気付きにくいREDOログの問題切り分けテクニック：Oracleパフォーマンス障害の克服（6）（2/3 ページ）

[高橋潤，＠IT]

REDOログ書き込みのタイミング

• 3秒置き
• COMITT要求時
• ログ・バッファの3分の1がいっぱいになったとき
• DBWRが書き込みを行う直前

のようにいくつかのタイミングがあります。「ログ・バッファの3分の1がいっぱいになったとき」の動作は、ログ・バッファのサイズによって影響を受けます。ログ・バッファはSGA内のメモリ上に確保され、パラメータ「log_buffer」で設定できます。このサイズはどの程度で設定すべきかが、重要な管理項目です。デフォルトでは「128Kbytes×CPU_COUNT」で設定されており、CPU数が5未満であれば500Kbytes（524288bytes）となるようです。

　ログ・バッファのサイズが適正であるかどうかは、ログ・バッファに書き込むREDOエントリで競合が起きているかどうかで判断します（リスト1）。統計情報の「redobuffer allocation retries」の回数が多い状態であれば、ログ・バッファに書き込み待ち（再実行）が発生していることになりますので、この再実行を減らすためにlog_bufferのサイズを大きくします。「redobuffer allocation retries」がほとんど0に近い状況が理想です。

SQL> select value
  2  from v$sysstat
  3  where name like 'redo buffer allocation retries';

リスト1　redo buffer allocation retriesの値を取得

図2　リスト1の出力結果（クリックすると拡大します）

※勘違いしやすいパラメータ

上述の「redo buffer allocation retries」以外にも「redo log space requests」というパラメータがあります。この値は下記に引用した管理者ガイドにあるように、REDOログ・バッファの書き込み要求の待機の回数を表すのではなく、REDOログ・ファイルの書き込みを待機した回数になります。つまりlog_bufferの値を判断するための値とはならないことに注意してください。

REDOログ領域要求統計

V$SYSSTAT統計のredo log space requestsは、サーバ・プロセスがREDOログ・バッファ内の領域を待機するのではなく、オンラインREDOログ内の領域を待機する必要があった回数を示します。この統計と待機イベントの大きい値は、LGWRではなく、チェックポイント、DBWR、アーカイバ・アクティビティをチューニングする必要があることの標識として使用する必要があります。ログ・バッファのサイズを増やしても効果がありません。（Oracle9i管理者ガイドより抜粋）

　また、log_bufferのサイズについては、V$SYSSTAT内の待機イベントである「logbuffer space」でサーバ・プロセスがログ・バッファ内の空き領域を待機しているかどうか確認できます（リスト2）。ここで待機が発生しているようであれば、log_bufferのサイズを変更することで解決することがあります。

SQL> select value
  2  from V$SYSSTAT 
  3  where name like 'log buffer space';

リスト2　log buffer spaceの値を取得

（2）ログ・スイッチの発生するタイミング

　ログ・スイッチが発生するのは、

• 現行のログ・グループが満杯になったとき
• 管理者によるコマンド要求時

のタイミングとなります。ログ・スイッチの問題に関しては、V$SESSION_EVENTの待機イベント「logfile switch completion」で確認できます（リスト3）。

SQL> select
TOTAL_WAITS AS 待ち回数, 
2    TOTAL_TIMEOUTS AS タイムアウト回数,
  3    TIME_WAITED * 100 AS "待機時間合計 秒",
 
4    AVERAGE_WAIT * 100 AS "待機平均時間 秒", 
5    MAX_WAIT * 100 AS "待機最大時間 秒" 
 
6  from V$session_event 
 
7  where event like 'log file switch completion';

リスト3　log file switch completionの値を取得

図3　リスト3の出力結果（クリックすると拡大します）

　このイベントには、

• log file switch (archiving needed)
  アーカイバがアーカイブ・ログを作成できない場合（次回で詳しく解説します）
• log file switch (clearing log file)
  新規使用のため循環した過去のREDOログをクリーニング中の場合
• log file switch (checkpoint incomplete)
  チェックポイントに失敗した場合

の3種類以外のすべてのログ・スイッチにかかわる待機、つまり循環ファイルの次のファイルにログ・スイッチできない状態を確認できます。これはDBWRがチェックポイントを完了する前に、循環して使用しているREDOログのすべての領域を使用してしまうほど大きなREDOログが生成されていることを示しますので、REDOログ・ファイルのサイズまたは個数、あるいはその両方を増やす必要があります。

　REDOログ・ファイルのサイズを大きくしたり（現在使用しているREDOログ・ファイルを削除し新規ファイルを追加する）、REDOログ・グループを追加することで、ログ・スイッチを減少させることが可能です。

REDOログ・ファイルのログ・グループ数を確認

　REDOログ・ファイルのログ・グループ数を確認する方法はリスト4になります。図4の出力結果では、ログ・グループは3つで、ログ・ファイルは多重化されていないことなどが分かります。

SQL> SELECT * FROM V$LOGFILE;

リスト4　REDOログ・ファイルの状態を確認

図4　リスト4の出力結果（クリックすると拡大します）

　V$LOGFILEの出力内容の意味を表1に示します。

列名	データ型	格納されているデータの内容
GROUP#	NUMBER	REDOログ・グループ識別子番号
STATUS	VARCHAR2(7)	ログ・メンバーの状態 　INVALID：ファイルはアクセス不可能 　STALE：　ファイルの内容が不完全 　DELETED：ファイルは使用されなくなった 　空白：ファイルは使用中
MEMBER	VARCHAR2(513)	REDOログ・メンバー名
表1　V$LOGFILE動的パフォーマンスビュー（抜粋）

REDOログ・ファイルのファイルサイズを確認

　REDOログ・ファイルのファイルサイズを確認する方法はリスト5になります。図5の出力結果から、各ファイルのサイズは104857600bytes、ノーアーカイブ・モードで運用されていることなどが分かります。

SQL> SELECT * FROM V$LOG;

リスト5　REDOログ・ファイルの状態を確認

図5　リスト5の出力結果（クリックすると拡大します）

　V$LOGの出力内容の意味を表2に示します。

列名	データ型	格納されているデータの内容
GROUP#	NUMBER	REDOログ・グループ識別子番号
SEQUENCE#	NUMBER	ログ順序番号
BYTES	NUMBER	ログのサイズ（byte）
MEMBERS	NUMBER	ログ・グループのメンバーの数
ARCHIVED	VARCHAR2(3)	アーカイブ状態（YES | NO）
STATUS	VARCHAR2(16)	ログ状態が格納される。内容は以下のキーワード UNUSED：　オンラインREDOログが、まだ書き込まれていないことを示す。これは、ログがカレントREDOログではない場合の、追加またはRESETLOGSの直後のREDOログの状態 CURRENT：　現行のREDOログ。これは、REDOログがアクティブであることを意味する。REDOログはオープン状態の場合もクローズ状態の場合もある ACTIVE：　アクティブだが、カレント・ログではない。このログはクラッシュ・リカバリのために必要。また、ブロック・リカバリのために使用される場合もある。このログはアーカイブ済みの場合も未アーカイブの場合もある CLEARING：　ALTER DATABASE CLEAR LOGFILE文の後、空のログとして再作成されていることを示す。ログの消去の後、状態がUNUSEDに変更される。 CLEARING_CURRENT：　クローズされたスレッドからカレント・ログが消去されることを示す。新しいログ・ヘッダーを書き込むときのI/Oエラーなどのスイッチ障害がある場合、ログがこの状態のままになることがある INACTIVE：　インスタンス・リカバリのためには、ログがもう必要でないことを示す。このログは、メディア・リカバリのために使用される場合がある。このログはアーカイブ済みの場合も未アーカイブの場合もある
BYTES	NUMBER	ログのサイズ（byte）
表2　V$LOG動的パフォーマンスビュー（抜粋）

（次ページに続く）