読み取り専用の分離レベルでデッドロック（SQL Server）が発生することはありますか？

Question

私はデッドロックについて理解しています。同じリソースに対して2つのプロセスが競合しようとしています.2つのプロセスは、同じデータ行に「書き込み」しようとしています。 1つのプロセスがすべてデータを読み取っている場合、他のプロセスがデータを更新している場合、そのプロセスはどのようにリソースの競合ですか？それでも、デフォルトのトランザクションレベル 'ReadCommitted'に設定されているデータベースでは、いくつかのデッドロック例外が発生しています。 ReadComitted definitin - 変更された（ただしまだコミットされていない）データは読み取れません。これは問題ありませんが、この「ダーティーリード」が発生した場合、SQL Serverはデッドロック例外をスローする必要がありますか？ 誰もがこのシナリオで実際の体験をしていますか？私はブログの投稿を見つけた（stackoverflowの開発者によると、これ以下）、これは本当かもしれないと主張する。

ありがとうございます。

Answer 1

はい、発生する可能性があります。それぞれに独自のトランザクションを持つ2つのプロセスがあるとします。最初の更新TableAはTableBを更新しようとします。次に、TableBはTableAを更新しようとします。あなたが不運な場合は、両方のプロセスが最初のステップを完了してから、次のステップを無期限に待って2番目のステップを完了します。

デッドロックを回避するための最も一般的な方法の1つです。テーブルを更新する順番に一致させることです。両方のプロセスがTableAを最初に更新しTableBを更新した場合、デッドロックは発生しません。

Answer 2

は、行を読みながらトランザクション分離レベルが最初にリソースすなわち上Shared Lockを取得ReadComittedが、我々はそれが資源にExclusive lockを取得し、行を更新しようとします。複数のユーザーが同じ行に共有ロックを持つことはできますが、1人のユーザーが行を更新しようとすると、その行に排他ロックが適用されます。その結果、最初にレコードを見ることができるユーザーがA dead lock行の共有ロックがユーザーが更新しようとしたとき第1ユーザーが排他ロックを既に持っています。 User1とUser2の両方が共有ロックを持っているシナリオを想像してみて、レコードを更新しようとすると、他のユーザーがトランザクションをコミットする必要がある行に対してExclusiveロックを取得します。 DEAD LOCKが発生します。
デッドロックの場合は、Priority Level is not set SQL Serverがいつか待ってから、RollBackトランザクションがcheaperでロールバックされます。

はいUser1がデータの読み取りのみを行い、User2が一部のデータの更新を試み、そのテーブルにクラスター化されていないインデックスがある場合は、可能です。

1）ユーザー1は、一部のデータを読み取り、参照を実行するためにクラスタ化されていないインデックスの共有ロックを取得してから、データ自体を返すためにデータを管理する共有ロックを取得しようとします。

2）書き込み/更新を行っているユーザー2は、最初にデータを含むデータベースページに排他的ロックを取得し、インデックスを更新するためにインデックスの排他ロックを取得しようとします。