問題タブ [read-committed-snapshot]

SQL Server で READ COMMITTED SNAPSHOT よりも SNAPSHOT 分離レベルを使用するタイミングを理解するのを手伝ってくれませんか?

ほとんどの場合、READ COMMITTED SNAPSHOT が機能することは理解していますが、いつ SNAPSHOT 分離を行うかはわかりません。

ありがとう

Sql Server 2005 で読み取り/書き込み比率を照会するにはどうすればよいですか? 知っておくべき注意事項はありますか?

おそらく、DMV クエリ、標準レポート、カスタム レポート (パフォーマンス ダッシュボードなど)、または Sql Profiler トレースの調査で見つけることができます。正確にはわかりません。

なぜ私は気にするのですか？

Web アプリのデータ層のパフォーマンスを改善するために時間を費やしています。何百万ものレコードと何千ものユーザーを扱っています。

私が検討しているポイントの 1 つは、データベースの同時実行性です。Sql Server は、既定でペシミスティック コンカレンシーを使用します。これは、書き込みの多いアプリに適しています。私のアプリが読み取り負荷が高い場合は、Jeff Atwood が StackOverflow で行ったread committed snapshotように、オプティミスティック コンカレンシー (分離レベル: )に切り替える可能性があります。

スナップショット分離がこの問題を解決することはわかっていますが、オーバーヘッドを回避できるように、この特定のケースで NOLOCK が安全かどうか疑問に思っています。

次のようなテーブルがあります。

テーブルへの更新はありません。削除は発生する可能性がありますが、テーブルのもう一方の古い端に影響を与えるため、SELECT と競合することはありません。挿入は定期的であり、(Id, Date) インデックスへのページ分割は非常に一般的です。

標準の INSERT と SELECT の間に次のようなデッドロック状況があります。

INSERT は Cx (Date, Id; Value) の次に Ix (Id, Date) のロックを取得しますが、SELECT は Ix (Id, Date) と Cx (Date, Id; Value) のロックを取得するためです。これは、SELECT が最初に Ix をシークし、次に Cx のシークに参加するためです。

クラスター化インデックスと非クラスター化インデックスを交換すると、このサイクルが中断されますが、他の (より複雑な) SELECT とのサイクルが発生するため、受け入れられる解決策ではありません。

NOLOCK を SELECT に追加すると、この場合に問題が発生する可能性はありますか? 返品できますか:

1. TOP 1を頼んだのに複数行？
2. 行が存在し、コミットされているにもかかわらず、行がありませんか?
3. 最悪なのは、WHERE 句を満たさない行ですか?

私はこれについてオンラインで多くのことを読みましたが、私が見た過大または過少の異常の唯一の再現 ( 1 つ、2 つ) はスキャンを伴います。これには、シークのみが含まれます。Jeff AtwoodのNOLOCK の使用に関する投稿があり、良い議論が生まれました。Rick Townsend のコメントに特に興味を持ちました。

第 2 に、ダーティ データを読み取ると、まったく間違った行を読み取るリスクが生じます。たとえば、select が行を見つけるためにインデックスを読み取る場合、select が実際のデータ行を読み取るときに、更新によって行の場所が変更されます (たとえば、ページ分割またはクラスター化インデックスへの更新が原因で)。 、もう存在しないか、まったく別の行です!

これは、挿入のみで更新なしで可能ですか? もしそうなら、挿入専用テーブルでのシークでさえ危険である可能性があると思います。

アップデート：

スナップショット分離がどのように機能するかを理解しようとしています。トランザクションがテーブルを読み取り (共有ロックなしで!)、関心のある行を見つけて、tempdb のバージョン ストアから古いバージョンの行を取得する必要があるかどうかを確認する、行ベースのようです。

しかし、私の場合、複数のバージョンを持つ行はないため、バージョン ストアはかなり無意味に思えます。また、行が共有ロックなしで見つかった場合、NOLOCK を使用した場合とどう違うのでしょうか?

SQL Server 2005 データベースに対して COM データ アクセス レイヤーを使用する大規模な Web アプリケーションがあります。デフォルトでは、分離レベルは READ_COMMITTED です。今、私は READ_COMMITTED_SNAPSHOT 分離レベルがどのように機能するかを理解しており、MSDN を読むと透過的に有効にできると書かれています。しかし、私はまだ懐疑的です。:) READ_COMMITTED から READ_COMMITTED_SNAPSHOT に変更した場合、実装上の方法で、アプリケーションが壊れないことが保証されていますか (アプリケーションがすべてを本で行うと想定しないでください)。COM レイヤーに追加の例外はスローされませんか? トランザクションのセマンティクスは同じですか?

PS。実装方法とは、ロックの代わりに行のバージョン管理を使用するだけで、READ_COMMITTED_SNAPSHOT 分離レベルが意図的に READ_COMMITTED とまったく同じように機能するように実装されたということですか?

この分離モードに切り替えた洞察やご自身の経験に感謝します。

たとえば、個人テーブルがあり、1行しかありません-

1 つの接続で

同時に別の接続で：

Q1: update ステートメントのタイミングに基づいて、select が次のような結果を返すことは可能ですか?

どちらの接続も明示的なトランザクションを使用せず、どちらもデフォルトのトランザクション分離レベル READ COMMITTED を使用します。

問題は、SQLステートメントの開始時に取得されたロックがステートメントが完了するまで存在し続けるかどうか、またはステートメントがロックを解放して同じロックを再取得できるかどうかを理解するのに役立つことです行が同じステートメントで 2 回使用されている場合は?

Q2:set read_committed_snapshot onがデータベースに設定されている場合、質問への回答は変わりますか?

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が更新する前にその行のコピーを開始したため、その行に排他ロックがないことを忘れないでください。

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

データベースで SET READ_COMMITTED_SNAPSHOT ON を指定して IsolationLevel.Snapshot を使用した場合の影響について興味があります。IsolationLevel 列挙のドキュメントには、スナップショット分離からの動作が記載されていますが、これは私たちの状況で探しているものではありません。

READ_COMMITTED_SNAPSHOT を有効にした後、IsolationLevel.Unspecified を指定する必要がありますか、それともこの値をまったく指定しないでください。または、IsolationLevel.Snapshot を指定した場合、READ_COMMITTED_SNAPSHOT を有効にした場合に期待される動作を実現できますか?

ありがとう！

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

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

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

SQL Server 2008 と同等の IBM DB2 9.7 の設定はありますか? パラメータは READ_COMMITTED_SNAPSHOT で、ON に設定でき、明らかにロックに影響します。