-
1. Re: Problem with restoration of RMAN backup to a new host (ORA-01152, RMAN-06053, RMAN-06025)
Dude! Dec 14, 2018 1:09 PM (in response to 3038124)When you backup an open database, the restored database will be inconsistent and require recovery. What probably happened here is that the recovery process could not undo uncommitted transaction because of the missing online redo logs.
If the original database is still running you may need to copy additional archivelogs or perform a log switch and copy those archivelogs. You avoid the problem by including "plus archivelog" with your backup command, e.g. backup database plus archivelog. RMAN will then automatically perform a log switch before and after the backup and include the archivelogs to be able to perform a recovery.
-
2. Re: Problem with restoration of RMAN backup to a new host (ORA-01152, RMAN-06053, RMAN-06025)
3038124 Dec 14, 2018 1:53 PM (in response to Dude!)Thanks for the fast reply!
I will keep that in mind for future backups.
Unfortunately i no longer have access to the original database.
The last backup is from 05. November and I have archive logs from then till 14. November.
Is there any way to recover them, maybe with loss of some data, to a consistent state?
kind regards
-
3. Re: Problem with restoration of RMAN backup to a new host (ORA-01152, RMAN-06053, RMAN-06025)
Dude! Dec 14, 2018 3:39 PM (in response to 3038124)RMAN will use incremental level backups and archivelogs to perform recovery. You might be missing necessary archivelogs to finish the recovery after the recovery process using the incremental level backups. Perhaps it works if you use RMAN to restore the database and then use SQL to recover the database "until cancel" using archivelogs only.
-
4. Re: Problem with restoration of RMAN backup to a new host (ORA-01152, RMAN-06053, RMAN-06025)
CristianR-Oracle Dec 17, 2018 9:06 AM (in response to 3038124)If your last full/level 0 is from 5th of November and you have all the archivelogs until 14th of November then you can do a point in time restore.
1. Restore the controlfile if not done yet
2. Restore the datafiles --? RMAN> restore database;
3. recover the database until 14th:
RMAN> recover database until logseq <last seq + 1>;
or
RMAN> recover database until time "to_date('14-NOV-2018 12:00:00','dd-mon-yyyy hh24:mi:ss')";
-
5. Re: Problem with restoration of RMAN backup to a new host (ORA-01152, RMAN-06053, RMAN-06025)
3038124 Dec 18, 2018 8:57 AM (in response to CristianR-Oracle)Further Information: The backup consists of a full backup (lev. 0) from January and a cumulative, incremantal backup from 5.Nov. 2018.
As mentioned above there are archived logs from then until the 14th November.
Okay, I tried the different proposed options but non of them worked. Here is the summary:
1.) recover database until time "to_date('14-NOV-2018 12:00:00','dd-mon-yyyy hh24:mi:ss')";
There is a message that the control file is used instead of the catalog. Therefore RMAN wants to recover files which do not exist in the new host.
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 12/11/2018 17:03:53
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence....
...
...
Is there a way to force the recovery from the catalog and not form the control file?
-
6. Re: Problem with restoration of RMAN backup to a new host (ORA-01152, RMAN-06053, RMAN-06025)
EdStevens Dec 18, 2018 12:50 PM (in response to 3038124)3038124 wrote:
Further Information: The backup consists of a full backup (lev. 0) from January and a cumulative, incremantal backup from 5.Nov. 2018.
...
Is there a way to force the recovery from the catalog and not form the control file?
level 0 backup i January
Level 1 backup in November.
So you went 11 months with no backup?
-
7. Re: Problem with restoration of RMAN backup to a new host (ORA-01152, RMAN-06053, RMAN-06025)
3038124 Dec 18, 2018 1:04 PM (in response to EdStevens)There seems to be a misunderstanding. I do an incremental, cumulative backup every month.
But I want to restore the last one, of course.
-
8. Re: Problem with restoration of RMAN backup to a new host (ORA-01152, RMAN-06053, RMAN-06025)
Stefan Abraham Dec 19, 2018 6:42 AM (in response to 3038124)Hello,
Not clear on the the backup strategy you are using but you can try below steps for this specific installation.
On new host
rman> crosscheck archivelog all;
rman> delete expired archivelog all;
Copy all archive logs or backups from before the start of the backup you are using. (From 5th before the start of backup since you are using 5th backup)
rman> catalog start with '<archivelog_folder>'
rman> recover database until time '<time till you have archive with>'
Hope you are using the same filesystem structure for both hosts for datafiles?
Thanks
Stefan
-
9. Re: Problem with restoration of RMAN backup to a new host (ORA-01152, RMAN-06053, RMAN-06025)
Dude! Dec 19, 2018 11:25 AM (in response to 3038124)3038124 wrote:
There seems to be a misunderstanding. I do an incremental, cumulative backup every month.
But I want to restore the last one, of course.Is there a way to force the recovery from the catalog and not form the control file?
That's not how it works. You can restore a full or level 0 backup, but incremental level backups and archivelogs are applied during the RMAN recovery phase. If the target control file is mounted and the catalog database is available at command execution, then RMAN automatically resynchronizes the recovery catalog as needed when you use RMAN commands.
RMAN-06025: no backup of archived log for thread 1 with sequence....
You have to troubleshoot the issue. The sequence number is what you need to verify with the information in your RMAN repository. If the location of your incremental backups and archivelogs are not the same as the "original" database, then RMAN will not be able to recover the database, regardless of your catalog database. If the location is different, you need to use the "catalog start with..." command and use "crosscheck" and "delete expired" to remove metadata that is no longer available.