挿入/更新トリガーによってマスターテーブルの変更を追跡する監査テーブルがあります。トリガーは、マスターテーブルのすべての新しいフィールド値を監査テーブルにコピーします。マスターテーブルで挿入/更新が発生した時刻を追跡するdatetime
列が監査テーブルにあります(getdate()
)。
主キーと時間列に固有のインデックスがあります。問題は、マスターテーブルでほぼ同時に複数の更新が発生した場合、一意キー違反で終了することです。ナノ秒レベルの精度をキャプチャする日時タイプはありますか?
1 に答える
1
DB は、本質的に ACID を介して同じレコードの更新を処理する必要があります。master_table_id / updatetime 主キーを組み合わせて監査テーブルを「チーズ」して、短期間に「更新が多すぎる」ことを防ぐことは、おそらく正しいアプローチではありません...特に新しいハードウェアを介してパフォーマンスが向上するため...もっと多くの可能性がありますあなたのpkが妨げている「正当な」更新。
聞きたくないのですが、ミリ秒未満のレベルで同じ行を何度も更新する操作はどのようなものですか? JDBC または ADO 接続を介して同じ PK の col2、col3、col4 をすべて更新していますか?
これらの「多くの」更新を、ストアド プロシージャへの入力を介して 1 つのストアド プロシージャ呼び出しにまとめて、書き込み操作を制限できますか? これはより高速であり、監査証跡のチャーンが少なくなります。
于 2012-08-09T06:05:15.283 に答える