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
の使用に最終通告を入れたくないです。
MSDNの質問 で確認されたように、アプリケーションからのBULK INSERT
が信頼できない外部キーの原因でした。 BCP
と同様に、BULK INSERT
が実行されるときはいつでも、挿入時に外部キーはチェックされないため、信頼されません。
Kinが述べたように、信頼できない外部キーを見つけて修正するための 単純なスクリプト がありますが、私のシナリオでは、挿入が頻繁に発生しており、この問題を常に修正しようと努力していますが、価値はありません。
Ypercubeは、一括挿入内でCHECK_CONSTRAINTS
option を使用することを提案しました。これにより、制約に従うことが強制されます。
挿入された行に関してBULK INSERT
の各使用が正当化されることを確認するために、開発者と検討する予定です。それ以外の場合は、それに対応する必要があります。