0

次のシナリオがあります。

  • 複数のプログラムがアクセス (更新、削除、挿入、および選択) するテーブル。実際、それらは同じですが、複数のユーザーによってインスタンス化されています。プログラムは使用後にデータを削除し、新しいデータを再度挿入するため、このテーブルが 1000 行を超えることはありません。これは、サプライヤー/コレクターの状況のようなものです。

  • これは工業生産のシナリオであり、いくつかの操作を保証する必要があるため、ユーザーがアクションを確認すると、プログラムはシステム上の他のテーブルからのデータでそのテーブルを更新します。

そのため、多くのコマンドにトランザクションを実装しました。その結果、多くのデッドロックが発生しました。

これらのロックを回避するために何ができるかについてのヒントが欲しい. 実際、トランザクションは必要ありません。コマンドが実行されることを保証するだけでよく、何らかの理由で失敗した場合、操作全体がロールバックされます。トランザクションを使用せずにそれを行う方法があるかどうかはわかりません。

PS: SQL Server 2008 R2 を使用しています。

PS2: 更新の FROM 句で使用したいくつかのシステム テーブルが大きな問題であることがわかりました。これらのテーブルはシステム全体で使用され、大量の挿入/更新/選択を取得します。したがって、このプログラムでそのテーブルのデータを変更しなかったため、ロックしてはならないものをロックしていました。

元：

   Update t1
   set x= 1
   from systable1 as t
   inner join systable2 t2
   where .....

これが大きな問題だったのでWITH (NOLOCK)、t と t2 とWITH (ROWLOCK)t1 にヒントを追加しました。

私が言及しなければならないもう1つのことは、これはテスト環境であり、本番環境で失敗するリスクを冒すことはできないため、データベースとプログラムに最大のストレスをかけています.

チェックポイント戦略を使用して、アクションが失敗した場合にアクションをやり直すことはできますか?

ありがとう。

4

4 に答える 4

0

readuncommittedを使用することは、ノックオン効果がありますが、可能な解決策です。私は最初にローロックを試してみます。SQL Serverは、ページロックに最適化して、レコードのロック数を減らします。レコードの幅が非常に広い場合を除いて、レコードは1,000個しかないため、ページロックによってロックされるレコードはかなり少なくなります。

于 2012-04-26T23:22:49.260 に答える
0

トランザクション内のすべてのクエリのパフォーマンス チューニングから始めます。インデックスを追加してトランザクション内のクエリを高速化すると、表示されるデッドロックの量に大きな違いが生じることがあります。

また、何かが失敗したときに必要なロールバックを実現するために、トランザクションをできるだけ小さくしてください。たとえば、データを検索するクエリが 5 つあり、データを変更するクエリが 3 つしかない場合、データを変更する 3 つのクエリだけにトランザクションを縮小できる可能性があります。

お役に立てれば。

于 2012-04-26T23:24:40.750 に答える
0

READ UNCOMMITTED を使用すると、ロックの問題を解消できる場合があります (「READ UNCOMMITTED 分離レベルを使用する理由」およびhttp://msdn.microsoft.com/en-us/library/aa259216(v=sql.80).aspxを参照) 。 . ただし、これにより、一貫性のないデータが読み取られたり、必ずしもデータベースに保持されるとは限らないことに注意してください。

于 2012-04-26T23:12:18.613 に答える
0

First, yes you need transactions to ensure success or failure (rollback). Only a 1,000 records? That table must be getting slammed with inserts/updates/deletes! So to me this sounds like a heavy transaction table - so be careful with adding indexes as they will only make your inserts/updates/deletes slower. And I have to confirm there are no triggers on your heavy transaction table, right?

So what about your reads? Ever think about separating out a reporting table or something? Replication might be overkill. How accurate and up-to-the-minute does the data need to be?

Finally - profile, profile, profile.

于 2012-04-27T00:40:01.137 に答える