REDOログに関する検証その１２

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

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

前回は、UPDATE、INSERT、DELETEのそれぞれ3つの処理を行った際の、REDOに対
する書き込み量の違いについての解説を行った。

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

＊＊＊＊＊＊＊ CREATE及びDROP処理は大量に書き込みを行う＊＊＊＊＊＊＊

＜CREATE処理＞

create table work03   (empno    number(4),
                       Ename    varchar2(6),
                       Address  varchar2(12),
                       Job      varchar2(8),
                       Mgr      number(4),
                       Sal      number(7),
                       Comm     number(7),
                       Deptno   number(2)) ;

＜統計情報＞

Redo entries                 69
Redo size                 15032
Redo wastage               1328
Redo blocks written          33

＜DROP処理＞

drop table work03 ;

＜統計情報＞

Redo entries                 51
Redo size                 11260
Redo wastage                644
Redo blocks written          24

上記は、CREATE及びDROP処理を行った際の結果（統計情報の差分）である。
前回のUPDATE、INSERT、DELETEなどといった処理と比べて、Redo sizeの値が増
大していることにお気付きいただけただろうか。

INSERTやDELETEといった処理では、400バイト前後で済んでいたREDOサイズが、
CREATE（DROP）処理では10Kバイト以上ものリソースを必要としてしまうのであ
る。

これは、テーブルをCREATE（DROP）する際、管理情報として複数のディクショ
ナリに対して変更を行うからである。1件のINSERT（DELETE）処理では、REDOエ
ントリ（レコード）は1つしか発生しないが、CREATE処理の場合69（DROPは51）
ものエントリが発生している。実際に、REDO・DUMPの内容を調べたところ、69
のエントリの内、その大半がディクショナリに対してのものであった。

＊＊＊＊＊＊＊＊＊＊＊＊＊ NOLOGGINGモード＊＊＊＊＊＊＊＊＊＊＊＊＊＊

NOLOGGINGモードは、ディクショナリに対する変更以外はロギングしないため、
REDOログへの書き込みを大幅に減らすことができる。その結果、REDOに対する
パフォーマンスを向上させることが可能となる。

しかし、障害時のリカバリ情報であるREDO情報が存在しないため、メディア・
リカバリを行うことができない。したがって、アーカイブ運用を行っているサ
イトでは、NOLOGGING処理の直後にバックアップを取得する必要があるかもしれ
ない。

NOLOGGINGモードが必要となるのは、「相当量のREDOへの書き込み」が問題とな
る大規模テーブルへの大量データ・ローディングや大規模インデックスの再作
成などの処理である（NOLOGGINGモードはダイレクト書き込みが可能な処理以
外はサポートされていない）。

したがって、データ量が少ない処理に対しては、むやみに使用することは避け
た方がよいかもしれない。なぜなら、REDOへの書き込みが停滞するほどのログ
情報は発生しないからである。また、障害発生時のリカバリのための情報をロ
ギングしていないので、NOLOGGINGモードでの処理は、やり直しが可能なバッチ
処理に限定すべきかもしれない。

NOLOGGINGオペレーションで生成されたデータは、NOLOGGINGオペレーション以
前に取得していたバックアップファイルを用いて、RECOVER DATABASEコマンド
で復旧させようとしても、検索すると以下のような「block corrupted」のエラ
ーが発生してしまう。

SQL> select * from CHAMU9 ;

ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 5, block # 74435)
ORA-01110: data file 5:
'../export/home/ora817/OraHome1/oradata/ora817/users01.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option

次回は、REDOに関する統計情報についての解説を行う予定である。

以上秋の気配が漂ってきた茅ヶ崎にて

REDOログに関する検証 その１２