3

私はキューシステムとして使用するデータベーステーブルを持っています。ここでは、互いに通信する個別のプロセスがテーブルのエントリを作成および読み取ります。たとえば、ユーザーが検索を開始するとエントリが作成され、1 ～ 2 秒ごとに実行される別のプロセスがその新しいエントリを取得し、ステータスを更新してから検索を実行し、検索が完了すると再びエントリを更新します。これはすべて、1 時間あたり数千回の検索でうまくいくようです。

ただし、これらすべての「ジョブ」のステータスを表示できるマスター管理画面がありますが、実行が非常に遅くなります。私は基本的に、過去 1 時間のテーブル内のすべてのエントリを返すので、何が起こっているのかを監視できます。ある種のロックの問題が発生していると思います。各エントリを読む必要があるだけで、データが少し古くなっているかどうかはあまり気にしません。標準の 'Select * from Table' ステートメントを使用するだけなので、ジョブが常にデータを更新しているため、データを返す前に他のロックが期限切れになるのを待っている可能性があります。

これは、特定の種類のカーソルによって、各行を一度に 1 つずつ返すなどにより適切に処理されますか? 他のアイデアはありますか？

ありがとう

4

3 に答える 3

2

FROM yourtable WITH (NOLOCK)テーブルのヒントが必要です。

まだ行っていない場合は、更新プロセスでトランザクションの分離を確認することもできます。

于 2012-07-16T21:26:24.360 に答える
2

データが少し古くなっているかどうか本当に気にしない場合...またはデータが 99.99% 正確であることだけが必要な場合は、次の使用を検討してWITH (NOLOCK)ください。

SELECT * FROM Table WITH (NOLOCK);

READ UNCOMMITTED ISOLATION LEVELこれにより、次の動作を持つを使用するようクエリに指示されます。

ダーティ リードを許可することを指定します。他のトランザクションが現在のトランザクションによって読み取られたデータを変更するのを防ぐ共有ロックは発行されません。また、他のトランザクションによって設定された排他ロックは、現在のトランザクションがロックされたデータを読み取ることをブロックしません。

NOLOCKによってデータが不正確になる可能性があることに注意してください。そのため、システムの残りの部分で使用することはお勧めできません。

于 2012-07-16T21:27:18.703 に答える
1

NOLOCK(行の欠落や行の重複などの非常に悪い事態につながる可能性があります) の代わりに、データベース レベルで読み取りコミット スナップショット分離を許可し、次のようにクエリを発行します。

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
于 2012-07-16T21:31:41.320 に答える