大規模なSQL Server 2008テーブルは、通常、SNAPSHOT ISOLATIONトランザクションを使用して（比較的）小さなチャンクで更新されます。スナップショットは、チャンクが重複しないため、これらの更新ではうまく機能します。これらの更新は、1回の長期実行操作ではありませんが、トランザクションによってグループ化された多数の小さな1行挿入/更新です。TSQLスナップショット分離では、ロックされていない行のみを更新できますか？
現在ロックされていないすべての行を更新するには、優先度の低いトランザクションを使用します。誰も私はこの動作を得ることができるか知っていますか？別のSNAPSHOT ISOLATIONトランザクションは、行が衝突するとすぐに失敗するか、失敗する前にできるすべてのものを更新しますか？
SET DEADLOCK_PRIORITY LOWを試してみるといいですか？おそらく、更新されていない行のみを対象とする再試行ループでWHEREがありますか？
スナップショットアイソレーションは実際には機能しません。オプティミスティック・ロック・モデルは、書き込み/コミットの準備ができるまで、ロックまたは競合をチェックしないことを意味します。また、 '優先度'自体のクエリを設定することはできませんし、更新プログラムでREADPASTヒントを使用することもできません。
各更新は暗黙的なアトミックトランザクションです。したがって、1つの更新が1つのトランザクションで失敗した場合（それらはすべて1つのトランザクションで失敗します）、すべてがロールバックされます。
SET DEADLOCK_PRIORITYは、取引が取引の際にロールバックされるプリファレンスを設定します（そうでないと、最も安いロールバックが選択されます）。
定期的な衝突が予想される場合、try-catchはかなり必要です。
リトライループは、異なるロックモデルを使用し、NOWAITヒントを使用してブロックされるクエリをスキップするように動作します。
SNAPSHOT ISOLATIONトランザクションは、更新の競合が発生するとすぐに失敗します。ただし、データベースの外部にあるキューを使用して、更新プログラムの優先順位付けを行います。
この点を明確にしていただきありがとうございます。これらの2種類のアップデートは、さまざまなコンポーネントから来ていますが、それらをスケジュールする方法を見ていきます。 – Djof
スナップショットアイソレーションが並行性を書くのに適していないと思うのはなぜか不思議です。並行更新が行ロックで失敗するのを見たので、テーブル自体はロックされていないと思います。ワークロードを少し説明するための説明を少し変更しました。なぜ私が優先順位について話していたのですか。あまりにも悪いことに、「書き込み」はありません。あなたのご意見ありがとうございます。 – Djof
：私はそれを書いたときに私の頭の中でコミットされたスナップショットを読みました。それでも、「最後の瞬間」までロック/競合を実際にチェックしないため、（ロックされていない行の更新のみ）希望の方法では動作しません。 –
ロールバックについては正しくありません。 – Djof