ログマイナー再び！！ その６
＜ログマイナー再び！！ その６＞
ペンネーム： ぽっちゃりメタボン
こんにちは！！
最近の寒さのあまり動きが鈍くなってきたぽっちゃりメタボンです。
健康診断も迫ってきているのでラーメンの食べすぎには気をつけなければ。。
さて、今週もはりきってはじめましょう。
▼ 前回までのおさらい
前回までログマイナーについての基本的な機能について、検証も交えながら
ご紹介してきました。
第一回でも述べましたが、ログマイナーには以下の用途が考えられます。
・論理的な破損の特定
→アプリケーション・レベルで発生したエラーなど、
データベースの論理的破損が発生した時期を特定
・リカバリを行うための処置を特定
→リカバリを行うために必要なSQLを特定
・傾向分析
→どの表にどんな更新が多いかなどの統計情報を取得し、
チューニング時の優先順位を決定することができる
ですが、読者の皆様は今までログマイナーなんて使っていないですよね？
ログマイナーはメジャーな機能ではないので、そもそも使い方がよくわから
なかったり、ログマイナーを単体で使用しなければならないようなシチュエ
ーションがなかったのではないでしょうか。
そこで、これからお届けしていく内容として
「ログマイナーにしかできないこと」に注目してみたいと思います。
▼ ログマイナーの勘所
「ログマイナーにしかできないこと」で価値のあることとは・・・
それを、ずばり言ってしまうと
「レコード単位で更新前後の値を参照できること」です。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
では、この「レコード単位で更新前後の値を参照できること」は、
どんな時に必要になるのでしょうか？？？
そうです。「監査」なんです。
データベースに格納されているオブジェクトの特性、データの特性によって
は、「誰が、いつ、どのデータを書き換えたか」というようなデータの更新
履歴を管理する必要があります。
そんなことはアプリケーションで既に実装していると思われる方もいらっしゃ
ると思いますが、想定外の経路でのデータ変更、つまり、改竄が行われていな
いことを証明しなさいと言われてしまった場合にはアプリケーションでのみの
履歴管理では難しいのではないでしょうか。
＃実際にお客様からそのようなご相談を受けたことがあります。
ログマイナーは、そんなあなたに役立ちます。
ということで今回からは、ログマイナーを監査、データベースセキュリティ
に使用する可能性を探っていきたいと思います。
▼「ログマイナーにしかできないこと」
=(イコール)「レコード単位で更新前後の値を参照すること」
ログマイナーを監査目的で使用するにあたり、一番の見どころは、UNDO、REDO
の情報をREDOログから取得し、「レコード単位で更新前後の値を参照できる」
ことです。
なぜならば、Oracle Databaseに標準で実装可能な監査機能である、Audit Trail、
FGAでは更新前後の特定のカラムの値を参照することはできないからです。
＃ Audit Trailについてはこちらのバックナンバー
https://old.insight-tec.com/mailmagazine/ora3/vol163.html
では具体的に、どんな時にレコード単位で更新前後の値を参照する必要がある
のでしょうか？
例えばこんなニーズをお持ちの方がいそうですよね？
・ 本日の会計テーブルに対する全ての変更履歴を確認したい。
・ 通常、実行されないプログラムからの変更データがあるかどうか確認したい
・ Audit Trailで取得している監査証跡とログマイナーの取得情報と結びつ
けたい
・ 特定ユーザの取引履歴を確認したい
上記のような要件をログマイナーを使ってどのように解決していけば良いの
でしょうか。はたまた、解決できないのでしょうか。
では、次週は上記の例で挙げたような要件に対してどのように
ログマイナーで解決していくかを具体的にお届けして行きたいと思います。
今回はここまでです！！
キンモクセイが香る 茅ヶ崎より