新しくアタッチされた Dev インスタンスが、以前の Dev データベースに加えられたが、名前が変更されて Dev としてアタッチされる前に Live DB レプリカに存在しなかったスキーマの変更を "ピックアップ" するという問題が発生しました。
Dev DB はログ配布スタンバイとして開始され、完全に復元され、デタッチされ、ファイルの名前が変更されてから、新しい Dev DB として再アタッチされます。以前の Dev データベースは、デタッチされただけで削除されていないことに注意してください。また、古い Dev DB と新しい Dev DB はどちらも同じ元のデータベースの "フォーク" であることに注意してください。
これは開発/テスト環境なので特に問題はありませんが、静かに変更された Dev に対して、適用すると Live が壊れる何かを作成するのではないかと心配になります。
したがって、私の作業理論では、これは SQL Server の内部で使用される一意の識別子と、おそらく Dev への変更のタイミングに関連しているというものです。
誰でもこれを確認したり、問題に光を当てたりできますか?
編集: 詳細 スキーマの変更には、いくつかのテーブルの最後に新しい null 許容列を追加することが含まれていました。したがって、それらは明らかにマイナーであり、重要なことに、実際のデータは含まれていません。また、ログ配布コピーは、再接続されるまでスタンバイ状態でした (読み取り専用)。クエリ ログを確認して、DDL の変更が実行されていないことを確認しました。
とはいえ、残念ながら問題を再現することはできません。テスト用に作成された小さな DB では発生しません。Dev DB を削除し、問題を解決するために完全バックアップから再作成したため、正確なプロセスを繰り返すことはできません。
この質問をする私の目標は、私たちが例外的なまぐれを経験したのか、それとも私たちのプロセスが根本的に健全でないのかを確認することです. 現時点では、例外的なまぐれに傾いています。