0

ASP.NET 4.0 (C#) を使用して構築された Web アプリケーションがあり、バックエンドとして SQL Server 2005 を使用しています。

アプリケーション自体はワークフロー エンジンであり、各レコードは 1 か月に 18 日間にわたって 4 人のロール ベアラーによって証明されます。

毎月 1 日に約 20 万件のレコードがあります。

18日間 - システム管理者がこれらのレコードの所有権を変更している可能性がある一方で、何人かの人々がレコードを見て証明しています。

私の質問または心配は、データベースでデッドロックの問題が頻繁に発生することです。

一部のユーザーは自分のキティに 10000 レコードを持っていて、すべてのレコードを一度に証明しようとする場合がありますが、システム管理者は数千レコードの所有権を一括で変更することもあり、その時点でデッドロックが発生し、2 人以上のユーザーが大量のアカウントを持っている場合でも同様です。証明しようとすると、デッドロックが発生します。

トランザクションでストアド プロシージャを広く使用しています。そのような状況をコーディングする方法はありますか?

または単にデッドロックを回避します。

このようにでたらめな方法で質問して申し訳ありませんが、ヒントやヒントは大歓迎です。問題を理解するためにさらに情報が必要な場合はお知らせください。

ありがとう

4

1 に答える 1

0

いくつかの提案:

1) テーブルからのデータの読み取り/テーブルへのデータの書き込みに同じ順序を使用します。

例 #1 (読み書きデッドロック): A から読み取ってから B に書き込むusp_ReadA_WriteBストアド プロシージャと、B から読み取ってから A に書き込む別のストアド プロシージャを作成することは避けてください。usp_ReadB_WriteAこのブログ投稿を読んでください。

例 #2 (書き込み-書き込みデッドロック):テーブル A にデータを書き込み、次にテーブル B にデータを書き込むストアド プロシージャと、同じテーブル (テーブル B に続いてテーブル A) にデータを書き込むusp_WriteA_WriteB別のストアド プロシージャを作成しないようにします。usp_WriteB_writeA

2) トランザクションの期間を最小限に抑えます。影響を受ける行を最小化して、ロックの数を減らします。ロック エスカレーションの 5000 ロックのしきい値に注意してください。

3) クエリを最適化します。例:実行計画で[Clustered]{Index|Table}Scan, {Key|RID} Lookupand 演算子を探します。Sortインデックスを使用しますが、インデックスの数を最小限に抑え、すべてのインデックスのサイズを最小限に抑えます (最初にインデックス キーのサイズを最小限に抑えます)。このブログ投稿をお読みください。

于 2013-07-31T20:50:56.987 に答える