ほとんどの場合、デッドロックは次のように説明されます。

プロセス1はリソースAをブロックします。

プロセス2はリソースBをブロックします。

プロセス1はリソースBにアクセスしようとしています。

プロセス2はリソースAにアクセスしようとしています。

その結果、一方のプロセスを中断して、他方のプロセスが実行を継続できるようにする必要があります。

しかし、これは相互ブロックの最も単純なバージョンであり、実際にはより複雑なケースに対処する必要があります。 この記事では、MS SQLのどの相互ロックに対応する必要があり、どのようにそれらと戦うかを説明します。

理論のビット

MS SQLなどの複雑なDBMSを使用する場合、一般的なクエリをブロックする方法とそのリソース、およびトランザクション分離レベルがクエリに与える影響を理解する必要があります。

これにあまり詳しくない人には、次の記事を読むことをお勧めします。

• ロックの粒度とロック階層
• ロックモード
• キーレンジロック
• トランザクション分離レベル

トランザクション分離レベルを選択

シリアライズ可能な分離レベルでトランザクションを使用すると、デッドロックが発生する可能性があります。 反復可能な読み取り分離レベルを使用する場合、以下で説明するデッドロックの一部は発生しません。 コミットレベルの読み取りがコミットされたトランザクションでは、最も単純なデッドロックのみが発生します。 コミットされていない読み取り分離レベルのトランザクションは、他のトランザクションの速度に実質的に影響を与えず、共有ロックを課さないため、読み取りによるデッドロックを引き起こすことはできません（ただし、データベーススキーマを変更するトランザクションではデッドロックが発生する可能性があります）。



トランザクション分離レベルは、デッドロックを考慮せずにシステムの速度に強く影響するため、トランザクションが実行するタスクに応じて分離レベルを正しく選択することが非常に重要です。 サンプルのヒントを次に示します。

• トランザクションがデータベース内のデータを変更し、同時にこのデータがデータベース内の既存のレコードと矛盾しないことを確認する場合、ほとんどの場合、シリアライズ可能な分離レベルが必要です。 ただし、並列トランザクションへの新しいレコードの挿入が現在のトランザクションの結果にまったく影響しない場合は、分離レベルの反復可能読み取りを使用できます。
• データを読み取るには、通常、トランザクションなしでデフォルトの分離レベル（コミット読み取り）を使用するだけで十分です。 ただし、読み取り中に一部を変更できる集計を読み取る場合、反復可能な読み取りレベルまたはシリアル化可能な分離レベルのトランザクションを使用する必要がある場合があります。
• 絶えず変化するデータのリアルタイム統計を表示する必要がある場合は、多くの場合、読み取り非コミット分離レベルを使用することをお勧めします。 この場合、統計には一定量のダーティデータが含まれますが（これが目立つことはほとんどありませんが）、レポートの構築はシステムの速度に実質的に影響しません。

デッドロックで再試行

数十種類のビジネストランザクションがあるかなり複雑なシステムでは、どのような状況でもデッドロックが発生しないようにすべてのトランザクションを設計できるとは考えられません。 デッドロックの防止に時間を費やすべきではありません。デッドロックの可能性は非常に小さいです。 ただし、ユーザーエクスペリエンスを損なわないために、相互ロックが原因で操作が中断された場合は、操作を繰り返す必要があります。 操作を安全に繰り返すには、入力データを変更せずに1つのトランザクションにラップする必要があります（または操作全体ではなく、各SQLトランザクションをRetryOnDeadlockの操作にラップする必要があります）。



C＃のRetryOnDeadlock関数の例を次に示します。

private const int DefaultRetryCount = 6; private const int DeadlockErrorNumber = 1205; private const int LockingErrorNumber = 1222; private const int UpdateConflictErrorNumber = 3960; private void RetryOnDeadlock( Action<DataContext> action, int retryCount = DefaultRetryCount) { if (action == null) throw new ArgumentNullException("action"); var attemptNumber = 1; while (true) { var dataContext = CreateDataContext(); try { action(dataContext); break; } catch (SqlException exception) { if(!exception.Errors.Cast<SqlError>().Any(error => (error.Number == DeadlockErrorNumber) || (error.Number == LockingErrorNumber) || (error.Number == UpdateConflictErrorNumber))) { throw; } else if (attemptNumber == retryCount + 1) { throw; } } finally { dataContext.Dispose(); } attemptNumber++; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RetryOnDeadlock関数は、時折発生するデッドロックでユーザーエクスペリエンスを向上させるだけであることを理解することが重要です。 非常に頻繁に発生する場合、状況を悪化させるだけで、システムの負荷が何度も増加します。

最も単純なデッドロックとの戦い

2つのプロセスが同じリソースにアクセスしているが順序が異なるためにデッドロックが発生する場合（記事の冒頭で説明）、リソースをブロックする順序を変更するだけで十分です。 原則として、特定のリソースセットが異なる操作でブロックされる場合 、 可能であれば、同じリソースが常に最初にブロックされる必要があります 。 このアドバイスは、リレーショナルデータベースだけでなく、一般的に相互ロックが発生するすべてのシステムに適用されます。



MS SQLに適用する場合、このアドバイスは少し簡略化しながら、次のように表現できます。複数のテーブルを変更するさまざまなトランザクションでは、最初に同じテーブルを変更する必要があります。

Shared-> Exclusive lock escalation

私たちのプラクティスで最も一般的なデッドロックは、次のように、分離レベルが反復可能読み取りまたはシリアル化可能のトランザクションで発生します。

1. トランザクション1はレコードを読み取ります（重畳Sロック）。
2. トランザクション2は同じレコードを読み取ります（2番目のSロックが課されます）。
3. トランザクション1はレコードの変更を試み、トランザクション2が終了してそのSロックを解放するのを待ちます。
4. トランザクション2は同じレコードを変更しようとし、トランザクション1が終了してSロックを解放するのを待ちます

。

このような相互ブロッキングの発生には、1つのリソースで十分であり、同じタイプの2つのトランザクションが戦っています。 戦いは、1つのレコードだけでなく、他のリソースに対しても実行できます。 たとえば、2つのSerializableトランザクションが特定の値を持つレコードの数をカウントし、同じ値を持つレコードを挿入すると、それらが待機しているリソースがインデックスのキーになります。



このようなデッドロックを回避するには、レコードを変更しようとしている2つのトランザクションのうち2つだけがそれを読み取ることができる必要があります。 特にこのために、更新ロックが導入されました。 次のように適用できます。

 SELECT * FROM MyTable WITH (UPDLOCK) WHERE Id = @Id
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ORMを使用していて、データベースからのエンティティの要求方法を制御できない場合、データベースから要求する前にレコードをブロックするために、純粋なSQLで別のクエリを実行する必要があります。 更新ロックを課すリクエストは、このトランザクションでこのレコードにアクセスする最初のリクエストであることが重要です。そうしないと、同じデッドロックが発生しますが、レコードが変更されたときではなく、更新ロックを適用しようとしたときです。

更新ロックを適用することにより、同じリソースにアクセスするすべてのトランザクションを順番に実行しますが、通常、同じリソースを変更するトランザクションは原則として並行して実行できないため、これは正常です。

このようなデッドロックは、データを変更する前にチェックするトランザクションで発生する可能性がありますが、めったに変更されないエンティティについては、RetryOnDeadlockを使用できます。 予備の更新ロックを使用するアプローチは、異なるプロセスによって並行して頻繁に変更されるエンティティにのみ使用するには十分です。



例

ユーザーはポイントの賞品を注文します。 各タイプの賞品の数は限られています。 システムは、利用可能な賞品よりも多くの賞品を注文できないようにする必要があります。 プロモーションの性質上、同じ賞品を注文するユーザーに対して定期的にレイドが発生します。 このような状況でRetryOnDeadlockを使用すると、ユーザーの襲撃中に、ほとんどの場合、賞品の注文はWebタイムアウトによって低下します。



残りの賞の数を賞の種類のレコードに保存すると、賞の注文トランザクションは次のようになります。

1. 更新ロックを適用することにより、賞の種類の記録を取得します。
2. 残りの賞品の数を確認してください。 0の場合、トランザクションを完了し、適切な応答をユーザーに返します。
3. まだ賞品がある場合は、残りの賞品の数を1つ減らします。
4. 注文した賞品の記録を追加します。

したがって、1人のユーザーのみが同じ種類の賞品を一度に注文できます。 同じ種類の賞品を注文するすべてのユーザーリクエストが並んでいますが、このアプローチは、RetryOnDeadlockまたはデッドロック発生時の消費者へのエラー出力よりも優れたユーザーエクスペリエンスを提供します。

残りの賞品の数を保存せずに、注文した賞品の数に基づいて計算する場合、注文した賞品の数を計算するときに更新ブロックを適用できます。 次のようになります。

 SELECT count(*) FROM OrderedPrizes WITH (UPDLOCK) WHERE PrizeId = @PrizeId
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以下で説明するほとんどのデッドロックは同様の方法で発生します。共有ロックを設定した後、データを変更しようとします。 しかし、これらの各ケースには独自のニュアンスがあります。

インデックス不可能なフィールドの選択

インデックスに属さないフィールドによってシリアル化可能なトランザクションでレコードを探している場合、共有ロックはテーブル全体に適用されます。 そうしないと、現在のトランザクションが完了するまで、他のトランザクションが同じ値のレコードを挿入できないことを確認できません。 その結果、このフィールドで選択を行ってからこのテーブルを変更するトランザクションは、同様のトランザクションで相互にブロックされます。



このフィールドのインデックス（または最初のフィールドが探しているフィールドである複数のフィールドのインデックス）を追加すると、このインデックスのキーはブロックされます。 そのため、シリアル化可能なトランザクションでは、レコードを探している列にインデックスがあるかどうかを考えることがさらに重要です。



覚えておくべき重要な点がもう1つあります。インデックスが一意である場合、要求されたキーにのみロックが適用され、一意でない場合、このキーに続く値もブロックされます。 一意でないインデックスによって異なるレコードを要求し、それらを変更する2つのトランザクションは、隣接するキー値が要求された場合、相互にブロックできます。 これは通常、まれな状況であり、RetryOnDeadlockを使用して問題を回避するのに十分ですが、場合によっては、一意でないキーでレコードをプルするときに更新ロックをかける必要があります。

挿入前に利用可能性を確認する

例

追加する前に、データベースにFacebookにそのようなIDを持つユーザーが存在するかどうかを確認する必要があります。 データベース内の1行で作業しているため、それだけがブロックされ、相互ブロックの可能性は小さいという感じがします。 ただし、Serializable（およびこの列がインデックスに含まれる）の分離レベルを持つトランザクションで存在しない値を選択しようとすると、テーブルにある2つの最も近い値の間のすべてのキーに共有ロックが適用されます。 たとえば、データベースにId 15とId 1025があり、それらの間に単一の値がない場合、SELECT * FROM Users WHERE FacebookId = 500が実行されると、共有ロックが15から1025のキーに適用されます。 FacebookId = 600のユーザーが挿入しようとすると、相互ロックが発生します。 データベース内にFacebookIdが満杯の消費者が既に多数いる場合、相互ブロッキングの可能性は低く、RetryOnDeadlockを使用するのに十分です。 ただし、ほとんど空のデータベースでこのようなトランザクションを多数実行すると、パフォーマンスに大きく影響するほど相互ロックが頻繁に発生します。



新しい顧客からの消費者の並行インポートでこの問題が発生しました（クライアントごとに新しい空のデータベースを作成します）。 現在、シングルスレッドのインポート速度に満足しているため、同時実行をオフにしました。 しかし、原則として、上記の例と同様に問題は解決され、更新ロックを使用する必要があります。

 SELECT * FROM Users WITH(UPDLOCK) WHERE FacebookId = 500
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、空のデータベースへのマルチスレッドインポートでは、最初はスレッドがアイドル状態になり、ロックが解除されるまで待機しますが、データベースがいっぱいになると並列度が向上します。 インポートされたデータがFacebookIdによって順序付けられている場合、それらを並行してインポートすることはできませんが。 空のデータベースにインポートする場合、このような順序付けは避けてください（または、最初のインポート中にFacebookIdでデータベース内のユーザーの存在を確認しないでください）。

複雑なユニットの相互連動

システムに複雑な集合体があり、そのデータが複数のテーブルに格納されており、この集合体の異なる部分を並行して変更する多くのトランザクションがある場合、これらのすべてのトランザクションを相互ロックを引き起こさないように配置する必要があります。



例

データベースには、消費者の個人データ、ソーシャルネットワークでの彼の識別子、オンラインストアでの注文、彼に送られた手紙の記録が保存されます。







ソーシャルネットワークに識別子を追加し、手紙を送り、購入を登録するトランザクションは、消費者マスターレコードの技術フィールドを変更することもできます。 これらのトランザクションのいずれにも、コンシューマIDが存在します。



デッドロックを回避するには、次のリクエストでトランザクションを開始する必要があります。

 SELECT * FROM Customers WITH (UPDLOCK) WHERE Id = @Id
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、特定の消費者に関連するデータを変更できるトランザクションは一度に1つだけであり、消費者の集計がどれほど複雑であっても相互ロックは発生しません。

データストレージスキームを変更して、電子メールの送信と購入の登録が消費者のテクニカルノートを変更しないようにすることができます。 その後、注文と送信された手紙に関する情報は、消費者の変化と並行して変更できます。 この場合、実際にはこのデータを「消費者」集計の範囲から取り出します。



要約すると、ユニットを操作するためのヒントは次のように説明できます。

• システム内のトランザクションが複数の集約を変更しないようにする必要があります
• 集約を変更するトランザクションでは、集約データにアクセスする最初のリクエストは、集約ルートに排他ロックまたは更新ロックを課す必要があります
• システムの並列度を上げるには、集計を可能な限り小さくする必要があります

もちろん、これらのヒントはデッドロックの万能薬ではありませんが、人生を大いに促進できます。

連続したレコードの相互ロック

このような相互ブロックは、非常に特定の条件下で発生しますが、数回はまだそれらに遭遇しているので、それらについて話す価値もあります。



例





DirectCRMからメールゲートウェイにレターが送信されると、送信の事実（データベース内の1つのエントリ）について消費者にアクションが発行されます。 アクションIDは通常のIDであり、後続のレコードごとに1ずつ増加します。 メールサーバーへのレターの送信が成功すると、メールゲートウェイはそれについてDirectCRMを報告し、CRMはレターの送信の成功に関するアクションを発行します。これは、送信の事実に関するアクションを参照します（リンクはHierarchicalCustomerActionsテーブルに格納されます）。 電子メールゲートウェイからのメッセージを処理する操作がべき等であるため（ 前の記事でこれを読む必要がある理由）、（シリアル化可能なトランザクションで）正常に送信するアクションが発行されたかどうかを確認します。 このチェックでは、レターの送信の事実に対応して、RootCustomerActionIdによってインデックス内のキーに共有ロックが適用されます。 ただし、送信に関するアクションは最初に送信の事実を参照するものであり、その発行時には、HierarchicalCustomerActionsテーブルにそのようなRootCustomerActionIdを持つ単一のレコードはありません。 したがって、2つの既存のキーの間のすべてのキーに共有ロックが適用されます。 アクションIDはIDであるため、非常に頻繁にチェックされるRootCustomerActionIdは、既にテーブルにあるものよりも大きくなり、テーブル内のRootCustomerActionIdの最大値以上のすべてのキーにロックがかかります。 電子メールゲートウェイでは、メッセージが複数のストリームで送信され、その結果、次の状況が頻繁に発生します。

1. DirectCRMは、Id N、N + 1、N + 2などで送信するという事実に関するアクションを追加します。
2. 電子メールゲートウェイは、これらすべての電子メールを並行して送信します。
3. ディスパッチアクションが発行された時点で、RootCustomerActionIdの最大値はN-1です。
4. N、N + 1、N + 2などの送信に成功したレコードがあるかどうかを確認する場合、N-1以上のRootCustomerActionIdを持つレコードに共有ロックが課せられます。
5. 各トランザクションは、独自の送信レコードを挿入しようとし、他のトランザクションが共有ロックを解放するのを待ちます。
6. その結果、すべての並列トランザクションのうち、1つだけが実行され、残りはポンプで排出されます。

HierarchicalCustomerActionsを照会するときに更新ロックを適用すると、相互ロックはなくなりますが、並列処理も行われません。すべてのトランザクションは、更新ロックを課すトランザクションが終了するまで待機します。

この問題には次の解決策があります。

• ほとんどの場合、新しいIDが2つの既存のIDの間にあるように、IDを拒否してアクションIDを生成します。 そうすると、相互ブロックの可能性は小さくなります。
• 送信の事実に関するアクションを発行する場合、HierarchicalCustomerActionsにもエントリを挿入します（このレコードRootCustomerActionIdはCustomerActionIdと同じです）。 次に、RootCustomerActionId = Nのレコードを要求すると、NおよびN + 1の値に共有ロックが強制されます。これは、そのような値のレコードが既に存在するためです。 Id NおよびId N + 1で送信するという事実に関するアクションを参照して、送信成功時にアクションを挿入する際の相互ブロックを回避するために、HierarchicalCustomerActionsに要求するときに更新ロックを適用する必要があります。 その結果、複数のレコードを並行して挿入すると、次のことが発生します。
  
  
  1. トランザクション1は、RootCustomerActionId = Nのレコードを要求します。同時に、更新はキー値NおよびN + 1をロックします。
  2. トランザクション2は、RootCustomerActionId = N + 1のレコードを要求します。 同時に、彼は値N + 1およびN + 2に更新ロックを課そうとするため、トランザクション1の完了を待ちます。
  3. トランザクション3は、RootCustomerActionId = N + 2のエントリを要求します。 同時に、更新はキーN + 2およびN + 3の値をブロックします。 ここで、トランザクション2はトランザクション3が完了するまで待機する必要があります。
  4. トランザクション1と3は並行して動作します。
  5. トランザクション2は進行中です。