Oracle での監査について助けが必要です。多くのテーブルを持つデータベースがあり、任意のフィールドの任意のテーブルに加えられたすべての変更を監査できるようにしたいと考えています。したがって、この監査で必要なものは次のとおりです。
そのため、任意のテーブルの監査を実行するはずのトリガーの作成を開始しましたが、問題が発生しました...
前に述べたように、非常に多くのテーブルがあり、テーブルごとにトリガーを作成することはできません。したがって、トリガーを起動するテーブルに対して動的に動作できるマスタートリガーを作成するという考え方です。私はそれをやろうとしていましたが、まったく幸運ではありませんでした....オラクルは、コードによって宣言され、私たちがやりたいように動的に宣言されていないテーブルに対してのみトリガー環境を制限しているようです。
これを行う方法や、この問題を解決するためのその他のアドバイスについて何か考えはありますか?
10g エンタープライズ エディションを使用している場合は、Oracle のFine-Grained Auditingを参照してください。自分で巻くより断然いいです。
ただし、バージョンが低い場合、または何らかの理由で FGA が好みに合わない場合は、次の方法でそれを行うことができます。重要なことは、アプリケーション テーブルごとに個別の監査テーブルを作成することです。
上で概説したテーブル構造と一致しないため、これが聞きたいことではないことはわかっています。ただし、更新の影響を受ける各列の OLD 値と NEW 値を含む行を格納するのは、非常に悪い考えです。
そのため、アプリケーション テーブルごとに同じ構造の監査テーブルを用意します。これは、CHANGED_TIMESTAMP と CHANGED_USER をアプリケーション テーブルに含めることを意味しますが、これは悪いことではありません。
最後に、これがどこにつながるかを知っているので、:NEW 値だけを含むレコード全体を監査テーブルに挿入するトリガーを各テーブルに設定します。トリガーは、INSERT および UPDATE で起動する必要があります。これにより、完全な履歴が得られます。レコードの 2 つのバージョンを簡単に比較できます。DELETE の場合、主キーのみが入力され、他のすべての列が空の監査レコードが挿入されます。
これらすべてのオブジェクトを実装するには、表と列が多すぎるという異論があります。ただし、テーブルを生成し、データ ディクショナリ (user_tables、user_tab_columns) から DDL ステートメントをトリガーするのは簡単です。
独自のトリガーを作成する必要はありません。
オラクルには、柔軟できめ細かい監査証跡サービスが付属しています。この文書(9i) を出発点として見てください。(編集:同じドキュメントの 10g バージョンと 11g バージョンのリンクを次に示します。)
消防ホースから水を飲むように多くの監査を行うことができます。これにより、ある時点でサーバーのパフォーマンスが低下する可能性があります。または、監査情報が多すぎてそこから意味のある情報をすばやく抽出できなくなる可能性があります。および/または多くのディスク容量を消費する可能性があります。本当に必要な監査情報の量と、それを保持する必要がある期間について、時間をかけて考えてください。これを行うには、基本的な構成から始めて、実際に収集している監査証跡データの種類のサンプルを取得できるようになってから、調整する必要がある場合があります。