ログマイナー再び！！　その１０

＜ログマイナー再び！！　その１０＞
ペンネーム：ぽっちゃりメタボン

読者の皆様こんにちは。

サザンオールスターズが大好きなぽっちゃりメタボンです。

今週もはりきってはじめましょうね。

▼ はじめに

前回は本シリーズを総括する上でログマイナー使用した事後監査の運用例に
ついて触れました。

その中で読者の方からメタボン宛てにご質問が届きましたので、ご質問内容を
皆様に紹介させて頂くと共に、その回答の場とさせて頂きたいと思います。

早速ですが、以下がご質問の内容です。

▼ 質問内容

Ｑ１. 取得情報について

ログマイナーで取得可能な情報について教えてください。

・DBログイン時刻、ログオフ時刻
・DBのユーザID
・OSのユーザID
・クライアントの端末
(ローカル接続の場合はそのサーバ名、
リモート接続の場合はユーザが使用しているPCの端末名)
・クライアントIPアドレス
(ローカル接続の場合はそのサーバのIP、リモート接続の場合はユーザが
使用しているPCのIP)

Ｑ２．サプリメンタル・ロギング

上記Ｑ１の情報を取得可能な場合、サプリメンタル・ロギングのオプションは
どのようになるのでしょうか？
システムへの負荷は最小限にしたいため、最適なオプションを設定したく思っ
ています。

Ｑ３． audit_trail 設定について

検証の中では audit_trail = DB_EXTENDEDとされていましたが、これは必須な
のでしょうか？

▼ 回答

Ａ１. 取得情報について

うーん。

残念ながら、ログイン、ログオフ情報をREDOログからは取得することができません。
なのでログイン、ログオフ情報を取得する場合は少し工夫が必要になります。

まずは audit_trailのログオン監査を有効にします。

SQL> audit session ;
監査が成功しました。

これにより、各セッションのログオン、ログオフ時間を監査証跡として残す事
が可能になります。
※ここでは audit_trail = db or db_extended が設定されているものとします。
※dba_audit_trail(実体はaud$) には 1セッション = 1レコードが生成される
ためログイン、ログオフが頻繁に行われるようなアプリケーションの作りに
なっている場合は注意が必要になります。

監査証跡を確認可能な dba_audit_trailと
ログマイナーセッションから確認可能なredo情報であるv$logmnr_contentsを
dba_audit_trail.sessionid、v$logmnr_contents.audit_sessionidを結合キー
にして、dba_audit_trailの情報からログオン、ログオフを取得する必要があ
ります。

以下のSQLを実行します。

SQL>
　　　　1  select
　　　　2     b.timestamp LOGON,
　　　　3     b.logoff_time LOGOFF,
　　　　4     a.SESSION_INFO,
　　　　5     a.OPERATION
　　　　6  from
　　　　7   v$logmnr_contents a
　　　　8  ,dba_audit_trail b
　　　　9  where operation != 'INTERNAL'
　　10  and b.sessionid  = a.audit_sessionid
　　11  and b.logoff_time is not null

LOGON             LOGOFF
----------------- -----------------
07/11/26 19:20:32 07/11/26 19:22:11

SESSION_INFO
----------------------------------------------------------------------
login_username=METABON client_info= OS_username=ora102 Machine_name=VM
RH30 OS_terminal=pts/0 OS_process_id=2247 OS_program_name=sqlplus@VMRH
30 (TNS V1-V3)

OPERATION
--------------------------------
UPDATE

これによりREDOレコードに対応した、ログオン、ログオフ時間の取得が可能と
なります。

Ａ２．サプリメンタル・ロギング

サプリメンタル・ロギングはあくまでＳＱＬ文の再構成(sql_redoカラム,
sql_undoカラム)時に情報を付加するための補助的な役割となりますので、
上記情報を取得するためには最小サプリメンタルロギングを設定するのみで
問題はありません。

SQL> alter database add supplemental log data;

データベースが変更されました。

Ａ３．audit_trail設定について

必須ではありません。

audit_trail = DB_EXTENDED を設定することにより実行ＳＱＬ文が取得可能
になるため、検証では設定を行いました。
※10gR2からのみ取得が可能です。
※ログマイナーでは実際に実行されたＳＱＬ文を取得することができません。
あくまで、v$logmnr_contents.sql_redoは”再構成”されたＳＱＬ文となります。

よって、取得情報として、実行ＳＱＬ文が必要でない場合は audit_trail の
設定は必須ではありません。

▼ まとめ

読者の皆様からの質問を答えたところで本シリーズは最終回となります。

連載開始当初はどうなる事かと思いましたが、なんとか連載に穴をあけること
なく無事に最終回を迎える事ができたことに、達成感を覚えています。

今にして筆者の胸に去来する思いは、説明下手でログマイナーの魅力が正しく
伝えることができたのか、または、誤解されている部分があるのではないかが
若干心配ではあります。
ですので、疑問、ご質問があればどしどしメール下さい。まっています。

そろそろ、お別れの時が近づいてきました。

最後になりましたが
読者の皆様、ご愛読ありがとうございました。

さよーならー

また逢う日までー

☆ぽっちゃりメタボンでした。えへ

砂混じりの茅ヶ崎より

ログマイナー再び！！ その１０