RMAN create standby database - Are you like me and use "restore database" for large databases, or like most people (based on my Linkedin poll) and use "duplicate for standby"?
![]()
The table below shows you the 3 main differences between the 2 methods.
![]()
This post started with a discussion within my team around which method you use. I, being of the "restore database" camp, didn't realize how commonly used "duplicate for standby" is.
I have also dug through the documentation, and there is no common method that is mentioned. Even the 21c documentation for creating a standby database doesn't mention using the duplicate command.
Well in this post, I will explain why "restore database" has been my preference.
Duplicate database for standby
From the poll I ran, this is the most common way to create a standby database. It is probably the simplest way also because a lot of the configuration of the standby database is done automatically as part of the automated process.
Below is the simplified steps to perform this process.
PRE work
- Create simple initfile on the standby host. The real SPFILE will be brought over as part of the duplication process. This may contain location parameters for datafiles and redo logs if different from the primary.
- Create directories on the standby host. This includes the audit directory, and possibly the database file directories if they are different from the host.
- Startup nomount.
Duplicate
The duplicate process automatically performs these major steps using the standby as an auxiliary instance.
- Create an SPFILE. The process creates an SPFILE for the standby and sets parameters for the standby.
- Shutdown/Startup standby database. This will use the newly created SPFILE during the rest of the processing
- Restore backup controlfile for standby database. The controlfile for the standby database is put in place, and the spfile is updated to it's location
- Mount controlfile . Mount the controlfile that was restored
- Restore database . Restore the datafiles files for the CDB and PDBs to their new location on the standby
- Switch datafile . Uses the new location of the datafiles that were restored.
- Create standby redo logs.
- Set parameters for standby database. The parameters necessary to communicate with the primary database are set.
- Put standby in recover mode . By this time, you should have set the primary database to communicate with the standby database.
NOTES
If you noticed above, I highlighted the second step which forces a shutdown/startup of the standby database. Because of this step, it is not possible to use this method and restore across nodes in a RAC database. This can cause the duplicate operation to take much longer for larger databases.
Then in step #5 you can see that the "Restore Database" is automatic in the processing and it is not possible to perform a "restore as encrypted" if you are migrating to OCI from a non-TDE database. The duplicate process does support "restore as encrypted", but only for creating a new Database, not a standby database.
Restore Database
This is the method that I've always used. There is no automation, but it gives you much more control over the steps.
PRE work
- Restore copy of prod SPFILE to standby host. For this process, it doesn't matter if it is an intifile or spfile. In this file you set all the parameters that are needed for the standby database to communicate with the primary and store datafiles/logfiles in the correct location.
- Create directories on the standby host. This includes the audit directory, and possibly the database file directories if they are different from the host.
- Startup nomount.
- Create copy of primary controlfile for standby. This will be used for the standby database, and should contain the backup catalog of the primary database, and the RMAN settings including the channel definitions.
- Copy standby controlfile to standby host. The controlfile is copied to the standby host, and may be put in ASM at this point. Ensure the spfile points to the controlfile (and/or srvctl).
- Alter database mount. Mount the controlfile.
- Start up ALL nodes in the RAC cluster in mount mode. This will allow you to restore the database across ALL nodes in the RAC cluster, and include all the networking from these nodes. For a large database hosted on multiple DB nodes this can make a HUGE difference when restoring the database.
- Create (or copy) TDE wallet. If the standby database is going to be TDE, then include the wallet if the primary is TDE, or create a new wallet and key if the standby database is going to be TDE.
Restore Database
The restore process is a manual process
- RMAN Connect to database (and possibly RMAN catalog). Connect to the database and make sure you have access to the backups. For ZDLRA this may mean connecting to the RMAN catalog.
- Restore Database (as encrypted). This will restore the database to the new location. With Restore Database, the database can be encrypted during the restore operation. With 19c it is supported to have the standby database be encrypted without the primary database being encrypted (Hybrid dataguard).
- Switch datafile . Uses the new location of the datafiles that were restored.
- Recover database. This will use the archive logs that are cataloged to bring the standby database forward
- Create standby redo logs.
- Set parameters for standby database. The parameters necessary to communicate with the primary database are set.
- Put standby in recover mode . By this time, you should have set the primary database to communicate with the standby database.
NOTES
With the restore database, there are 2 sections I highlighted and these are the advantages that I love about using this method.
- RMAN is restoring across multiple nodes in a RAC cluster which can make the restore operation much faster.
- Restore as encrypted allows you take a database that may have TDE partially implemented, or not implemented and create a new standby database that is encrypted. With the duplicate method, TDE would have to be implemented separately.
If you are restoring a VERY large database (200 TB for example) that was not TDE from object storage to the Exadata Cloud Service, both of these advantages can make a HUGE difference when creating a standby database.
Comparison
The chart below compares the the differences between "Duplicate Database" and "Restore Database".
WARNING: When using a ZDLRA for backups, it is NOT recommended to use the "Restore Database" to clone a database as a new copy. Registering the restored copy can cause issues with the RMAN catalog because the "restore database" leaves entries in the RC_SITE table.
