気付きにくいREDOログの問題切り分けテクニック：Oracleパフォーマンス障害の克服（6）（2/3 ページ）
Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。（編集局）
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';
※勘違いしやすいパラメータ
上述の「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）ログ・スイッチの発生するタイミング
ログ・スイッチが発生するのは、
- 現行のログ・グループが満杯になったとき
- 管理者によるコマンド要求時
のタイミングとなります。ログ・スイッチの問題に関しては、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';
このイベントには、
- 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;
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;
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動的パフォーマンスビュー（抜粋） | ||
（次ページに続く）
Copyright © ITmedia, Inc. All Rights Reserved.