なぜ復元でデータベースが止まってしまうのか？
復元作業中のデータベースは「復元しています…」となり、基本的に接続できない
この復元しています…はNORECOVERY状態という
一応、STANDBY状態という取得のみ許可できる状態もある
「復元完了。みんな触っていいよ」という状態はRECOVERY状態という
設定により、以下の1. 復元先と2. 復元元が止まるパターンに陥ってしまう
なぜ混乱するのか？
自分が使う状況で復元の前にログ末尾のバックアップを実行するにデフォルトでチェック入っているのが混乱の原因な気がしてきた
「復元元productionのバックアップファイル」を使って「復元先production_test」を復元しよう
SQL ServerのリストアのパターンのCに該当
この作業から、どうして復元元が復元しています…になるのが想像できなかった
なぜなら原因は復元元の最新のログ末尾のバックアップをとることによる、復元元の復旧状態の変化だったから
1. 復元先が止まるパターン
復元先は、データベースの復元で復旧状態をRESTORE WITH NORECOVERYとすることで止まる
この項目は意図的に「復元中ですよ」とするので意味はわかる
1. 完全バックアップだけ復元する(まだ復元するファイルが残っているのでNORECOVERY)
2. 差分バックアップだけ復元する(同じくNORECOVERY)
3. トランザクションログバックアップその1を復元する(同じくNORECOVERY)
4. …略
5. トランザクションログバックアップ最新を復元する(ここでRECOVERYに設定する)
これをまとめて一度に行ってもリストア履歴では内部で同じことをやっていることがわかる
リストア履歴をシステムデータベースから確認するSQL
2. 復元元が止まるパターン
復元元は、データベースの復元で復元の前にログ末尾のバックアップを実行するをチェックするとこの状態になってしまう
デフォルトでチェックが入っている
間違えて復元状態にしちゃいました…となる…
ここがよくわからん
復元元productionのバックアップファイルを使ってproduction_testに一週間前のproductionを復元したい場合
ログ末尾のバックアップって必要？
ログ末尾のバックアップが必要な状況とは？
結局、自分の想定する状況だと必要ないということがわかった
チェック見逃して止まったらびっくりする
ログ末尾のバックアップは、トランザクションログバックアップもとられていない最新のデータまでぴったり一致させたいときくらいしか使わなさそうに思える