This content has been marked as final. Show 10 replies
In this case, the target database controlfile would be updated about the new location of the backup pieces. (/u04/backup/RMAN)
In this case, the target database controlfile would be updated about the new location of the backup pieces
How ? How will RMAN know about the location of backup pieces in the standby server ? I didn't see any commands for this above.
if you used OS commands to move the backuppieces to /u04 AND the backup was NOT created in that location, RMAN will NOT know of the location.
you need to catalog the backuppieces in the new location.
while connected to the primary DB, from the standby server, issue:
this should work.
RMAN>catalog start with '/u04/backup/RMAN/'
but, for regular duplicates, I usually maintain the same directory path in both servers.
although I understand, this may not always be possible.
another solution, is that you create a symbolic link in your standby server, duplicating the existing path in your production server.
Edited by: Pinela on Dec 21, 2012 7:54 AM
Hi Pineala,1 person found this helpful
As OP mentioned, the control file is not restored yet. The auxillary instance is still in NOMOUNT state. You need the control file to issue the CATALOG command.
I think (I could be wrong ) , in standby server you must use the same location in primary server when you took the RMAN hot backup.
So, if you used /u07/data/backup in the primary DB server as the backup location, when you copy the backup pieces to standby server , you better create a location like /u07/data/backup there and store the backup pieces there. RMAN will be looking at this location by default
Hi tom,1 person found this helpful
yes, but, when you duplicate you connect to the primary and the auxiliary.
so you do have a CF (the primary's CF) and you can catalog into that CF.
for example, I am sure if:
-he moved the backup pieces into the /u04/data/backup directory in the primary server,
- catalog them,
-move the files into that same directory into the standby server,
- and issued the duplicate,
it would work.
the other solution, is the symbolic link. I have used this technique for backups and it works (at least in 11gr2). Not sure if the duplicate will get it. But for backups it works.
Edited by: Pinela on Dec 21, 2012 8:12 AM
1 person found this helpful
How ? How will RMAN know about the location of backup pieces in the standby server ? I didn't see any commands for this above.My bad. Firstly, let me know why do you require to connect to the target database when you have its backup on the standby server ?
Its a normal restore you do. Here are the steps:
Finally start the MRP process. Refer this link http://shivanandarao.wordpress.com/2012/04/19/duplicating-primary-database-to-a-new-host-without-connecting-to-the-primary-database-in-oracle-10g11g/ for the steps though this is not for a standby database, it can give you an idea about the steps.
1. set the dbid on the standby server through RMAN (DBID of standby database would be the same as the primary database) 2. startup force nomount the standby instance using a dummy pfile 3. restore the spfile from the backup. 4. Make necessary changes in the restored spfile required for a standby database (archive destinations, service names, path of control files and related information). You can do this by creating a pfile for the above restored spfile. Make sure you start the standby instance back with the updated spfile. 5. Connect the standby instance through RMAN and restore the standby controlfile using command "restore standby controlfile from <'path of the backup on the standby server'>".Hope you would have taken the backup of controlfile of primary database in a standby format. 6. catalog the backups located at new location. 7. set newnames if required for the standby datafiles. 8. restore and recover the database.
Hope you got an idea.
Thank you Sivananda.
Now I am wondering why does everyone use RMAN DUPLICATE as the preferred method to create a standby DB if this can be achieved using a regular RMAN restore, Recover ? What is the advantage of using RMAN DUPLICATE ?
For a duplicate you must connect to the target database.
For a normal restore, like you suggest, no, you don't need to be.
but a normal restore is not a duplicate. a restore operation is simply part of the duplicate operation.
simple. duplicate is a quicker and simpler method because you issue just one command.
After configuration, you issue just one command, and if the pfile/spfile is correctly configured, RMAN takes care of ALL the necessary steps, even for ASM (taking care of the switch datafile also). it restores the cf, it mounts the db, it restores, it recovers, it updates the CF with the correct names, it converts filenames if necessary, opens the DB etc.
And, since only a single command is used, it is less prone to errors.
And that saves you a lot of trouble.
Simply you have some details, like the location of the backuppieces.
it works great also for DEV env refreshes (with some modifications to the pfile/spfile).
Edited by: Pinela on Dec 21, 2012 4:02 PM
Great explanation Pinela. THANK YOU.