批量插入后外键变得不可信

Question

在 SQL 2014 版服务器（12.0.2430.0 - 还没有 SP1）中，数据库处于 2012 兼容模式（正在努力将其切换到 2014...）我有一些外键对象，它们始终标记为not trusted在数据库中. 我在没有NOCHECK选项的情况下删除并重新创建了它们，但在 5-10 分钟内它们再次变得不受信任，如果我生成一个CREATE脚本，它会显示为：

ALTER TABLE [dbo].[Points]  WITH NOCHECK 
ADD  CONSTRAINT [FK_BadgeId] FOREIGN KEY([BadgeId])
REFERENCES [dbo].[Badge] ([Id])
GO

正在使用的创建脚本是：

ALTER TABLE [dbo].[Points]
ADD  CONSTRAINT [FK_BadgeId] FOREIGN KEY([BadgeId])
REFERENCES [dbo].[Badge] ([Id])
GO

ALTER TABLE [dbo].[Points] CHECK CONSTRAINT [FK_BadgeId]
GO

没有复制，没有第三方工具，我正在监视数据库上的所有 DDL 语句，因此它不是另一个用户。

我能够很好地检查约束（WITH CHECK CHECK在每个约束上使用），但不久之后它们仍然不受信任。只有在凌晨运行的维护作业是 Ola 的，而且这种情况全天都在发生。

更新：

因此，经过几次跟踪以缩小可能性之后，似乎 aBULK INSERT可能会导致FK不可信。这个 msdn 问题指出这是密钥变得不受信任的有效途径，这是我第一次听说它。

所以我现在的问题是，是否有替代策略BULK INSERT可以保持外键is_trusted状态？它是在每小时运行几次的应用程序的上下文中执行的。我可以让开发人员批量处理他们的插入语句，但BULK INSERT如果我不需要，我宁愿不使用最后通牒。

Answer 1

BULK INSERT正如MSDN 问题所证实的那样，来自我们应用程序的A是不可信外键的原因。与 类似BCP，无论何时BULK INSERT执行a，在插入过程中都不会检查外键，从而使其不受信任。

正如 Kin 所提到的，有一些简单的脚本可用于查找和修复不受信任的外键，但在我的场景中，插入发生的频率很高，这使得不断解决这个问题的努力不值得。

并且 ypercube 建议在批量插入中使用CHECK_CONSTRAINTS 选项，这将强制遵守约束。

我计划与开发人员一起审查以确保每次使用 的BULK INSERT插入行都是合理的，否则它将不得不接受。