私が過去に使用した簡単な方法の 1 つは、基本的には、監査したいテーブルの構造を反映した 2 番目のテーブルを作成し、メイン テーブルに更新/削除トリガーを作成することです。レコードが更新/削除される前に、現在の状態がトリガーを介して監査テーブルに保存されます。
効果的ではありますが、監査テーブル内のデータは、最も有用ではなく、レポートするのも簡単ではありません。データの変更を監査するためのより良い方法があるかどうか疑問に思っていますか?
これらの記録はあまり更新されるべきではありませんが、非常に機密性の高い情報であるため、すべての変更が監査され、簡単に報告されることが顧客にとって重要です。
このテーブルの書き込みと読み取りの量はどれくらいだと思いますか?
Table、Column、OldValue、NewValue、User、および ChangeDateTime の列を含む単一の監査テーブルを使用しました。これは、DB 内の他の変更と連携するのに十分な汎用性があり、大量のデータがそのテーブルに書き込まれている間、レポートします。そのデータは、1 日の使用頻度の低い時間帯に実行できるほど十分にまばらでした。
追加: データ量とレポートの量が問題になる場合は、監査テーブルを読み取り専用データベース サーバーに複製して、マスター サーバーの作業を停止させることなく、必要なときにいつでもレポートを実行できるようにすることができます。
次の 2 つのリンクが役立つことがわかりました。
CLR と単一の監査テーブルを使用します。
SQL 2005 CLR を使用した汎用監査トリガーの作成
監査対象のテーブルごとにトリガーと個別の監査テーブルを使用します。
SQL Server データへの変更を監査するにはどうすればよいですか?
組み込みの監査パッケージはありますか? Oracle には優れたパッケージがあり、SQL を変更している悪者がアクセスできないように、監査の変更を別のサーバーに送信することさえできます。
彼らの例は素晴らしいです...監査テーブルを変更している誰かに警告する方法を示しています。
OmniAuditは、必要なソリューションとして適している可能性があります。独自の監査ルーチンを作成することに満足しているので、これまで使用したことはありませんが、良さそうです。
Greg の回答で説明されているアプローチを使用し、テーブル トリガーから呼び出されるストアド プロシージャを監査テーブルに入力します。