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

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

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

前回は、REDOログに関する統計情報などについての解説を行った。

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

＊＊＊＊＊＊＊＊＊＊＊＊ REDOログは無駄使い？＊＊＊＊＊＊＊＊＊＊＊＊

＜トランザクション＞

———- SQL文 ———-

UPDATE WORK03
SET ENAME = 'haneda'
WHERE EMPNO = 1001 ;

1行が更新されました。

COMMIT ;

コミットが完了しました。

※ EMPNOにはインデックスは作成していない

以下の図は、REDOログに対する書き込み量を調査するために必要となる統計情
報である。

これらの統計情報の値は累計値となっているので、更新処理前後の差分を求め
る必要がある。書き込み量を調べるために必要な統計情報の更新処理前後の差
分は、以下の通りである。

１．redo size           = 448
２．redo wastage        = 544
３．redo blocks written =   2

まず、redo blocks writtenに注目していただきたい。ここで言うブロックとは、
Oracleブロックではなく、OS上のブロックを意味している。したがって、512×2
で1024バイト書き込んだことになる。

次に、実際の書き込みを行ったバイト数を表すredo sizeを見てみると、448で
1024に満たない。

そこで、実際のOS上のファイルを16進表示して中身を確認したところ、ブロッ
ク中に何も書き込みが行われていない部分が数多く存在することが分かった。

REDOログ・ファイルの16進表示

つまり、REDOログ・ファイルに書き出すためのフォーマットを基準にして、そ

のフォーマットに基づいて書き込みを行っているために、空白の部分が存在し
ているのである。

この、何も書き込みを行っていない量を表しているのが、redo wastageである。

実際に書き込みを行った量を、redo wastage及びredo blocks writtenから求め
ると、以下の様になる。

1024（redo blocks written） - 544（redo wastage）
               - 16（ヘッダー） × 2（ブロック数） = 448（redo size）

※ 各ブロックの先頭には、それぞれ16バイトのヘッダー情報が格納されている
ため、書き込みを行ったブロック分を除く必要がある

つまり、たかが6バイトの更新に、1Kバイトもの領域を消費し、その内の544バ
イトは、512バイト単位で書き込みを行う際のフォーマットのために無駄使いし
ているということになる。

確かに、OS側のブロック単位（512バイト）で書き込みを行うこと自体は、パフォー
マンスを向上させる上では妥当な構造と言えるだろう。

しかし、「無駄使い」という表現には語弊があるかもしれないが、いくらパフォー
マンスを優先させるためのフォーマットとは言え、もう少し改善の余地はある
のではないだろうか。

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

以上茅ヶ崎にて

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