SSDTスキーマ比較は、BULK INSERTの進行中は機能しません

私は、SFSとSSDTの両方と一緒にTFS /ソース管理を使用する大規模なETLおよびDWプロジェクトで働いています。

今日、SSISパッケージがデータベーステーブルへの一括挿入を実行している間、そのデータベースに対してSSDTスキーマ比較を実行できないことがわかりました。一部のパッケージの完了には非常に長い時間がかかるため、これは残念です。データベースのバージョン管理のためにSSDTプロジェクトに保存するために、スキーマ比較機能を使用してデータベース構造への変更を検出します。

これについてもう少し詳しく見てみると、SSDTのスキーマ比較関数OBJECTPROPERTY()が、データベースのテーブルでシステム関数を呼び出すSQLスクリプトを実行していることがわかりました。特に私の場合、が現在一括挿入されているテーブルを参照する場合、への呼び出しはすべてOBJECTPROPERTY(<object_id>, N'IsEncrypted')ブロックされているよう<object_id>です。

Visual Studioでは、SSDTスキーマ比較はしばらくするとタイムアウトし、違いが検出されなかったと主張します。

SSDTでこの問題の回避策はありますか、それともMS Connectバグレポートを提出する必要がありますか？

または、BULK INSERTはSSISパッケージからOBJECTPROPERTY行われるので、テーブルの呼び出しをロックせずにこの挿入を行う方法はありますか？編集： SSIS OLE DB宛先では、「テーブルのロック」からチェックマークを削除できます。チェックマークはそれを実行しますが、状況によってはパフォーマンスが低下する可能性があります。一部のオブジェクトがロックされている場合でも、SSDTスキーマ比較でその機能を実行できるようにするソリューションの方がはるかに興味があります。

OBJECTPROPERTYコールは、スキーマ安定性のみである（SCH-S）ロック、必要と互換性のないスキーマ変更（SCH-M）ロックとを。

BULK INSERTいくつかの状況でSCH-Mロックがかかります。これらは、Books Onlineの一括インポートを最適化するためのガイドラインの「一括インポート時のテーブルロックとログ」セクションにリストされています。

宛先テーブルがクラスター化されている場合、トレースフラグ610を有効にすると役立つ場合があります。これらの一連の投稿全体とデータ読み込みパフォーマンスガイドを読んで、この方法を選択する場合は十分にテストしてください。

SSDT IsEncryptedがテーブルのプロパティをチェックする理由がわかりません。それが理にかなっているシナリオを想像することはできませんが、それはSSDTの人々にとっての問題です。