vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| 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 |