不完全リカバリまたはバックアップ制御ファイルを使用したリカバリの後は、ログをリセットする必要があります。
ユーザー管理のデータベースのフラッシュバックおよびリカバリの実行
現行のすべての制御ファイルのコピーが消失したか、または破損した場合は、バックアップ制御ファイルをリストアおよびマウントする必要があります。リストアされたデータファイルがない場合でも、RECOVERコマンドを実行し、RESETLOGSオプションを指定してデータベースをオープンする必要があります。ただし、現行の制御ファイルのいくつかのコピーを使用できる場合は、「現行の制御ファイルのサブセットが消失した場合の対応」の手順を実行し、リカバリおよびRESETLOGSの実行を回避できます。
Recovery Managerのリカバリの実行: 高度な例
REDOログは変更履歴なので、不完全リカバリ、つまり過去のある時点まで戻す場合、それ以降の変更履歴は不要。従って、RESETLOGS しないとオープンできないというのは納得できる。
バックアップ制御ファイルを使用したリカバリの場合に RESETLOGS が必要なのはなぜだろうか？時間があるときに調べてみよう。
[参考]
Controlfile Recovery Requires RESETLOGS | Ardent Performance Computing
Controlfile Recovery Requires RESETLOGS - oracle-l - FreeLists
追記(2009/05/01):
現行のすべての制御ファイルを失った場合、論理バックアップ(backup controlfile to trace)から制御ファイルを再作成すれば、noresetlogsで復旧できる。バックアップ制御ファイルを使用した場合、resetlogsが必要。resetlogsによって、ファイル情報の整合性合わせ、ログ番号のリセットなどを行うらしい。
追記(2009/07/13):
- コールドバックアップから完全リカバリする場合、制御ファイルのSCNまでREDOを使ってロールフォーワードして、UNDOを使ってロールバックする。
- 論理バックアップ(backup controlfile to trace)から制御ファイルを再作成する場合、再作成したときにREDOログのSCNを読んで制御ファイルにSCNを入れる。
- 物理バックアップ(バックアップ制御ファイル)をリストアする場合、SCNが空になっていて、Oracle は resetlogs を要求するように作っている。
んじゃないかと妄想した。
