パッケージに「同じ接続を保持する」プロパティを設定していない限り、これは私の好みではありませんが、経験していることはドキュメントに記載されていることです。
Using SET QUERY_GOVERNOR_COST_LIMIT applies to the current connection only
and lasts the duration of the current connection
パッケージ内で、SQL 実行タスクの接続が開かれ、クエリ ガバナー ステートメントが発行され、そのタスクが終了します。次に、OLE DB ソース (または ADO.NET ソース) の一部として、データ フロー タスクで新しい/異なる接続が使用されます。その接続はガバナーのコストを変更していないため、QG の対象となります。
これを解決するには、データ フローでソースを変更する必要があります。必要なテーブルを選択したと仮定すると、ラジオ ボタンを [テーブル ソース] から [クエリ ソース] (おおよその名前) に切り替える必要があります。このクエリのソースとして、次のようなものを使用します
SET QUERY_GOVERNOR_COST_LIMIT 0;
SELECT
MT.*
FROM
dbo.MyTable AS MT;
編集
QG 制限を超えているのはターゲット テーブルであることを考えると、Destination の Connection Manager を変更して RetainSameConnection プロパティを True に設定するのが手っ取り早い方法です。これにより、宛先変換の同じ接続のコストが既に変更されていることが保証されます。この質問に対する私の回答で、それを設定した場所のスクリーンショットがあります
SSIS: デフォルトの Logging OnError が RetainSameConnection で機能しない
うまくいく可能性のある他のアプローチは、データの負荷を変更してクエリ (挿入) のコストを削減することです。
- コミット サイズやバッチ サイズを減らすことで、そこに到達できる場合があります。
- ターゲット テーブルに大量のインデックスが作成されている場合、すべてのインデックスを維持するコストがクエリ ガバナーのしきい値を超える可能性があるため、パッケージの実行前後に非クラスター化インデックスを削除して再作成すると、挿入コストが削減される可能性があります。また、NCI を再作成すると作業に時間がかかる可能性があるため、缶 (コスト) が後回しになる可能性があります。
- Enterprise Edition を使用していてパーティショニングを使用している場合は、空のパーティションにロードしてスワップインできる可能性があります。この状況ではそうではなく、パーティショニングがうまく行われなければ問題が悪化する可能性があるためです。