Menu
Restoring Files with RMAN. Use the RMAN RESTORE command to restore the following types of files from disk or other media. Database (all datafiles) Tablespaces. Control files. Archived redo logs. Server parameter files. Because a backup set is in a proprietary format, you cannot simply copy it as you would a backup database file created with an operating system utility; you must use the RMAN.
Hi,I have two servers, one with our production database, and another hosting a standby database. Each also has its own catalog database as well. I took a full rman backup this morning at 6:30am and used it to restore onto the standby server - it included the spfile, controlfile, datafiles, etc. The standby database is working great, and mirrors production as of 6:30am.At 12:30pm I did a backup of my archive logs from the prod database. The file is PTMNARCHK1KLU4EK11.BKP and is roughly 700MB in size. I am copying it to my standby server to my flash recovery area, but it doesn't seem like RMAN sees it. I do a 'list backup from 2009-08-05:12:35:00' and get no results.Can anyone tell me the proper command to use this particular file to 'roll my database forward' so that it will mirror the prod database as of 12:30pm?My flash recovery area is G:oracleproduct10.2.0f lashrecov eryarea which is where the files for my spfile+controlfile in the form of.bkp files reside.
However, I also have the actual rman backup files database+archivelogs in this directory: D:rmanbackupdatabase.How do I know which directory this file belongs in?Many thanks! Yes, the directory structures are both servers are identical.
Also, the spfile does not seem to show any RMAN configuration settings. When I do a 'show all' from RMAN prompt, both servers configurations are also identical except for one setting: 'configure snapshot controlfile name' points to a different folder on the prod server than it does on the standby server. But I think that is irrelevant for this discussion, right?When I issued crosscheck archivelog all from th standby server it crosschecked 13 objects, but again it still didn't use the.bkp file which I copied to the flash recovery area on the G: drive. Instead it found archive logs with.arc extension in two locations.The first: G:oracleproduct10.2.0f lashrecov eryareaP TMNARCHIV ELOG2009 0805The second: L:archivelogsptmnptmn autobackup 2009080 5Am I unable to restore my archive logs from a.bkp file? I'm sure there's a way since rman does the backup in that format to begin with, but I'm struggling with the syntax still. I thought it was like this: recover archivelog from backup 'insert path here' but obviously I am wrong.Any more help would be much appreciated. Actually, no I am wrong.
I have a.bkp file in: L:archivelogsptmnptmn autobackup 2009080 5 which I copied as part of the restore database operation that I did yesterday, but during the crosscheck RMAN says it found files here: L:archivelogsptmnptmn archivelog 2009080 5, but that directory does not exist! Where is it pulling that information from (the inventory of the prod database since that's the DB instance that was recently restored???), and how do I clear that and make it look in the right locations? 1- Yes, this is a manual process at the moment just for testing purposes until we prove it works. I copy the archive logs in the form of.bkp files from prod server to standby server. Directories are identical.2- It received them because I copied them, but no, it did not apply them.
That's my goal. I have my database as of 6:30am yesterday. I have two.bkp files (1 contains spfile and controlfile, the other contains just archive logs), and I want to 'roll forward' the archive logs.3- What is a DML?Rigth now if I do list backup or crosscheck archivelog I get absolutely nothing. It appears my catalog is not seeing anything, even though I restored the controlfile from the latest autobackup.Can you give me step by step instructions on how to restore archive logs?
I hope that's a little clearer.Thanks for your help so far. Prod query:SQL select dbid from v$database;DBID-SQLStandby query:SQL select dbid from v$database;DBID-SQLI assume that's good since it knows which DB ID it's attempting to become.@mrjoltcola: I already did the catalog operation you and it-rex mentioned while disconnected from the catalog, thus, using the control file. However, you need to re-connect to the catalog in order to do the resync operation - otherwise I get an error saying operation not permitted while not connected to a catalog. The target and catalog databases are definitely correct - the standby server has no link back to the target server. The tnsnames has no entry to the SID on that server.When I tried register db I get:RMAN register database;RMAN-00571: RMAN-00569: ERROR MESSAGE STACK FOLLOWS RMAN-00571: RMAN-03002: failure of register command at 13:47:25RMAN-08040: full resync skipped, control file is not current or backupRMAN. 1) Standby databases WILL have the same DBID2) RMAN is standby aware, if you use it correctly3) You should be using a recovery catalog doing the type of work you are doing. The catalog needs to be accessible from both primary and standby.
When you take backups on the primary or standby, the backups will automatically be recorded in the central catalog. This is the only way to do this in a Dataguard cluster.You are jumping through hoops when you don't need to, and I think the root problem goes back to the fact that may have taken the initial backups of the archivelogs without connecting to a catalog. If you always connect to the catalog, then you can take/restore backups from either primary or standby node, because it is all the same DBID.
![Restore archive log file from rman backup Restore archive log file from rman backup](/uploads/1/2/5/5/125561227/993615013.png)
No no no.guys, assume the prod server/db is unavailable. Disaster has struck, and I'm left with the backup files on the standby server/db - it has its own catalog! The two are not interconnected in any way.Here's what I am doing at this very moment:- Restoring the standby database as of 6::30am yesterday using the backupsets created from the target db that I manually copied to the standby server.-Then, the goal is to use the backuppiece created from the target server yesterday at 12:30pm to restore te archive logs to that point in time. They have been manually copied to the standby server in the flash recovery area. What is the command syntax or how do I do this?
@it-rex:1) It is not a public bug, and is specified for 10.1 so be careful about giving support here based on the Metalink info.2) He is running 10.23) He is not using Grid Control to do this that I am aware of, and that is what the bugs refer to.4) He is not trying to take a backup of his standby, he is trying to restore the standby which should already be properly registered in the catalog.BUT he says he is not using a catalog, so we are mainly in a backup and recovery scenario. So lets regroup and understand what he really wants to do.He cloned the primary, but I do not see that he ever activated it in the ROLE of standby, I do not see that he ever started managed recovery, etc. So is the database open? If so, then retrace all the way back to where you tried to catalog the backup piece while connected to some unknown RMAN catalog:When you performed that step, were you connected to a catalog or not?Then here you tried to register the standby database:But you should not do that, the database should already be registered.So lets get one thing clear before proceeding:Do you want to do this with an RMAN catalog or not?
If so, please give the history of the catalog.rman target / catalog=rman/pass@CATRMAN list incarnation. @mrjoltcola: I think you're starting to understand. Most of what you said to it-rex is correct. No dataguard, no grid control, no 'standby role'.
Just a backup server with a database and catalog, similar if not identical to the way the target server is setup.I take a full RMAN backup with control file, spfile, archive logs, and datafiles. I restore, recover, open resetlogs, and all is good. Time goes by, data is changed, and archive logs are created from prod server.
I copy them to the backup or 'standby' server. My prod server crashes about an hour later. I want to restore my archive logs that were just taken recently, to bring my backup/standby server to a current state, more current than the complete rman restore that was done several hours ago earlier in the day.When I tried to catalog the backup piece WHILE connected to the catalog on the backup server, I got an error saying target database not in recovery catalog. That's when, with the help of this topic, you guys told me to disconnect from the catalog and use just the control file. I don't know if this is advised, but I am just following your guidance. With that, it worked and was properly catalog in the CONTROL FILE.
Then, you guys suggested to do a resync. I re-connected to the catalog since you have to he connected to do a sync, and when I issued the command, I got the same error. That's where I'm stuck, and I am still unsure of the proper syntax to say 'restore archive log from backup piece.'
![How to restore tablespace from rman backup How to restore tablespace from rman backup](/uploads/1/2/5/5/125561227/621350972.png)
Ok, we are getting somewhere.1) The RMAN catalog, is it the same catalog that you were using for the backups of the primary?2) Since you have opened with resetlogs, the bad news, you cannot recover with those archivelogs unless you use flashback or restore from the original backup image prior to the open resetlogs. You've created a new incarnation and a new log sequence. With 10g and 11g it is possible to recover and roll forward by applying logs ACROSS resetlogs boundaries, but it requires you flashback / restore to a point prior to the last SCN before the recover step. Once you open resetlogs on the copy, it is diverged from the primary (primary goes down Main Street, clone goes down First Street). So you have to head back to First and Main intersection, and recover.NOTE: I have not suggested you resync or register anything.
But the confusion starts when discussing standby, because we immediately think 'Data Guard' cluster. Yes, sorry for the confusion. I just saw that 'standby database' is actually an industry term which seems to describe an online replication of some sort. I am not doing something that advanced or complex (I don't think).To answer #1, no, I do not believe it is the same catalog - I've said now a few times, each server has its own catalog. Target server = primary db + catalog. Backup server = backup db + catalog.For #2, I think I understand what you're saying. Where can I go from here?
I'm trying to get back to a point where I am ready to attempt restoring archive logs again, but after just finishing the restore+recovery, I get an error saying data file 5 needs media recovery after doing open resetlogs. These are different options below to accomplish your standby solution. This is a very complex question and is honestly best done by voice, because the nature of the options differ and need to be explained.
I'll do my best.In no particular order of value or complexity, some options:1) Keep a non-dataguard 'standby' ready for recovery, but simply don't open it. Just keep it in recovery mode and apply logs as you need to. That way you won't create a new incarnation.
It is the act of 'open resetlogs' that you need to delay until needed. Keep in mind, you need to be constantly shipping logs or backupsets over to the standby for availability, or must have to delay the application of the logs until the failure, and for that reason, I really don't see any advantage to this step, but we used to do this prior to data guard with manual scripts.2) If you want to open the 'standby', for testing, or whatever, then configure Oracle flashback database. It will allow you to flashback and recover again and again. The flashback will send you back in time, then you can recover again.OR3) Simply restore a full backup and recover as far as you can, using the backupsets / archivelogs. This option is a delayed response option, in that you have to wait until the disaster to start all of the restore / recovery work.
If going this route, at least periodically test the backups by doing this restore.What is to be gained from using separate catalogs? I do not advise that. It would solve your problem of having the correct history available to RMAN without any 'catalog operations', this is the whole point of the centralized catalog. Yes, the directory structures are the same. Drive letters are the same. Since I'm running out of 1-2-3s and a-b-cs I'm switching to Roman Numerals.:)I.
There is the solution to rescue you from a minor mess that is based on a simple mistake.If you cannot open without further recovery (file 5 needs media recovery) then RMAN is looking for the next archive log. Perhaps it was not properly backed up, or rotated out in the first place, or perhaps the catalog command never worked. You can continue this route and probably learn some valuable lessons.II. There is a long-term, proper solution to accomplish what you originally set out to do.Start over and do it right. If the restores are not executing again, you may try restore with the 'force' option.I've needed it at one point in the past when RMAN was trying to be too smart and thought the file did not need restoration.The situation you are in is simply lack of enough archive logs to finish the recover. You can continue down the path and restore the archive logs with your original scenario, but I'm dubious, because if you ever opened your database, then it should open now, unless you had repeated a restore. I am just about to close this topic since I have made some progress now, but I had just one last question.
Here's what I did:Deleted all files and references to any backups and logs other than 8/5/09 which is the date I want to roll forward to. Restored the controlfile from autobackup from that date. Restored the datafiles again, then did a recover and open with resetlogs. It succeeded.
Then, when connected to my catalog on the backup server, I did a 'catalog backuppiece' using the backup from 12:30 on 8/5/09. Then I had to register my database with the catalog. It worked, and a resync also succeeded after that. Finally I ran 'restore archivelog all' which seemed to complete successfully as well. I can see the new.arc files in the directory I expect.however. I thought this step was the part where the database gets 'rolled forward'. But, when I check my ERP program for the data, I did not see anything new after the restore I did from 6:30am.
So here's my last question:Does 'restore archivelog all' actually import the archive logs, or does it just extract them from my.bkp file and put them on the hard-drive? If the latter, then what is the command to actually make the database import those.arc files? Is it a recover database?If it's ok with you guys, I'd like to split the points, 250 a piece, between mrjoltcola and it-rex, since you both offered helpful advice throughout the troubleshooting process.Thanks again.
Does 'restore archivelog all' actually import the archive logs, or does it just extract them from my.bkp file and put them on the hard-drive?Latter. RESTORE restores files, period. It doesn't do anything else to the files. It can restore from IMAGE copies or BACKUPSETs.
'restore archivelog' just grabs the log files from whereever RMAN decides is best (if you have multiple backups) and puts them back on the filesystem or ASM so the database can see them. 'RECOVER' applies the redo (by reading from archive logs) and will access and restore logs as needed if available in the catalog and the media layer.I agree with your choice of closing, it is your question, and your decision. Also please make sure to take my recommendations in consideration, such as using a centralized RMAN server. That way there is no registration, etc. You simply run RMAN from the replica copy, connecting as the original database (since the DBID matches) and restore. As far as the catalog is concerned, it is the same database. Restores are easy, but just be careful about performing backups from different copies of the same database using a central CAT, that will cause issues if not done right.Make sure to thoroughly test your DR scenario once or twice, and document it.
Trust me, if/when you actually need it, you may have forgotten our conversation and some of the steps, and that document will be invaluable. I definitely consider all recommendations and advice given to me, that's why I'm here:)I am also documenting as much as I possibly can so that I remember what I did to get it to work.Where I am now: I did a restore archivelog all which took two different backupsets from 08/0509 and 08/06/09 and restored the logs into a folder based on today's date, 08/07/09. I did a crosscheck and a list backup and the catalog apperas to be aware of the files. I can see them on the disk and they appear the right size. They start with sequence # 4299 and go through 4324.If I issue recover database it appears to work, but finishes in 0 seconds and does not error out. That's strange. The same happens if I do recover database until sequence = 4324Then if I do recover database until time 07-AUG-09, it starts, but errors out with 'datafile 1 must be restored from backup created before 07-AUG-09'.And finally, if I do recover database until time 06-AUG-09 it RMAN-06004: ORACLE error from recovery catalog database: RMAN-20207: UNTIL TIMEor RECOVERY WINDOW is before RESETLOGS time.Your thoughts?
I feel like I am inches away from success.