A cold backup was taken of a 10.2.0.3 database using rman. The database
was shut down cleanly before the backup was started. When I tried to
restore the backup a few days later, it would not let me open the
database. It said that file 1 (system01.dbf) file needed further
recovery. Why would a file need *any* recovery if it was a cold backup?

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

On 7 May, 16:41, Chuck <skilover_nos...@bluebottle.com> wrote:
> A cold backup was taken of a 10.2.0.3 database using rman. The database
> was shut down cleanly before the backup was started. When I tried to
> restore the backup a few days later, it would not let me open the
> database. It said that file 1 (system01.dbf) file needed further
> recovery. Why would a file need *any* recovery if it was a cold backup?
>
> 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

On May 7, 11:41*am, Chuck <skilover_nos...@bluebottle.com> wrote:
> A cold backup was taken of a 10.2.0.3 database using rman. The database
> was shut down cleanly before the backup was started. When I tried to
> restore the backup a few days later, it would not let me open the
> database. It said that file 1 (system01.dbf) file needed further
> recovery. Why would a file need *any* recovery if it was a cold backup?
>
> 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

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?

gazzag wrote:
> On 7 May, 16:41, Chuck <skilover_nos...@bluebottle.com> wrote:
>> A cold backup was taken of a 10.2.0.3 database using rman. The database
>> was shut down cleanly before the backup was started. When I tried to
>> restore the backup a few days later, it would not let me open the
>> database. It said that file 1 (system01.dbf) file needed further
>> recovery. Why would a file need *any* recovery if it was a cold backup?
>>
>> 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

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.

hpuxrac wrote:
> On May 7, 11:41 am, Chuck <skilover_nos...@bluebottle.com> wrote:
>> A cold backup was taken of a 10.2.0.3 database using rman. The database
>> was shut down cleanly before the backup was started. When I tried to
>> restore the backup a few days later, it would not let me open the
>> database. It said that file 1 (system01.dbf) file needed further
>> recovery. Why would a file need *any* recovery if it was a cold backup?
>>
>> 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
>
> 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?

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.

On May 7, 8:41*am, Chuck <skilover_nos...@bluebottle.com> wrote:
> A cold backup was taken of a 10.2.0.3 database using rman. The database
> was shut down cleanly before the backup was started. When I tried to
> restore the backup a few days later, it would not let me open the
> database. It said that file 1 (system01.dbf) file needed further
> recovery. Why would a file need *any* recovery if it was a cold backup?

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/uniont...s_1b7saic.html