3

実行するジョブを含む SQL Server (2008 R2) にキューを実装しています。完了すると、ジョブは履歴テーブルに移動され、フラグが成功または失敗に設定されます。キュー テーブル内のアイテムには、主キーとして ID 列があります。履歴キューには、この ID とタイム スタンプの組み合わせが PK として含まれています。

ジョブが失敗した場合、それを再実行するオプションが欲しいのですが、これは、履歴テーブルから元に戻し、ライブ キューに戻すことだと考えられています。トレーサビリティの目的で、再挿入された行に元のエントリと同じ ID を持たせたいのですが、これは ID 列であるため問題が発生します。

考えられる解決策は 2 つあります。

1) IDENTITY_INSERT を使用します。

SET IDENTITY_INSERT TableName ON

-- Move from history to live queue

SET IDENTITY_INSERT TableName OFF

2) ライブ キューと履歴キューの両方から最大 ID 値を取得して追加するなど、一意の ID を生成するカスタム ロジックを作成します。

2 が面倒で、おそらくパフォーマンスが悪く、神経症の皮膚が這うようになることを除けば、2 には実際の問題は見られません...

オプション 1 は気に入っていますが、その意味が十分にわかりません。これはどのように機能しますか？そして、これを 2 つのテーブルに対して同時に行うと、物事がクラッシュしたり燃えたりすることを私は知っています。2 つのスレッドが同じテーブルに対して同時にこれを行うとどうなりますか?

これは、半一般的に使用されるストアド プロシージャに対してこれを行う良い方法ですか、それとも、ブルー ムーンで 1 回だけデータをバッチ挿入するためにこの手法を使用する必要がありますか?

どちらが最良の選択肢であるか、またはより良い方法があるかについて何か考えはありますか?

4

4 に答える 4

1

オプション1を使用します-使用しますIDENTITY_INSERT

SET IDENTITY_INSERT TableName ON

-- Move from history to live queue

SET IDENTITY_INSERT TableName OFF

IDENTITY_INSERT現在の接続に適用される設定であるため、別の接続が同様のことを行っていても、影響はありません。ONそれを使用してエラーが発生する唯一の場所は、最初のテーブルで最初に有効にせずに別のテーブルに設定しようとした場合ですOFF。

于 2011-05-18T06:57:25.447 に答える
0

ID 値を再利用するときにパフォーマンスの問題が発生する可能性があります。これは、ID 列がクラスター化インデックスによってインデックス付けされている場合です。

厳密に増加する数を指定すると、挿入された行は常にクラスター化インデックスの最後に追加され、ページ分割は発生しません。

再利用された数字を挿入し始めると、それらの挿入中にページ分割が発生する可能性があります。それが問題である場合は、ドメイン次第です。

于 2011-05-18T11:29:33.413 に答える
0

元の (ライブ) ID 値を使用して履歴テーブルに挿入することはできませんか? とにかくタイムスタンプと組み合わせると言います。

于 2011-05-18T06:46:04.187 に答える
0

キューの ID 列が「ジョブ ID」を割り当てる列であると仮定すると、最も簡単な解決策は、FK が履歴テーブルを指している可能性がある新しい「OriginalJobID」null 許容列を追加することだと思います。次に、ジョブを再実行するときに、ジョブがキューに追加されるときに新しい ID を取得できるようにしますが、この新しい列で元のジョブへの参照を保持します。

「または、この手法は、ブルームーンで一度だけデータをバッチ挿入するために使用する必要があります」と答えるには、間違いなく、まさにそれが目的です。

おっと、@ Damien_The_Unbeliever は正しいIDENTITY_INSERTです。設定が接続ごとであることを忘れていました。ID挿入アプローチで実際の問題に陥るのは複雑です（MARSのようなものか、エラー処理が悪いと思います）。とはいえ、ID を再利用しようとするのは間違いだと思います。

于 2011-05-18T06:51:55.517 に答える