検索
連載

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

Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。(編集局)

Share
Tweet
LINE
Hatena

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の出力結果
図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の出力結果(クリックすると拡大します)
図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の出力結果
図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の出力結果
図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動的パフォーマンスビュー(抜粋)

次ページに続く)

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る