データベースを復元する前に、作業中のシステムをシャットダウンする必要があります。これを行わないと、アプリケーションサーバーのメモリ内の状態がデータベースと一致しないため、深刻な問題が発生する可能性があります。破損したデータベースがエラーを引き起こし、システムが動作を停止してデータベースが使用できなくなるまで、しばらく時間がかかる場合があります。
だから私はこの状況を検出して問題を回避しようとします。
- アプリケーションサーバーは必ずしも接続を維持しているわけではないので、シングルユーザーモードやこのようなものはおそらく役に立たないでしょう。
- 復元が失敗したり、サーバーがシャットダウンしたりするかどうかは関係ありません。それを無視するべきではありません。
- データベースは、任意のマシン上の任意のSQLサーバーツールによって復元できます。自分のツールに頼ることはできません。
誰かがすでにそのような問題を解決しましたか？
SQL Server 2005以降、.NET（C＃）、SMOを使用しています。
編集：
アプリケーションの設計に関する誤解や議論があるため、問題の原因を説明する必要があります。
Hi-Loジェネレーター：アプリケーションは、Hi-LoidジェネレーターのHi-Valueのキャッシュを持つNHibernateを使用します。Hi-Valueはデータベースから読み取られ、データベースに戻って別の範囲の数値を取得する必要があるまで、アプリケーションが特定の数の主キーを生成できるようにします。データベースに格納されているHi-Valueはインクリメントされるだけで、デクリメントされることはありません（データベースの古いバージョンが復元された場合を除く）。これはHi-Loジェネレーターの概念であり、私自身が発明したものでも実装したものでもありません。
キャッシュ：キャッシュでは、データベース内のレコードを識別するために主キーが使用されます。データベースの通常の使用では、主キーは変更されません。復元の場合、主キーは同じレコードを識別しなくなり、キャッシュはまったく間違っています。これも検出できません。たとえば、新しいレコードに間違った外部キーを設定する可能性があります。
DB復元は、データベースの他の通常の使用法と比較することはできません。復元は、データ処理のすべてのルールに違反します。
多くのアプリケーションは、実行中は接続を開いたままにして、復元を不可能にしていると思います。他のほとんどのアプリケーションは、データベースが復元されたときにクラッシュし、その後データベースにアクセスしようとします。私の場合、しばらく動作し続けることがありますが、これは問題です。
ほとんどの人は、アプリケーションの実行中にデータベースを復元しようとさえしないと思います。
アプリケーションがまだメモリ内にある間にデータベースが復元されると、理論上、私の場合は証明されたリスクがあります。ほとんどのアプリケーションがそれを処理しないという理由だけで、これはまったく問題ではないと言われたくありません。