正在进行大容量插入时 SSDT 架构比较不起作用

Question

我在一个大型 ETL 和 DW 项目中工作，我们将 TFS/源代码控制与 SSIS 和 SSDT 一起使用。

今天，我发现当 SSIS 包正在对数据库表执行 BULK INSERT 时，不可能对该数据库执行 SSDT 模式比较。这是不幸的，因为我们的一些软件包需要很长时间才能完成。我们想使用 Schema Compare 功能来检测数据库结构的更改，以便将它们保存在我们的 SSDT 项目中，以便对数据库进行版本控制。

深入研究一下，我发现 SSDT 中的 Schema Compare 函数执行一个 SQL 脚本，该脚本调用OBJECTPROPERTY()数据库中表的系统函数。特别是在我的情况下，OBJECTPROPERTY(<object_id>, N'IsEncrypted')当<object_id>引用当前正在批量插入的表时，任何调用似乎都被阻止了。

在 Visual Studio 中，SSDT 架构比较只是在一段时间后超时，并声称未检测到任何差异。

SSDT 中是否有解决此问题的方法，或者我应该尝试提交 MS Connect 错误报告？

或者，由于 BULK INSERT 发生在 SSIS 包中，是否有某种方法可以在不锁定OBJECTPROPERTY表上的调用的情况下进行此插入？编辑：在 SSIS OLE DB 目标中，我们可以从“锁定表”中删除复选标记，它按照它所说的做，但这在某些情况下可能会损害性能。我对允许 SSDT 架构比较完成其工作的解决方案更感兴趣，即使某些对象被锁定。

Answer 1

该OBJECTPROPERTY调用需要模式稳定性 (Sch-S) 锁，该锁仅与模式修改 (Sch-M) 锁不兼容。

在BULK INSERT将在某些情况下，SCH-M锁。这些列在《在线书籍优化批量导入指南》的“批量导入期间的表锁定和日志记录”部分：

如果目标表是集群的，您可能会发现启用跟踪标志 610会有所帮助。如果您决定走这条路线，请阅读这些帖子的整个系列和数据加载性能指南并彻底测试。

我不知道为什么 SSDT 检查IsEncrypted表的属性。我无法想象这是有道理的场景，但这是 SSDT 人员的问题。