These are the rman commands used to do the restore.
startup force nomount;
restore controlfile from '$mediahandle';
alter database mount;
restore database from tag $tag;
alter database open resetlogs;
The $variables are shell variables that specify the appropriate
information needed to restore the correct control file and backup sets.
It's part of a script that's worked dozens of times before. Everything
worked fine up to the "alter database open resetlogs;" where it started
complaining about needing recovery on one of the files. There were no
errors in either the backup or the restore.
TIA
How was the backup originally taken?
HTH
-g
For wild stab's in the dark, I would ask these questions:
1) is it possible that the control file that you restored is not the
correct one?
2) is it possible that what you describe as a clean shutdown was not
exactly in that manner?
With the database down. The controlfile backup was an auto backup
shutdown immediate
startup mount
backup database;
alter database open;
One of my colleagues suggested after the restore I need todo "recover
database noredo" but if I understand corrrectly that's only necessary of
the online redo logs were lost. They weren't.
Been checking these very things all morning. The control file is the
correct one taken immediately after the database backup via controlfile
autobackup (same scn), and the alert log shows nothing unusual happened
between the "shutdown immediate", and the "alter database open".
Oddly if I use the backup reports in Grid Control for this database, it
shows the status of the backup I restored from as "FAILED" (I think that
status comes from v$rman_backup_job_details), but the RMAN output log
from the backup itself shows no errors, all files backed up succesfully
and the return code was 0.
FYI the MML is Veritas Net Backup if it makes a difference.
Sometimes this is a slightly misleading message, due to some other
file needing recovery.
The other file may have been offline or read-only when the backup was
taken (or, I'm guessing, the db was shut down).
Are any of your data files fuzzy? See metalink Note:337450.1 for some
thoughts.
>
> These are the rman commands used to do the restore.
>
> startup force nomount;
> restore controlfile from '$mediahandle';
> alter database mount;
> restore database from tag $tag;
> alter database open resetlogs;
>
> The $variables are shell variables that specify the appropriate
> information needed to restore the correct control file and backup sets.
> It's part of a script that's worked dozens of times before. Everything
> worked fine up to the "alter database open resetlogs;" where it started
> complaining about needing recovery on one of the files. There were no
> errors in either the backup or the restore.
>
> TIA
>Oddly if I use the backup reports in Grid Control for this database, it
>shows the status of the backup I restored from as "FAILED" (I think that
>status comes from v$rman_backup_job_details), but the RMAN output log
>from the backup itself shows no errors, all files backed up succesfully
>and the return code was 0.
Well, if grid control is confused, maybe something else is, too.
jg
--
@home.com is bogus.
D'Oh! http://www.signonsandiego.com/uniontrib/20080507/news_1b7saic.html