スナップショットアイソレーションを使用すると、SQL Serverデータベースの書き込みが遅くなりますか？
システムで多くのデッドロックが発生しています。
それらを修正するためにスナップショットアイソレーションを使用したいのですが、私のDBAはそれについて予約しています。
彼の懸念の1つは、スナップショット分離が書き込み速度を低下させることです。これは、キャッシュに書き込み、次にTempDb（行バージョン）に書き込む必要があり、呼び出し元に戻ることができるためです。
「通常の」書き込みは、キャッシュに書き込むだけで実行できます。
これは行のバージョン管理のしくみですか？それともそれよりも複雑ですか？どういうわけかこれらを並行して行いますか？
それともスナップショットアイソレーションでは書き込みが遅くなりますか？
これは、キャッシュに書き込み、次にTempDb（行バージョン）に書き込む必要があるため、呼び出し元に戻ることができるためです。
いいえ、不正解です。バージョン管理の存在下での書き込みは、各書き込みがディスクにアクセスする必要があるため（tempdbの場合）、レイテンシが高くなることを意味しますが、これは正しくありません。 tempdbへの書き込みは、「キャッシュ」への書き込みでもあります。唯一の「待機」は、ログを強化する必要があるCOMMIT時に発生します。バージョン管理では、DBログとtempdbログの両方を強化する必要があることは事実ですが、これは必ずしもレイテンシが高いことを意味するわけではありません（IOは異なるストレージパスで並行する必要があり、tempdbが保存されます）使用頻度の高いLDFとは別のドライブにありますよね？）完全な説明については 仕組み：ボブ・ドールのSQL Server I/Oプレゼンテーション DBAがこれを理解するよりも理解していることを願っていますここに。
他の投稿で述べたように、スナップショットにはINSERTSのコストがなく、更新と削除のコストは簡単に軽減できます。 Row Versioning Resource Usage はトレードオフを説明します。この時点で、おそらく現実的なワークロードでテストする必要があります。これは、あなたが受ける影響を適切に評価する唯一の方法です。
デッドロックが発生している場合は、アプリケーションに他の問題があると思います。スナップショット分離は通常、待機ロックの削減に役立ちますが、デッドロックの根本は通常、アプリケーションのさまざまなアクセス方法であり、一貫したパターンを守ることで防止する必要があります。デッドロックに関する議論は複雑であり、デッドロックに関する多くのリソースがあります。
TempDBの負荷が増加するため、DBAは分離レベルをスナップショットに変更することについて懸念を抱くのは当然です。一般的には、スナップショット分離を使用することをお勧めしますが、これはデッドロックへの対処の1つにすぎないと思います。 1つのトランザクションが行Aを更新してからBを更新し、別のトランザクションが行Bを更新してからAを更新するというダーティな書き込みが発生する可能性があります。