ログマイナーに関する検証その２

＜ログマイナに関する検証その弐＞ペンネームチョビひげ

— みてみてv$logmnr_contents —

前回はログ・マイナーの実行手順の説明を行なった。

今回は実際にログ・マイナーを実行し、
v$logmnr_contents表に作成される内容を見てみたいと思う。

まずは簡単なUPDATE文を実行して、ログ・マイナーを実行してみよう。

*************************************************************

# scottユーザで実行

SQL> desc zura;
Name                                      Null?    Type
----------------------------------------- -------- -------------------
EMPNO                                     NOT NULL NUMBER(4)
ENAME                                              VARCHAR2(10)
JOB                                                VARCHAR2(9)
MGR                                                NUMBER(4)
HIREDATE                                           DATE
SAL                                                NUMBER(7,2)
COMM                                               NUMBER(7,2)
DEPTNO                                             NUMBER(2)

#1行をUPDATE

SQL> update zura set ENAME='Urashima' where ENAME='Momotaro';

SQL> commit;

# ここからsysユーザで実行
# ディクショナリ・ファイルの作成

SQL> exec dbms_logmnr_d.build(dictionary_filename=>
     'ora817dict.ora',dictionary_location=>'../u01');

# REDOログ・ファイルの登録(今回は特定のトランザクションを検証するために、
# 事前にログ・スイッチを行いアーカイブログ・ファイルを取得する)

SQL> exec dbms_logmnr.add_logfile(options=>dbms_logmnr.new,logfilename=>
     '../u01/arch0_28.dbf');

#ログ・マイナーの初期化
SQL> exec dbms_logmnr.start_logmnr(dictfilename=>
‘../u01/ora817dict.ora’);
[/sql]
# v$logmnr_contentsより検索
SQL> select scn, data_obj#, seg_owner, seg_name, operation
from v$logmnr_contents;

SCN DATA_OBJ# SEG_OWNER SEG_NAME OPERATION
———- ———– ———— ———– ——————
687902 0 INTERNAL
687902 0 START
687902 26065 SCOTT ZURA UPDATE
687904 0 COMMIT
[/sql]

上記のv$logmnr_contents表を検索した結果を見てみると、UPDATEとCOMMITで4
つのオペレーション(INTERNAL,START,UPDATE,COMMIT)のREDOレコードが作成さ
れているのが分かる。

REDOログ・ファイルのダンプファイルではSCN(system change number)などが
16進数表示であったが、v$logmnr_contents表では10進数表示になっており分
かりやすくなっている。
ちなみに、SCNはデータベースになんらかの障害が発生した場合に、バックア
ップファイルとREDOログ・ファイルからPointInTime回復を実行する際に指定
する事が出来る。

次にv$logmnr_contents表よりSQL_REDO、SQL_UNDO列を検索してみよう。

SQL> select data_obj#, operation, sql_redo, sql_undo
     2 from v$logmnr_contents;
DATA_OBJ#  OPERATION    SQL_REDO
---------  ------------ -----------------
0          INTERNAL
0          START        set transaction read write;
26065      UPDATE       update "SCOTT"."ZURA" set "ENAME" = 'Urashima'
                        where ROWID = 'AAAGXRAAFAAASDHAAO';
0          COMMIT       commit;

SQL_UNDO
-----------------------------------------------------------------------

update "SCOTT"."ZURA" set "ENAME" = 'Momotaro'
where ROWID = 'AAAGXRAAFAAASDHAAO';

REDO、UNDOのSQL文が確認できる。
また、ログ・マイナーの初期化の際、ディクショナリ・ファイルを指定するこ
とにより、v$logmnr_contents表内で表示されるオブジェクト名、列名等の変換
も行なわれている。

ちなみに、ディクショナリを指定しなかった場合は以下のような表示になる。

# sysでユーザで実行

SQL> exec dbms_logmnr.add_logfile(options=>dbms_logmnr.new,logfilename=>
     '../u01/arc0_28.trc');

# ログ・マイナーの初期化

SQL> exec dbms_logmnr.start_logmnr();

# v$logmnr_contents表を検索

SQL> select scn, seg_owner, seg_name, operation, sql_redo
     from v$logmnr_contents;
SCN     SEG_OWNER  SEG_NAME  OPERATION  SQL_REDO
------- ---------- --------- ---------- -------------------
346635                       START      set transaction read write;
346635  UNKNOWN              UPDATE     update UNKNOWN.Objn:3825 set
                                        Col[2] = HEXTORAW('35cfba')
                                        where ROWID = 'AAAA7xAABAAAGTUAAA';
346637                       COMMIT     commit;

オブジェクトのオーナ(SEG_OWNER)が表示されず、SQL_REDO列のオブジェクトID
や列番号がそのまま表示されており、非常に分かりづらい。

REDOログ・ログファイルを分析する際は、ディクショナリを指定することによ
って、SQL_REDO列やSQL_UNDO列のSQL文がコピーアンドペーストで利用可能にな
り、分析がやり易くなっていることが分かる。

以上、きょうもへいわな茅ヶ崎にて

ログマイナーに関する検証 その２