主キーとしてIdentity列を持つテーブルがあります。
数日前まではすべて順調で、このテーブルを使用しているアプリケーションはPK違反について不平を言い始めます。DBCC CHECKIDENTについて思い出すまで、最初はこれは不可能だと思いました。魔法の関数は、「現在の列の値」が「現在のIDの値」よりも高いことを教えてくれました。私は最高の価値に再シードしました、そしてすべては再びうまく見えました。
私の質問は、これが将来再び発生するのを防ぐために、この非同期の問題の考えられる原因は何ですか？そしてそれを防ぐ方法は？
IDENTITY_INSERTがオンになっているインスタンスを見つけるためにコードを検索する必要があるようです。次に、（おそらく番号の大きいident列）キーが挿入されます。挿入された（そして任意の）PK値がシード値内にあるという点で、アプリケーションはおそらく過去に幸運に恵まれました-おそらく削除などが原因です。
スケジュールされたメンテナンスを行っており、オフピーク時にシングルユーザーモードになっている場合を除き、実稼働環境ではID挿入をオンにしないでください。これは、レコードがオンになっているときにレコードを挿入しようとするすべての人に影響し（IDが指定されていないため、通常の挿入プロセスではエラーになります）、それを使用することは非常に悪い習慣です。本番環境でこれを使用する開発者またはプロセスがある場合は、すぐにプロセスを再考する必要があります。
開発者は本番権限を持ってはいけません。dbaでは何に影響するかを考えずにID挿入をオンにすることはできないため、その手順だけで問題の将来の再発を防ぐことができます。Joshに同意します。実行されているETLインポートを確認します。特に、問題が発生した頃に実行されたETLインポートを探します。
開発者がID値を変更したり、ID挿入をオンにしたりする場合は、これが非常に悪い方法である理由を開発者に教育する必要があります。ID値は、関連するすべてのテーブルにも影響するため、挿入後に変更しないでください。