ログマイナー再び!! その2

<ログマイナー再び!! その2>
ペンネーム: ぽっちゃりメタボン

こんにちは、ぽっちゃりメタボンです。
今週もはりきって、ログマイナーを深めていきましょう。

▼ 前回のおさらい

前回はログマイナーの実行手順を確認してみました。
簡単に実行できてしまいましたが、ログマイナーの起動手順においては色々
と選択可能なオプションも用意されていますのでそれらを確認していきなが
ら、進めていきたいと思います。
今回は、ログマイナーを実行する上で必要となる LogMiner ディクショナリ
について確認していきます。

▼ LogMiner ディクショナリ とは

ログマイナーはREDOログ内にあるオブジェクトIDとオブジェクト名を紐付け
するためにディクショナリを必要とします。つまり
V$LOGMNR_CONTENTS内に保持されるSQL文の再構成(SQL_REDO、SQL_UNDO列)
等に使用されるというわけです。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10gR2ではディクショナリ指定で以下の3つが用意されています。

1.) オンラインカタログを指定。
2.) REDOログファイルへLogMinerディクショナリを抽出し、指定。
3.) フラットファイルへLogMinerディクショナリを抽出し、指定。

今回は1、2のオプションについてそれぞれ見ていきたいと思います。
※3.フラットファイルへのLogMiner ディクショナリの抽出については前回
のログマイナー検証シリーズで取り上げていますのでそちらを参照して下さ
いね。
https://www.insight-tec.com/mailmagazine/ora3/vol081.html

▼ 環境のおさらい

OS:Red Hat Enterprise Linux ES release 3
DB:10gR2(10.2.0.1)

▼ 今回使用するテーブルはこちら

SQL> desc test_03
名前            NULL?    型
-------------- -------- ------------
COL1                    NUMBER
COL2                    NUMBER
COL3                    VARCHAR2(20)

SQL> select * from test_03;

      COL1       COL2 COL3
---------- ---------- --------------
         1          1 test1

▼ 手順確認

1.) オンラインカタログの使用

オンラインカタログとは簡単にいうと現在のデータベースディクショ
ナリですので、最新の情報を持っています。
ですので別途、ディクショナリ情報を抽出する必要がありません。

1.1) 分析対象となるログファイルを指定します。

            SQL> execute dbms_logmnr.add_logfile(logfilename=>'&redologfi
                 lename',options=>dbms_logmnr.new);

            PL/SQLプロシージャが正常に完了しました。

1.2) “options”に dbms_logmnr.dict_from_online_catalog を指定し、
ログマイナーを起動します。

            SQL> execute dbms_logmnr.start_logmnr(options=>dbms_logmnr.
                 dict_from_online_catalog);

            PL/SQLプロシージャが正常に完了しました。

1.3) v$logmnr_contens へ 問い合わせ

            SQL> select timestamp,sql_redo from v$logmnr_contents 
                 where seg_name='TEST_03';

TIMESTAMP
-----------------
07/09/30 03:15:02
07/09/30 03:19:43

SQL_REDO
---------------------------------------------------------------------
create table test_03(col1 number,col2 number,col3 varchar2(20));
insert into "SCOTT"."TEST_03"("COL1","COL2","COL3") values ('1','1','
test1');

2.) REDOログファイルへLogMinerディクショナリを抽出し、指定。

スナップショットとして、とある時点でのディクショナリをREDOログへ
出力しておき、ログマイナー起動時にそのREDOログを追加し、ディクシ
ョナリとして使用する方法です。

2.1) REDOログへディクショナリの抽出

            SQL> execute dbms_logmnr_d.build(options=> dbms_logmnr_d.stor
                 e_in_redo_logs);

            PL/SQLプロシージャが正常に完了しました。

2.2) v$archived_log を参照し、どのアーカイブログへディクショナリ
情報が出力されているかを確認をします。

※ディクショナリ情報が大きい場合などには複数のアーカイブログ
へ跨って出力されるのでdictionary_begin=’YES’と
dictionary_end=’YES’を条件に指定して参照することを
忘れずに!!

SQL> select name from v$archived_log where dictionary_begin='YES';

NAME
---------------------------------------------------------------------
/home/ora102/oracle/flash_recovery_area/ORA102/archivelog/2007_09_30/
o1_mf_1_48_3hx7kpx8_.arc


SQL> select name from v$archived_log where dictionary_end='YES';

NAME
---------------------------------------------------------------------
/home/ora102/oracle/flash_recovery_area/ORA102/archivelog/2007_09_30/
o1_mf_1_48_3hx7kpx8_.arc

2.3) 上記で使用するべきファイルが特定できましたので
ディクショナリ情報を含むアーカイブログ、
分析対象のログファイルをそれぞれ追加します。

            SQL> execute dbms_logmnr.add_logfile(logfilename=>'&redologfi
                 lename',options=>dbms_logmnr.new);
            
            PL/SQLプロシージャが正常に完了しました。


            SQL> execute dbms_logmnr.add_logfile(logfilename=>'&redologfi
                 lename',options=>dbms_logmnr.addfile);
            
            PL/SQLプロシージャが正常に完了しました。

2.4) “options”に dbms_logmnr.dict_from_redo_logs を指定し、
ログマイナーを起動します。

            SQL> execute dbms_logmnr.start_logmnr(options=>dbms_logmnr.
                 dict_from_redo_logs);

2.5) v$logmnr_contens へ 問い合わせ

            SQL> select timestamp,sql_redo from v$logmnr_contents 
                 where seg_name='TEST_03';

TIMESTAMP
-----------------
07/09/30 03:15:02
07/09/30 03:19:43

SQL_REDO
---------------------------------------------------------------------
create table test_03(col1 number,col2 number,col3 varchar2(20));
insert into "SCOTT"."TEST_03"("COL1","COL2","COL3") values ('1','1','
test1');

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

▼ ちょっと試しに

オンラインカタログ指定の場合には常に最新のディクショナリ情報を使用して
いるとのことなのでちょっと意地悪をして、構成情報を変更してみましょう。

1) 先程、使用した test_03表 の col2列 をdropしてみます。

SQL> alter table test_03 drop column col2;

表が変更されました。

2) 分析対象のログファイルは先程と同一のものを指定し、再度、オンライン
カタログを使用したログマイナーセッションで
v$logmnr_contensへSCNを条件に問い合わせしてみます。

SQL>select timestamp,sql_redo from v$logmnr_contents 
    where scn=464276

TIMESTAMP
-----------------
07/09/30 03:19:43

SQL_REDO
---------------------------------------------------------------------
insert into "SCOTT"."TEST_03"("COL 1","COL 2","COL 3") values (HEXTOR
AW('c102'),HEXTORAW('c102'),HEXTORAW('7465737431'));

SQL_REDO列には更新処理を再実行するためのSQL文が再構成された形で格納さ
れますが、その構成が上手くできなくなってしまったようです。

3) 更に test_03表 を削除してみちゃいます。
SQL> drop table test_03 purge;

表が削除されました。

4) 再度、オンラインカタログを使用したログマイナーセッションで
v$logmnr_contensへ問い合わせ。

SQL>select timestamp,sql_redo from v$logmnr_contents 
    where scn=464276

TIMESTAMP
-----------------
07/09/30 03:19:43

SQL_REDO
---------------------------------------------------------------------
insert into "UNKNOWN"."OBJ# 11238"("COL 1","COL 2","COL 3") values (H
EXTORAW('c102'),HEXTORAW('c102'),HEXTORAW('7465737431'));

さらにSQL_REDO列のSQL文に含まれていたスキーマ名とオブジェクト名も確認
ができなくなってしまったようです。

オンラインカタログを指定し、ログマイナーを使用する場合においては常に
最新のディクショナリ情報が使用されるために表の構成が変更された場合等
が発生した場合に上記のような状況が発生していると考えられます。

次回はそこらへんを中心に掘り下げて検証を行っていきます。

今回はここまでです。

まだまだ、虫が多い 茅ヶ崎より