web-dev-qa-db-ja.com

一括挿入後に外部キーが信頼できなくなる

2012互換モードのデータベースを備えたSQL 2014エディションサーバー（12.0.2430.0-SP1はまだありません）で（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のものであり、これは1日中行われます。

更新：

したがって、可能性を絞り込むためにいくつかのトレースを行った後、BULK INSERTがFKを信頼できないものにする可能性があるようです。 このmsdnの質問 は、これがキーが信頼されなくなるための有効なルートであることを示しています。これは私が聞いた最初のルートです。

だから私の質問は、外部キーのBULK INSERTステータスを維持できるis_trustedを使用する代わりの戦略はありますか？ 1時間に数回実行されるアプリケーションのコンテキストで実行されています。開発者に代わりに挿入ステートメントをバッチ処理させることもできますが、必要がない場合は、BULK INSERTの使用に最終通告を入れたくないです。

sql-serverforeign-keysql-server-2014bulk-insert
10
LowlyDBA

MSDNの質問 で確認されたように、アプリケーションからのBULK INSERTが信頼できない外部キーの原因でした。 BCPと同様に、BULK INSERTが実行されるときはいつでも、挿入時に外部キーはチェックされないため、信頼されません。

Kinが述べたように、信頼できない外部キーを見つけて修正するための 単純なスクリプト がありますが、私のシナリオでは、挿入が頻繁に発生しており、この問題を常に修正しようと努力していますが、価値はありません。

Ypercubeは、一括挿入内でCHECK_CONSTRAINTSoption を使用することを提案しました。これにより、制約に従うことが強制されます。

挿入された行に関してBULK INSERTの各使用が正当化されることを確認するために、開発者と検討する予定です。それ以外の場合は、それに対応する必要があります。

9
LowlyDBA