SQL ServerのREAD COMMITTED SNAPSHOTとSNAPSHOT

私はSQL Server READ COMMITTED SNAPSHOTとSNAPSHOT分離レベルの違いを調査していて、次のリソースに出会いました。

行バージョン管理ベースの分離レベルの選択

ほとんどのアプリケーションでは、次の理由から、スナップショットアイソレーションよりも行バージョン管理を使用したコミットコミットアイソレーションをお勧めします。

• スナップショット分離よりも少ないtempdbスペースを消費します。

• スナップショットアイソレーションは、行のバージョン管理を使用した読み取りコミットアイソレーションには適用できない更新の競合に対して脆弱です。スナップショット分離で実行されているトランザクションがデータを読み取ってから別のトランザクションで変更されると、スナップショットトランザクションによる同じデータへの更新により更新の競合が発生し、トランザクションが終了してロールバックされます。これは、行のバージョン管理を使用した読み取りコミット分離の問題ではありません。

私はこれらのトピックにやや不慣れですが、上記のリンクから2つの箇条書きを理解できないようです。

1. これらのモードでtempdbスペースが異なるのはなぜですか？一方は他方よりも詳細なバージョン管理を保存しますか？

2. スナップショット分離は、更新の競合に対してより脆弱なのはなぜですか？

1. READ COMMITTED SNAPSHOT各ステートメントの後に新しいスナップショットを使用します。これは、より少ない行バージョンが維持されることを意味します。（ドキュメントから引用した文は、これが常に真であると示唆しているため、やや誤解を招く可能性がありますSNAPSHOT。長時間実行されるトランザクションの場合にのみ真です。）スナップショット行バージョンは書き込み時に作成されます。読み取りは、tempdbに入力される内容には影響しません。作家は、将来どのような読み取りが行われるかを予測することはできません。読者は、パージできるもののみに影響します。
2. ときにSNAPSHOTトランザクションがT1別のトランザクションによって変更された行への書き込みを行うT2間の時間でT1開始し、T1書き込みをしようとし、文は更新競合エラーで失敗します。これは楽観的な同時実行モデルです。With READ COMMITTED SNAPSHOT T1はT2、行のXロックを解放して通常どおり続行するのを待ちます。

スナップショットと読み取りコミットスナップショットのもう1つの違いは次のとおりです。

1. スナップショット

最初のセッションで

TRANアイソレーションレベルのスナップショットを設定するTRAN SELECT * FROM TB1 ..... .....

2回目のセッションで

TB1 SET NAME = NAME + 'test'の更新id = 1

最初のセッションで

SELECT * FROM TB1-これは、name = 'test'ではなく、ID = 1の値名を返しますCOMMIT TRAN

コミットスナップショットの読み取りでは、セッション1の最初の選択でid = 1の名前が返され、2番目の選択で名前+ 'test'が返されます。

そのため、スナップショット分離では、SQL SERVERはトランザクションの開始時にスナップショットを作成し、トランザクション全体でそのスナップショットから読み取ります。

読み取りコミットスナップショットでは、トランザクション中にすべてのSELECTステートメントに対してスナップショットが作成されます。