問題タブ [snapshot-isolation]

SQL Server 2008 データベースとSET ALLOW_SNAPSHOT_ISOLATION ON、列 ID (主キー) と SSN (一意の非クラスター化インデックス) を持つ Person テーブルがあります。

データベース内の行の 1 つは、ID = 1、SSN = 776-56-4453 です。

1 つ 1 つの接続で、次のことが起こります。

次に、別の接続で：

予想どおり、最初の接続では、2 番目の接続の実行が終了した後も SSN が '777-77-7777' として表示され続けます。最初の接続の実行計画は、SSN で「クラスター化されたインデックス シーク」を示していますが、他の接続でインデックス キーが更新されている場合、最初の接続はどのようにインデックスを使用し続けることができますか?

これに対応するために、SQL サーバーは複数のバージョンのインデックスを保持するために何か特別なことをしますか?

スナップショット分離レベルのパフォーマンス特性を理解しようとしているので、行の以前のバージョンから古いデータを取得する場合でも、SQL Server が既存のインデックスを使用できるほどスマートであることを確認したいと考えています。

以下の記述：

このSQLエラー3960が表示されます：

更新の競合により、スナップショット分離トランザクションが中止されました。スナップショット分離を使用してデータベース 'myDatabase' のテーブル 'dbo.Companies' に直接または間接的にアクセスし、別のトランザクションによって変更または削除された行を更新、削除、または挿入することはできません。トランザクションを再試行するか、更新/削除ステートメントの分離レベルを変更してください。

私が理解している限り、エラーメッセージから、dbo.Companies別の接続が変更されている間は、テーブルを更新、削除、または挿入しないでくださいdbo.Companies。

しかし、別のテーブルdbo.Changes( への外部キーを持つdbo.Companies) に新しい行を挿入していて、 で参照されている行を削除していなかったのに、主キーではなく でdbo.Companies行を更新しただけだったのはなぜですか? dbo.Companiesこれはうまくいくはずですよね？(SQL Server のバグですか?)

アップデート：

テーブルは次のようになります。

2番目の更新は行っています:

Microsoftのサイトhttp://msdn.microsoft.com/en-us/library/ms173763.aspxで読んだ

そのSQLServerは、データベースが回復されている場合を除いて、データの読み取り時にロックを要求しません。

READ_COMMITTED_SNAPSHOT / SNAPSHOTISOLATIONを使用しているSQLServerが共有ロックをまったく使用していないということですか？そんなことがあるものか？

たとえば、2つのトランザクションがある場合。最初のトランザクションT1は、いくつかの行を更新しようとしています。2番目のトランザクションT2は、同じ行の読み取りを開始します（このトランザクションは、彼を出力バッファー、応答バッファー、またはSQL Serverで呼び出されるものにコピーします）。同時に、トランザクションT1はその行の更新を開始します（最初にバージョン管理された行を作成しました）。

トランザクションT2がコミットされていないデータを読み取る可能性はありませんか？トランザクションT2は、T1が更新する前にその行のコピーを開始したため、その行に排他ロックがないことを忘れないでください。

この状況はさらに可能であり、データのコピー中にその行に共有ロックを設定せずにこれを回避するにはどうすればよいですか？

Paxosベースのレプリケーションスキームとスナップショット分離などのさまざまな同時実行モデルとの実際の関係は何であるか疑問に思いました。誰かがこれらの2つをそれらの関係に関してそしていくつかの実際的な例で親切に説明することができますか？

一部のインデックスに 64 ビットのハッシュベースの B+ ツリーを使用する NoSQL データベースを開発しています。現在、永続的な B+ ツリーにスナップショット分離マルチバージョン同時実行制御 (SI MVCC) を適用することを検討しています。

私が最初に直面した問題は、B+ ツリーのすべてのノードがツリーの次のノードへのポインタを保持していることです。次のノードが配置されているファイル内のバイト アドレスへの 64 ビット ポインター。したがって、レコード ノードを更新する場合、ルート ノードまでの B+ ツリーのそのブランチ内のすべてのノードを更新する必要があります。非常に多くのディスク更新を回避するためにこれを行うためのより良い/簡単な方法はありますか (通常は 4 'ディスクセクター/ノードは、レコードの書き込みごとに更新する必要があり、各ノードは単一のディスクセクター内に収まります)? おそらく、すべてのリンクされたノードの概要を保持する別のディレクトリ レコードですか?

ONコミットされたスナップショット分離を読み取り、データベースの分離を許可しました。まだデッドロック エラーが発生します。私は何が起こっているのかを知っていると確信しています...

1. 最初のトランザクションは、トランザクションの開始時にシーケンス番号を取得します。
2. 2 番目のトランザクションは、トランザクションの開始時に新しいシーケンス番号を取得しますが、最初のトランザクションが既に取得した後です (2 番目のシーケンス番号は最初のシーケンス番号よりも新しい)。
3. 2 番目のトランザクションは、最初に更新ステートメントに到達します。行のバージョン管理をチェックすると、最初のトランザクションがまだ更新されていないため、両方のトランザクションに先行するレコードが表示されます。行のシーケンス番号がコミットされた状態にあることがわかり、順調に進んでいます。
4. 最初のトランザクションが順番に実行され、2 番目のトランザクションと同様に、コミットされた同じシーケンス番号が検出されます。コミットしようとすると、別のトランザクションがコミットしようとしているレコードを既に更新しており、それ自体をロールバックする必要があることがわかります。

これが私の質問です。このロールバックはトレースでデッドロックとして表示されますか?

Microsoft SQL Server では、READ_COMMITTED_SNAPSHOT ISOLATION を使用します。

セッション 1 で、プリンシパルを 4000 から 5000 に更新します。

セッション 2 では、次のように言います。

セッション 1 トランザクションがコミットされていないため、4000 が返されます。

READ_COMMITTED_SNAPSHOT 分離モードを使用せず、使用する場合

1. READ COMMITTED ISOLATION モードの場合、セッション 2 は待機し続けます
2. READ_UNCOMMITTED ISOLATION モードを使用すると、セッション 2 で 5000 が返されます (select ステートメントで nolock を使用するのと同じです)。

Oracle では、同等のコマンド セットを実行すると、デフォルトで READ_COMMITTED_SNAPSHOT 分離モードが設定されているかのように動作します。

更新が完了する前に、SNAPSHOT 分離モードが tempdb に書き込むという Microsoft の記事を読みました。

-オラクルはデフォルトでどのようにこれを実現していますか?

-ディスクにも書き込みますか? I / Oの問題が発生しますか？

- Oracle のデフォルトのロック レベルは SQL サーバーとは異なりますか?

あなたの助けと時間を前もってありがとう。

以下のコードを使用すると、スナップショット分離をオフにできません。SQL Server 2012 ボックスを使用しています。新しい空のデータベースを作成し、スナップショット分離をオンにすることはできますが、オフに戻すことはできません。

「allow_snapshot_isolation OFF」行は、車輪を回転させるだけです。

次のシナリオの SQL Server 2012 データベースのソリューションを設計しています。

• データベースには、4 つまたは 5 つのテーブル間のいくつかの単純な親子関係を持つ約 1M のレコードが含まれています
• データベースには 24 時間 365 日、高負荷の読み取りがあります
• 1 日に 1 回、データベースにマージする必要がある約 1000 の挿入、更新、および削除を含むバッチを受け取りますが、この数はさらに多くなる場合があります。
• 毎日のバッチとは別に、データベースへの他のライターはありません

いくつかの「特別な」要件があります

1. これらの更新により、リーダーが大幅な遅延を経験することはありません。
2. リーダーの観点から、バッチ全体をアトミックに処理する必要があります。部分的に処理されたバッチがリーダーに表示されないようにする必要があります
3. 更新が途中で失敗した場合は、バッチのすべての変更をロールバックする必要があります
4. バッチ自体の処理はタイム クリティカルではありません。単純な実装では数分程度で十分です。

私が考えている選択肢は

• 単一のデータベース トランザクションを更新バッチ全体にラップし (これは大規模なトランザクションになる可能性があります)、スナップショット分離を使用して、更新の実行中にリーダーが元のデータを読み取れるようにします。

• パーティションの切り替えを使用する、このようなユースケースを念頭に置いて設計された機能のようです。欠点は、バッチの処理を開始する前に、すべての元のデータのコピーを作成する必要があることです。

• データベース全体を切り替えます。データベース全体のコピーを作成し、このコピーでバッチを処理してから、すべてのクライアントをこのデータベースにリダイレクトできます (接続文字列を変更するなど)。これにより、データベースを読み取り専用にし、場合によってはスケーラビリティのためにデータベースの複数のコピーを作成することもできます。

これらのオプションのうち、このシナリオに最も適しているのはどれですか? また、その理由は何ですか?

データベースで SNAPSHOT 分離レベルがオンになっているかどうかを知るために、SQL Server 2008 R2 の SSMS でどの SQL を実行しますか?