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
処理１は、項目ENAME（6バイト）を、間隔を空けずに瞬時に2件更新したもので
ある。この処理では、ディスク上のオンラインREDOログ・ファイルへ2ブロック
（1Kバイト）書き込みを行い、その内の340バイトがフォーマットのための未使
用領域となっている。
つまり、有効なREDO情報としては652バイトしか存在していないにも関わらず、
ブロック単位で書き込みを行う際のフォーマットのために、340バイトが無駄な
未使用領域となってしまっている（各ブロックの先頭には、それぞれ16バイト
のヘッダー情報が格納されている）。
この結果だけ見ても、いかに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 836
Redo blocks written 3
処理１と全く変わらない更新内容にも関わらず、Redo wastage及び
Redo blocks writtenの値がそれぞれ多くなっている。これは、更新内容が同じ
でも、LGWRがREDOログ・ファイルへ書き込みを行うタイミングによっては、書
き込まれるブロック数が異なることを意味している。
以前にも述べたように、LGWRはトランザクションが発生する度にREDOログ・ファ
イルへ書き込みを行うのではなく、いくつかのタイミングによって起動される。
そのタイミングの一つに「前回の書き込みから3秒間経過した時」がある。
処理１の場合、前回の書き込みから3秒以内の間に2レコード分の更新及びコミッ
トに関するREDOレコードが生成されたので、REDOログ・ファイルへの書き込み
は2ブロックで済んだ。
しかし、処理２の場合、各REDOレコードが生成される過程で、多少なりとも「間」
が生じてしまう。この「間」が生まれることにより、全てのREDOレコードが生成
されていないにも関わらず、前回の書き込みから3秒が経過してしまい、LGWRが
その時点までに生成されているREDOレコードをREDOログ・ファイルへ掃き出し
てしまう。
その結果、本来であれば2ブロックで済んだはずのREDO情報が、途中で書き込み
が行われたために、新たな領域を必要としてしまったのである。
イメージ図
この結果を「パフォーマンス」という観点から見た場合、さほど重要視する問題
とはならないが、「リソース」という面から見た場合はどうだろう。
この一連の処理から生まれる余分なブロックは1ブロックに過ぎないが、同じよ
うな処理を1万回繰り返した場合、トータルで1万ブロック、すなわち5Mもの領
域を無駄に消費してしまうことになる。そうなると、必然的にログ・スイッチ
のタイミングを早めてしまい、それが起因してパフォーマンスに影響を与えて
しまうことも十分に考えられる。
また、アーカイブ運用を行っているサイトでは、REDOログ・ファイルからアー
カイブ・ファイルへ掃き出しを行う際にも、この5M分の領域が含まれてしまう。
もし仮に、1時間に1回の割合でログ・スイッチが発生している場合、1日で120M
もの領域を、無駄に消費してしまう計算になる。
したがって、コーディングの段階でトランザクション部分をある程度まとめて
処理させることが、REDOログ・ファイルに対するリソースの節約につながるポ
イントとなる。
次回は、UPDATE、INSERT、DELETEのそれぞれ3つの処理を行った際の、REDOに対
する書き込み量の違いについての解説を行う予定である。
以上 茅ヶ崎にて