Oracle Recovery Manager Purpose And History
Oracle Recovery Manager (RMAN) was developed essentially as a way to more effectively backup and recover Oracle databases, as an automation mechanism for the same, and as a way to keep track of and managing backup sets. It was introduced in version 8 of the Oracle database, so it has been around for quite a while. In addition to managing backups, it includes other functionality that helps with managing standby databases and creating duplicate databases.
In this article I will discuss several ways that RMAN can be used to duplicate a database and to recover an existing database. My objective is to discuss the different uses for RMAN and some important enhancements that have been made over time. I will not include specific syntax or detailed instructions but there are links to the Oracle documentation at the end of the article where you can find more detail.
In terms of managing backups, RMAN has many benefits over managing backups manually. Some of the more important benefits include its ability to track the available backups and the location of the backup files, and the ability to enforce retention strategies by preventing the removal of backup media (as long as the backup files are not deleted outside of RMAN). The robust way that RMAN manages backup sets contributes to its utility for duplicating and restoring database.
Active Vs. Backup-Based Duplication — The Evolution Of Database Duplication With RMAN
Database Duplication has been enhanced in important ways in the past few versions of Oracle.
In Oracle 10g, the only option was to create a duplicate database using the backup files and archived redo logs of the source database. This meant that the target host had to have access to these files so we had to copy these to the the target host before the duplicate database operation could take place.
Oracle 11g introduced Active Database Duplication as a new option. With this option, the backup files are no longer required because RMAN duplicates the database by copying images of the source database files (not backup files) directly over the network. If desired, however, we can still use the original backup-based duplication.
Oracle 12c introduced Active Database Duplication using backup sets. Now, when using this option, we can choose between using database file image copies (this was the only option when using Active Database Duplication in 11g) or using backup sets. Using the new backup set option has a number of advantages including reduced load on the source system and the ability to use encryption and compression options when creating the new database. This is similar to using the original backup-based duplication except that we don’t have to copy the files over manually.
Key Use cases of RMAN
Create A Test Database Or Refresh A Development Database
RMAN can be used to create a duplicate database for testing or development purposes. A test database is useful for application testing, testing of Oracle Upgrades, or for refreshing a database to be used for development purposes. We can duplicate the entire database or only a portion of it.
Be aware of the security implications of using data from production in your test or dev environments and take proper precautions to protect those environments. Consider using Data Masking to prevent sensitive data from being exposed to your Test and Development Environments. A future blog post will discuss how to use Data Masking for this purpose.
Here are the high level steps for duplicating a database for test purposes (Oracle 12c):
- Determine our naming convention for files on the destination host. This is important if we are creating the duplicate database on the same host as the source database.
- Decide what type of duplication we will be doing (Active vs Backup Based, If active, Image vs Backup Sets)
- Make source database backups available to the destination if necessary (depends on the type of duplication)
- Create and prepare an instance on the destination host to hold the duplicate database.
- Launch RMAN and connect to the source and destination databases (in the RMAN context, the source database is known as the target database and the destination is known as the auxiliary database). The channels and connections that we specify in this step will depend on the type of duplication we are performing.
- Issue the RMAN DUPLICATE command: There are various important options that will need to be set depending on the type of duplication we are performing.
Create A Standby Database For Disaster Recovery
RMAN can be used to create a standby database to be used for disaster recovery purposes. The steps for creating a standby database are similar to the steps for creating a test or dev database except that we will specify ‘FOR STANDBY’ and ‘DORECOVER’ in the RMAN duplicate command.
Optionally, when using a standby database for disaster recovery, we may also wish to configure standby redo logs on the primary database and configure the Data Guard Broker to facilitate automatic switchover and failover operations.
Create A Standby Database For Reporting
RMAN can be used to create a standby database to be used for reporting purposes. And as of Oracle 11g, if using the separately licensed Active Data Guard Option, the reporting database can stay in recovery mode (redo logs being applied) so the data does not get stale during reporting. Prior to 11g, in order to report using a physical standby database for reporting, recovery had to be suspended while the database was open for reporting. The process of creating a standby database for reporting purposes is similar to the process of creating one for disaster recovery except that at the end of the process we open the database in read only mode.
RMAN Database Recovery
In the event of the loss of a datafile or a tablespace, RMAN can be used for database recovery. Because RMAN keeps track of when data file and archive log backups were taken and where they are located, it can easily restore these files when we issue a RESTORE command. And a a RECOVER command then performs the recovery operation. The basic steps that we follow when recovering a database or data file are as follows:
- Determine what needs recovery: (Entire Database, Data File, Tablespace).
- Launch RMAN and connect to the database to be restored and to the RMAN repository.
- Confirm that the required devices and channels are configured and configure them if necessary.
- Issue the required RESTORE and RECOVER commands
Notes And Links To Detailed Instructions
- RMAN Duplicate database supports cross platform duplication with some restrictions: See Oracle Doc ID 1079563.1 for more information.
- Oracle Enterprise Manager: This post described using RMAN command line statements to duplicate or recover databases. Oracle Enterprise Manager (Also known as Grid Control or Cloud Control, depending on the version of the database), can be used to complete some of the above tasks as well without using the command line.
- Detailed instructions for duplicating a database in 12c using RMAN can be found here: https://docs.oracle.com/database/121/BRADV/rcmdupdb.htm#BRADV89927
- A full discussion of the duplicate command and a nice table showing how the various file types are created on the destination host can be found here: https://docs.oracle.com/database/121/RCMRF/rcmsynta020.htm#RCMRF126
- Full instructions for performing a database restored can be found here: https://docs.oracle.com/database/121/BRADV/rcmcomre.htm#BRADV89773
- Detailed instructions for duplicating a database for the purposes of creating a standby database can be found here: https://docs.oracle.com/database/121/SBYDB/rcmbackp.htm#SBYDB4981
I hope you found this discussion of ORACLE RMAN database recovery and duplication helpful. Please leave any comments or questions and I will do my best to respond.
If you need help managing your Oracle database or just have a question, give us a call at (888) 809-4803 x 700 or visit www.budaconsulting.com.
