REDOログに関する検証 その１３
＜ REDOログに関する検証 その１３ ＞ ペンネーム つけまい
— 内部構造を理解し
パフォーマンスの向上に役立てる —
前回は、CREATEおよびDROP処理を行った際、UPDATE、INSERT、DELETE処理と比
べ、REDOに対して大量に書き込みが発生するという現象についての解説を行っ
た。
今回は、REDOに関する統計情報についての解説を行う。
＊＊＊＊＊＊＊＊＊＊＊＊ REDOに関する統計情報 ＊＊＊＊＊＊＊＊＊＊＊＊
Oracleでは、REDOに関する様々な統計情報が用意されている。この統計情報の
中には、チューニングのヒントとなるべき項目がいくつか存在している。
以下は、REDOに関する統計情報の中から、主だった項目をピックアップして解
説したものである。なお、これらの値は累計値となっているので、トランザク
ション毎の値を調査するには、前後の差分を求める必要がある。
＜統計情報を取得するためのSQL文＞
select * from v$sysstat where name like '%redo%' ;
＜各種統計情報＞
１．Redo synch writes 適用されている変更をコミットのためにディスクに書き込む必要がある場合に 増加 ２．Redo entries REDOエントリがREDOログ・バッファにコピーされるたびに増加 （生成されたREDOレコード数） ３．Redo size 生成されたREDOの合計バイト数 ４．Redo buffer allocation retries ユーザ・プロセスがREDOログ・バッファ内の領域の使用を待機した合計回数 この値は限りなく0の近傍でなければならない この値が一貫して増大する場合は、ログ・バッファが小さすぎること、あるい はチェックポイント機能またはログ・スイッチが原因となっていることが考え られる 初期設定パラメータ「LOG_BUFFER」の値を変更することによって、ログ・バッ ファのサイズを大きくすることができる ５．Redo wastage OSのブロック単位（512バイト）で書き込みを行う際のフォーマットのために、 REDOログ・ファイル内の領域を浪費した合計バイト数 ６．Redo writer latching time LGWRが各コピー・ラッチ（次回で説明）を取得して解除するために必要とした 合計経過時間（10ミリ秒単位） この統計情報は、初期設定パラメータ「LOG_SIMULTANEOUS_COPIES」（次回で説 明）が1以上の場合にのみ使用される ７．Redo writes LGWRによるREDOログ・ファイルへの書き込み合計回数 ８．Redo blocks written REDOログ・ファイルへ書き込みを行った合計ブロック数 ９．Redo log space requests アクティブ・ログ・ファイルが満杯になり、ログ・スイッチが発生した際にREDO ログ・ファイルへの書き込みを待機した合計回数 この値が一貫して増大する場合は、以下の原因が考えられる ・REDOログ・ファイルのサイズが小さすぎる ・LOG_BUFFERのサイズが小さすぎる ・REDOラッチの競合が発生している
次回は、REDOに関する2つのラッチ「REDOアロケーション・ラッチ」と
「REDOコピー・ラッチ」の役割についての解説を行う予定である。
以上 秋が一気に加速した茅ヶ崎にて