6

私はワークフローのようなシステムに取り組んでいます。1 つのタスク テーブルとステータス フィールドがあります。status の値は、New、ready、processing、error、abort、done のいずれかです。

タスクステータスの値を変更するために、さまざまな状況に基づいてトリガーされる約7つのプロセスがあります。ほとんどの場合、各プロセスは独自のデータ セットで動作し、毎回最大 5000 レコードしか処理しません。しかし、データが約 200 万レコードに達すると、まだデッドロックが発生します。SQL プロファイラで確認すると、関連するページ リソースのように見えます。私はSQLサーバーのパフォーマンスチューニングが苦手で、よく理解していません。

非アクティブなタスクは毎日アーカイブされるため、1,000 万件程度のレコードをサポートするようにテーブルを再設計することを考えています。

いくつかの選択肢があります:

  1. ステータスに基づいて分割テーブルを作成します。
  2. ステータスに基づいて静的データとサポートされているテーブルを含むマスター テーブルを作成する

この種の状況に適した方法はありますか?

ありがとう！

4

2 に答える 2

0

私は答えを投稿する必要があることを知っていますが、これらの質問で答えは続くかもしれません：

1.）テーブルのヒントはありますか？そうでない場合は、それらを適用して実験してください

2.）使用可能なすべてのインデックスが使用されていますか？また、TaskId列は唯一の受け入れ可能なインデックスですか？分析すると、特定の状況で新しいインデックスが必要になる場合があります

3.）200万件のレコードすべてが常にライブ/アクティブですか？

4.）断片化されたインデックスをチェックしましたか？毎日のアーカイブはインデックスの断片化を引き起こす可能性があるため、アーカイブジョブの最後に、断片化をチェックして修正する手順を追加することをお勧めします。

5.）、、、、、のステータスフィールドは、newどのデータタイプの下にありますか？readyprocessingerrorabortdone

6.）インデックス付きビューで実験しましたか？特定のデータを制限していることをすでに知っていて、テーブルスキャンを避けたい場合は、それが役立つ可能性があります

于 2011-11-19T21:10:52.173 に答える
0
  • ステータス列に基づいてテーブルを分割できます。1 つのパーティション内のアクティブなレコード。別のパーティションのクローズされたレコード
  • 月単位で、クローズされたレコードをクリアする (不要になった場合は削除する) か、アーカイブ テーブルに移動することもできます。
  • 分割テーブル より良い選択だとは思いません (同じ機能のために複数のテーブルは必要ありません)
  • デッドロックを回避するには、使用している SQL Server のバージョン
  • SQL 2005 以降を使用している場合 Read Committed Snapshot Isolation を使用して、コミットされたデータを読み取ります。これにより、読み取りが書き込みをブロックしないことが保証されます
于 2011-10-19T01:00:25.577 に答える