SQL データの変更の監査について、1 週間ほど前に SOF で質問しました。トリガーの使用に関する通常の話題が出てきましたが、SQL Server 2008 の CDC についての言及もありました。
私は今日それを試してみましたが、これまでのところとても良いです.1つだけサポートしているとは思えませんが、実際に誰が変更を行ったかを追跡しています. 誰がその声明を実行しましたか?
誰かが監査に CDC を使用したことがあるかどうか、また誰が変更を行ったかをどのように追跡したか知りたいです。
SQL データの変更の監査について、1 週間ほど前に SOF で質問しました。トリガーの使用に関する通常の話題が出てきましたが、SQL Server 2008 の CDC についての言及もありました。
私は今日それを試してみましたが、これまでのところとても良いです.1つだけサポートしているとは思えませんが、実際に誰が変更を行ったかを追跡しています. 誰がその声明を実行しましたか?
誰かが監査に CDC を使用したことがあるかどうか、また誰が変更を行ったかをどのように追跡したか知りたいです。
次を使用してCDCテーブルを直接変更しました 。ALTERTABLEcdc.dbo_MyTable_CTADD UserName nvarchar(50)NULL DEFAULT(SUSER_SNAME())
ところで、日付情報はすでに開始LSNフィールドと終了LSNフィールドにあるため、日付情報は必要ありません。
私の唯一の問題は、ユーザーが権限を変更できるWindowsグループを介してログインすることですが、UserNameフィールドは常に私のユーザー名であり、ユーザーのユーザー名ではありません。私はこの問題を回避する方法を見つけていません。
エドムンドさん、私の意見では、CDC はゴールデンタイムの準備ができていません。現在、CDC が有効になっている Visual Studio からデータベース プロジェクトを展開することに関して、かなりの苦労があるようです (DDL の変更は好きではありません)。さらに、CDC にはデータの有効期限が切れた場合のクリーンアップ プロシージャが組み込まれているようです。そのため、監査履歴を長期間保持することを本当に意図している場合は、これが悪い時期になる可能性があります。
また、誤解していた場合は訂正してください。SQL Audit は、ログインの失敗、DDL の変更など、SQL Server で発生する多数のイベントを監査するように調整されているようです。
Change Tracking は DDL 用であり、DML 用ではないため、運が悪いです。
テーブルから更新または削除された「古い」レコードをキャプチャすることが本当に意図されている場合、最良の答えは、dbo.TableName で Audit.TableName と update+delete トリガーを作成することです。また、TableName に CreatedBy DEFAULT SUSER、CreatedDate DEFAULT getdate()、ModifiedBy、ModifiedDate の列が含まれていることを確認してください。
CDC は実際には監査用に設計されていません。監査機能を探している場合は、SQL Server Auditを使用する必要があります。
理想的ではありませんが、CDC は誰が変更を行ったかを把握しないというのが一般的なコンセンサスのようですが、誰が変更をトリガーしたかを確認するために使用できる CreatedBy/Date 列と UpdatedBy/Date 列を実装しました。もちろん、これを機能させるには、行を更新する SP または SQL ステートメントで、それぞれ suser_name() と getDate() を使用して UpdatedBy/Date フィールドを適切に明示的に設定する必要があります。これは箱から出してすぐに使えるといいと思います.CDCに意図されていないことをさせていることに同意しますが、私もCDCを使用して、従来のトリガーを使用する代わりにデータ変更を非同期に監査しようとしています.