3

この質問がここで尋ねられたことは知っていますが、1) 比較的古いものであり、2) あまり役に立ちませんでした。

データベースでいくつかの操作を行うと、比較的多数のデッドロックが発生します。セットアップは次のとおりです。

テーブル:

テーブル B への外部キーを持つテーブル A。

オペレーション：

テーブル A に挿入

テーブル B に挿入

テーブル B の行を更新する

テーブル B の行を削除

テーブル A の行を削除する

問題：

これらの操作は基本的に任意の順序で実行できます。複数のワーカー ロールがあるため、これらの操作は冪等でなければなりませんが、各ワーカー ロールはテーブル A の異なる主キーを使用して動作します。テーブルをロックし、私が理解していることから、Aを削除すると、最初にテーブルBがロックされ、そこにある関連する行が削除され、次にAから行が削除されます。現在、これはアトミック操作であり、その間に追加のロックを実行する時間がないと想定していますテーブル B をロックし、テーブル A をロックします。これを回避する方法が想像できないためです。

現在、Microsoft Visual Studio で次の形式の例外をキャッチできます。

トランザクション (プロセス ID xxx) は、別のプロセスとのロック リソースでデッドロックされ、デッドロックの犠牲者として選択されました。トランザクションを再実行します。

この例外は、上記の操作のいずれかで発生する可能性があるようです。

私の質問は次のとおりです。どのロック/トランザクションがデッドロックの原因であるかをどのように知ることができますか? 例外が発生した後に役立つクエリを知っている人はいますか?

4

4 に答える 4

5

sys.event_logがここでの答えです。

これはサーバーの masterdb に存在し、データベースが先月ヒットしたすべてのデッドロック グラフのエントリを含む必要があります。

デッドロック グラフを使用して、SQL Serverデッドロック グラフのデバッグに関する多くのチュートリアルがあります。

于 2013-03-22T02:16:01.270 に答える
0

現在、SQLAzureのプロファイリングツールは実質的に存在しません。

ロックの問題は、標準のSqlServerとSqlAzureの世界でそれほど変わらないはずです。したがって、古き良きプロファイラーなどの標準的な手法を使用して、「古い」世界で問題を再現することをお勧めします。非常に便利な記事です。

そのアプローチが実を結ぶことが証明されない場合、汚い解決策はキャッチ/リトライロジックに取り組むことかもしれません。

于 2013-03-19T16:57:28.187 に答える
0

最近、同様の問題に遭遇しました。"with (UPDLOCK)" でアップデートを使用してみてください。

于 2013-03-19T17:59:54.077 に答える
-1

根本的な原因を見つけようとするには、次のようにします。

  • 単一のワーカー ロールを実行することから始めます。

次に確認します。

  • 適切なレベルのテーブル ロック、ページ ロック、または行ロックでロックしていますか?
  • ロックを解除していますか？
  • あなたのシステムは、同じ行に対するすべての編集が同じマシンによって行われるように設計されていますか?

ここにブロッキング クエリの検索に関するブログ投稿があります: http://blogs.msdn.com/b/sqlazure/archive/2010/08/13/10049896.aspx

于 2013-03-19T15:53:22.090 に答える