SET NEWNAME works for RESTORE and SWITCH, but not for RECOVER. Datafiles had been renamed and switched before the recovery started.
There is a flaw in your process though, and the above issue is its side effect:
Restore the control file from the 3/9 backup.
Why? You do a nearly complete recovery to get as close as possible to the current state, not the state on 3/9. Restore the controlfile from the latest backup taken on 3/14.
Since the restored control files aren't aware of the backup pieces for 3/10 - 3/14, I run this for each
This step is unnecessary if you use the latest controlfile.
This is absolutely normal when you try to perform a complete recovery from a hot backup, because that is how hot backups work, you will never have the latest changes in your backups.
Your backup includes archivelogs up to sequence 29. The next changes were in log sequence 30, but log sequence 30 became the current redo log at the time your backup was finished, so you do not have any backup of that. This is not a problem, this is how a hot backups work, you will never have backups of the latest log sequence. Obviously, the next hot backup will back up that, but by the end of that backup, another sequence becomes the latest sequence.
If you simply try recover database;
, RMAN tries to recover the database to the most current state, and it does not know where to stop (except when you have not only the archivelogs, but the redo logfiles also). Your last log sequence in the backup is 29, RMAN will complain about the next one, because it does not know where to stop.
If you want to avoid the above error, you can explicitly specify RMAN where to stop (perform a point-in-time recovery). For example:
recover database until sequence 30;
This would have had the same result as your recover command, without throwing an error. You can also specify UNTIL SCN
and UNTIL TIME
.
30 because:
When specifying log sequences, if the last created archived redo log
has sequence n, then specify UNTIL SEQUENCE n+1 so that RMAN will
apply n and then stop.
Or, you can just ignore this error and continue with alter database open resetlogs
.
Best Answer
Of course. A consistent full backup created in MOUNT mode does not require any archivelogs to be successfully restored.
An online backup is inconsistent and requires archivelogs for restoring a consistent state.