10gのエンタープライズエディションをお持ちの場合は、OracleのFine-GrainedAuditingをご覧ください。自分で転がすよりも間違いなく優れています。
ただし、バージョンが少ない場合、または何らかの理由でFGAが気に入らない場合は、次の方法で実行できます。重要なことは次のとおりです。アプリケーションテーブルごとに個別の監査テーブルを作成する 。
上で概説したテーブル構造と一致しないため、これは聞きたいことではないことを私は知っています。ただし、更新の影響を受ける各列のOLD値とNEW値を含む行を格納することは、非常に悪い考えです。
- スケーリングされません（10列に触れる1回の更新で、10個の挿入が生成されます）
- レコードを挿入するときはどうですか？
- いつでもレコードの状態を組み立てるのは完全な苦痛です
したがって、同じ構造のアプリケーションテーブルごとに監査テーブルを用意します。これは、アプリケーションテーブルにCHANGED_TIMESTAMPとCHANGED_USERを含めることを意味しますが、それは悪いことではありません。
最後に、これがどこをリードしているのかがわかっているので、各テーブルにトリガーを設定して、：NEW値のみを含むレコード全体を監査テーブルに挿入します。トリガーは、INSERTおよびUPDATEで起動する必要があります。これにより完全な履歴が得られ、レコードの2つのバージョンを比較するのは簡単です。 DELETEの場合、主キーのみが入力され、他のすべての列が空の監査レコードを挿入します。
反対意見は、これらすべてのオブジェクトを実装するにはテーブルと列が多すぎることです。ただし、テーブルを生成し、データディクショナリ（user_tables、user_tab_columns）からDDLステートメントをトリガーするのは簡単です。