スナップショットアイソレーションを使用すると、SQL Serverデータベースの書き込みが遅くなりますか？

システムで多くのデッドロックが発生しています。

それらを修正するためにスナップショットアイソレーションを使用したいのですが、私のDBAはそれについて予約しています。

彼の懸念の1つは、スナップショット分離が書き込み速度を低下させることです。これは、キャッシュに書き込んでからTempDb（行バージョン）に書き込む必要があり、呼び出し元に戻ることができるためです。

「通常の」書き込みは、キャッシュに書き込むだけで実行できます。

これは行のバージョン管理のしくみですか？それともそれよりも複雑ですか？それはどういうわけかこれらを並行して行いますか？

それともスナップショットアイソレーションでは書き込みが遅くなりますか？

これは、キャッシュに書き込み、次にTempDb（行バージョン）に書き込む必要があるため、呼び出し元に戻ることができるためです。

いいえ、不正解です。バージョン管理の存在下での書き込みは、各書き込みがディスク（tempdbの場合）にアクセスする必要があるため、レイテンシが高くなることを意味しますが、これは正しくありません。tempdbへの書き込みは、「キャッシュ」への書き込みでもあります。唯一の「待機」は、ログを強化する必要があるCOMMIT時に発生します。バージョン管理では、DBログとtempdbログの両方を強化する必要があることは事実ですが、これは必ずしもレイテンシが高いことを意味するわけではありません（IOは異なるストレージパスで並行している必要があり、tempdbは頻繁に使用されるLDFとは別のドライブに保存されます。正しい？）。詳しい説明については、「仕組み：ボブドーアーのSQL Server I / Oプレゼンテーション」をご覧ください。ここで伝えるよりも、DBAがこれをよく理解していることを願っています。

他の投稿で述べたように、スナップショットにはINSERTSのコストがなく、更新と削除のコストは簡単に軽減できます。行のバージョン管理のリソース使用量は、トレードオフについて説明しています。この時点で、おそらく現実的なワークロードでテストする必要があります。これは、発生する影響を適切に評価する唯一の方法です。

デッドロックが発生している場合は、アプリケーションに他の問題があると思います。スナップショット分離は通常、待機ロックを減らすのに役立ちますが、デッドロックの根本は通常、アプリケーションのさまざまなアクセス方法であり、一貫したパターンを守ることで防止する必要があります。デッドロックに関する議論は複雑であり、デッドロックに関する多くのリソースがあります。

tempDBの負荷が増加するため、DBAは分離レベルをスナップショットに変更することについて懸念を抱くのは当然です。一般的には、スナップショット分離を使用することをお勧めしますが、これはデッドロックへの対処の1つに過ぎないと思います。1つのトランザクションが行Aを更新してからBを更新し、他のトランザクションが行Bを更新してからAを更新するという、ダーティ書き込みが発生する可能性があります。