Внешние ключи становятся ненадежными после массовой вставки


11

На сервере редакции 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на каждом), но они все еще становятся ненадежными вскоре после этого. Только работы по обслуживанию выполняются Олой в начале утра, и это происходит в течение дня.

Обновить:

Таким образом, после пары следов, чтобы сузить возможности, кажется, что это BULK INSERTможет стать причиной FKнедоверия. Этот вопрос MSDN утверждает, что это правильный путь для ключа, чтобы стать ненадежным, который является первым, что я услышал об этом.

Итак, мой вопрос сейчас заключается в том, существует ли альтернативная стратегия использования, BULK INSERTкоторая может поддерживать is_trustedстатус внешнего ключа ? Он выполняется в контексте приложения, работающего несколько раз в час. Я мог бы предложить разработчикам пакетировать свои операторы вставки вместо этого, но я бы предпочел не ставить ультиматум на использование, BULK INSERTесли мне не нужно.

Ответы:


10

А BULK INSERTиз нашего приложения была причина ненадежных внешних ключей, что подтверждается вопросом MSDN . Аналогично BCP, каждый раз, когда BULK INSERTвыполняется a, внешний ключ не проверяется во время вставки, поэтому он не является доверенным.

Как упоминал Кин, существуют простые сценарии для поиска и исправления ненадежных внешних ключей, но в моем сценарии вставки происходят с такой частотой, что требует постоянного исправления этой проблемы, которая не стоит.

И ypercube предложил использовать CHECK_CONSTRAINTS опцию в массовых вставках, которая заставит ограничение соблюдаться.

Я планирую обсудить с разработчиками, чтобы убедиться, что каждое использование BULK INSERTоправдано с точки зрения вставленных строк, иначе это должно быть чем-то, с чем нужно жить.


3
Я использовал SqlBulkCopyс тем же эффектом, но есть (по крайней мере, сейчас) опция для массового копирования при проверке ограничений - это означает, что средство массового копирования может выполнять основную проверку, скорее всего, у bcp есть возможность включить который. Кто бы ни сделал режим без проверки по умолчанию, нужно ударить по лицу.
Джон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.