tableA からデータを読み取り、tableB にデータを挿入するパッケージがあります。このパッケージは複数回 (通常は 3 ～ 5 回) 並行して実行できますが、同じデータを読み取ることはありません。両方のテーブルにフラグ customerID があり、パッケージを実行するたびに特定の customerID からデータが読み取られるとします。
宛先で TABLELOCK を使用しないと、読み込みがはるかに高速になることに気付きました。これは、パッケージを実行するたびに tableB に同時にデータが挿入され、ページ レベルで何らかのロックが発生していても、テーブル全体がロックされていないためだと思います。
だから私の質問は、宛先でTABLELOCKを使用しないことに問題はありますか?
PS: 私は高速読み込みを使用しており、customerId はテーブル B のクラスター化インデックスです。
並列実行が一意の顧客 ID を呼び出している限り、いいえ、パフォーマンスに関してもデッドロックに関しても実際の問題はありません。
少なくとも知っておくべき問題は 2 つだけです。
1) 並列タスクがデータを挿入する順序と、その後の tableB の読み取り。tableB からの読み取りのリアルタイム性に応じて、TABLOCK は確実に役立ちます (ただし、保証はできません。ある顧客が 10,000 行を持っていて、別の顧客が 1 行しか持っていない場合、2 番目の顧客はデータ フロー タスク処理で最初の顧客を「飛び越える」可能性があります)。並列実行は、実行された順序で処理されます。そのため、データが利用できると思ったときに正確に利用できないというシナリオに陥る可能性があるため、順序が重要な場合 (そうではないか、並行して実行すべきではないと思います)、少なくともこれに注意してください。
2) 挿入が十分に大きい場合、TABLOCK を有効にしなくても、ROWLOCK から TABLOCK に自動的にジャンプする可能性があるため、一部のジョブで遅延や時差のある終了が発生する可能性があります。