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

＜ REDOログに関する検証その９＞ペンネームつけまい

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

前回は、なぜ、書き込みを行ったブロック数と、書き込みを行ったデータ量
（バイト数）が比例しないかについての解説を行った。

今回は、全く同じ内容でも、REDOログ・ファイルへ書き込みを行うタイミング
によって、必要とされるブロック数が異なってしまうという現象についての解
説を行う。

＊＊＊＊＊＊＊＊＊＊＊書き込みはブロック単位＊＊＊＊＊＊＊＊＊＊＊＊

前回でも述べたように、LGWR（オンラインREDOログ・ファイルへの書き込みを
行うプロセス）は、OS側のブロック単位（512バイト）で書き込みを行うことに
より、パフォーマンスを向上させている。そのため、たかが6バイトの更新にも
関わらず、1Kバイトもの領域を消費してしまい、その内の大半は、512バイト単
位で書き込みを行う際のフォーマットのために無駄使いしてしまっている。

以下に、REDOログに関する基本概念である「チェンジベクター」及び「REDOレ
コード」について、前回のおさらいも兼ねて説明する。

＜チェンジベクター＞
データベース内の任意の1ブロックに加えられた1つの変更を表したもの。チェ
ンジベクターには、変更したブロックのアドレス（DBA）や、更新後のデータな
どが格納される。

＜REDOレコード＞
データベースに対する原子的な変更を1つ記述した一連のチェンジベクターの集
まり。一部のトランザクションでは、複数のREDOレコードが生成され、各REDO
レコードに一連のチェンジベクターが格納される構造となっている。

仮に10件の更新処理を行った場合、REDOレコードは10個生成され、各REDOレコー
ドには複数のチェンジベクターが格納される。このREDOレコード（チェンジベ
クター）を生成する過程で、大量の未使用（無駄な）領域が発生するのである。
つまり、ブロック単位で書き込みを行うためのフォーマットを基に、REDOレコー
ド（チェンジベクター）を生成するので、このような未使用領域が生まれてし
まうのである。

＊＊＊＊＊＊タイミングによって書き込むブロック数が異なる＊＊＊＊＊＊

＜処理１＞
以下の2つのUPDATE文を間隔無しに瞬時に実行

●SQL文

Update work03 set ename = 'haneda' where empno = 1002 ;
Update work03 set ename = 'haneda' where empno = 1003 ;
Commit ;

●統計情報（差分）

Redo size                    652
Redo wastage                 340
Redo blocks written            2

＜処理２＞
以下の2つのUPDATE文を間隔を空けて実行

●SQL文

Update work03 set ename = 'haneda' where empno = 1002 ;

【間隔】

Update work03 set ename = 'haneda' where empno = 1003 ;
Commit ;

●統計情報（差分）

Redo size                    652
Redo wastage                 836
Redo blocks written            3

それぞれの統計情報に注目していただきたい。処理１、処理２共に、全く同じ
内容の更新処理であるにも関わらず、統計情報に差が生じてしまっている。

以前に述べたように、LGWRはトランザクションが発生する度にREDOログ・ファ
イルへ書き込みを行うのではなく、いくつかのタイミングによって起動される。
そのタイミングを思い出していただきたい。その中に、上記のような差が生ま
れてしまう理由（原因）が隠されている。

次回も引き続き、REDOログ・ファイルへ書き込みを行うタイミングによって、
必要とされるブロック数が異なってしまうという現象についての解説を行う予
定である。

以上茅ヶ崎にて

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