REDOログに関する検証 その13

投稿日: 2001年10月03日

< REDOログに関する検証 その13 > ペンネーム つけまい

— 内部構造を理解し
パフォーマンスの向上に役立てる —

前回は、CREATEおよびDROP処理を行った際、UPDATE、INSERT、DELETE処理と比
べ、REDOに対して大量に書き込みが発生するという現象についての解説を行っ
た。

今回は、REDOに関する統計情報についての解説を行う。

************ REDOに関する統計情報 ************

Oracleでは、REDOに関する様々な統計情報が用意されている。この統計情報の
中には、チューニングのヒントとなるべき項目がいくつか存在している。

以下は、REDOに関する統計情報の中から、主だった項目をピックアップして解
説したものである。なお、これらの値は累計値となっているので、トランザク
ション毎の値を調査するには、前後の差分を求める必要がある。

<統計情報を取得するためのSQL文>

select * from v$sysstat where name like '%redo%' ;

<各種統計情報>

1.Redo synch writes

適用されている変更をコミットのためにディスクに書き込む必要がある場合に
増加

2.Redo entries

REDOエントリがREDOログ・バッファにコピーされるたびに増加
(生成されたREDOレコード数)

3.Redo size

生成されたREDOの合計バイト数

4.Redo buffer allocation retries

ユーザ・プロセスがREDOログ・バッファ内の領域の使用を待機した合計回数
この値は限りなく0の近傍でなければならない
この値が一貫して増大する場合は、ログ・バッファが小さすぎること、あるい
はチェックポイント機能またはログ・スイッチが原因となっていることが考え
られる
初期設定パラメータ「LOG_BUFFER」の値を変更することによって、ログ・バッ
ファのサイズを大きくすることができる

5.Redo wastage

OSのブロック単位(512バイト)で書き込みを行う際のフォーマットのために、
REDOログ・ファイル内の領域を浪費した合計バイト数

6.Redo writer latching time

LGWRが各コピー・ラッチ(次回で説明)を取得して解除するために必要とした
合計経過時間(10ミリ秒単位)
この統計情報は、初期設定パラメータ「LOG_SIMULTANEOUS_COPIES」(次回で説
明)が1以上の場合にのみ使用される

7.Redo writes

LGWRによるREDOログ・ファイルへの書き込み合計回数

8.Redo blocks written

REDOログ・ファイルへ書き込みを行った合計ブロック数

9.Redo log space requests

アクティブ・ログ・ファイルが満杯になり、ログ・スイッチが発生した際にREDO
ログ・ファイルへの書き込みを待機した合計回数
この値が一貫して増大する場合は、以下の原因が考えられる
・REDOログ・ファイルのサイズが小さすぎる
・LOG_BUFFERのサイズが小さすぎる
・REDOラッチの競合が発生している

次回は、REDOに関する2つのラッチ「REDOアロケーション・ラッチ」と
「REDOコピー・ラッチ」の役割についての解説を行う予定である。

以上 秋が一気に加速した茅ヶ崎にて