Rowversion を使用して OLTP データベースの最新の変更のほとんどを取得するウェアハウス用のインクリメンタル ロード ルーチンがあります。10 分ごとに実行され、1 日に 1 ～ 2 回スタックします。
(NOLOCK)テスト対象の ROWVERSION を含む 2 つを除いて、プルするほぼすべてのテーブルにヒントがあります。(最も更新された 2 つのテーブルの変更のみをテストしています。残りは、一晩で完全に再作成することで対処できます。これにはいくつかのリスクがありますが、回避しているようです。)
このハングは、そのテーブルのレコードで永続ブロックにヒットした場所で発生していると推測しています。私たちのウェアハウスでは完全な一貫性は重要ではないので、(READPAST)rowversion でテストされたテーブルで、ロックされたテーブルが次に解放されたときにそれらを選択したいと考えています。
それを効率的に行う簡単な方法はありますか？アイデアは 1 つまたは 2 つあるのですが、行のバージョン管理を正しく理解するには複雑すぎるようです。
基本的に、一貫性に達するのに 10 分ではなく 20 分かかるレコードは気にしませんが、(NOLOCK)その ROWVERSION センシティブ テーブルに頼って、レコードのコミットされたバージョンを完全に失うことは気にします。