AWS Database Blog
Restore Amazon RDS for Oracle to a self-managed infrastructure using RMAN duplication
Amazon Relational Database Service (Amazon RDS) for Oracle is a fully managed commercial database that makes it easy to set up, operate, scale a relational database in the cloud. It takes care of installation, storage provisioning, management, OS and database patching, backup and restore automatically. This helps you focus your efforts on where you can make the biggest difference in your business by offloading the undifferentiated heavy lifting of database infrastructure management. As discussed in Restore an Amazon RDS for Oracle instance to a self-managed instance, there are a variety of reasons to restore a copy of your RDS for Oracle instance to a self-managed environment to test out new application code developments or changes. This provides you full control of the Oracle binaries, OS-level access, and elevated database level privileges.
In this post, we show how to take a backup of an RDS for Oracle database instance and restore it on a self-managed environment like Amazon Elastic Compute Cloud (Amazon EC2) using the Oracle Recovery Manager (RMAN) database duplicate method. This is a specific restoration technique, not to be confused with duplication in the generic sense of the word. This method doesn’t require a connection to a target or a recovery catalog. The procedure restores the database, performs a database rename, and starts it on a self-managed server in OPEN mode automatically.
Solution overview
In this method, we take an RMAN backup of the RDS for Oracle instance by using the custom package rdsadmin.rdsadmin rman util as discussed in Step by Step Guide to restore an Amazon RDS for Oracle instance to a self-managed Instance. Then we transfer it to target instance with an Amazon Simple Storage Service (Amazon S3) bucket using Amazon S3 integration. Finally, we restore the backup pieces to the target using the RMAN duplicate method. The following diagram illustrates our solution architecture.
On the Amazon RDS side, you perform the following high-level steps:
- Configure the RDS for Oracle instance with Amazon S3 integration using an AWS Identity and Access Management (IAM) role and option group.
- Create a database directory to keep the RMAN backups.
- Validate the database files (an optional but recommended step).
- Enable archive log retention to 24 hours.
- Take the RMAN backup of Amazon RDS for Oracle using
rdsadmin.rdsadmin_rman_util
. - Transfer the backup pieces to your S3 bucket.
- Delete the files from the RDS instance using
Fremove
to free up the storage space.
In the self-managed environment, you perform the following steps:
- Download the RMAN backup pieces from the S3 bucket to your local server.
- Prepare the environment to initiate the restore.
- Start the auxiliary instance using the modified parameter file.
- Restore the database using the RMAN duplicate method.
- Perform post-recovery steps.
If you’re using Amazon RDS for Oracle with transparent data encryption (TDE) enabled, you receive the following error when you try to access the encrypted columns in the restored database:
The error occurs when TDE wallet is used to encrypt data. As a result, AWS can’t include these items in backup for security reasons. You can use Oracle native export and import for this specific use case.
Prerequisites
To follow along with this post, you should have the following prerequisites:
- Familiarity with the following AWS services:
- Amazon RDS for Oracle
- Amazon S3
- Amazon Virtual Private Cloud (Amazon VPC)
- Amazon EC2
- An S3 bucket with a globally unique name. In this post, our S3 bucket name is
aws2p900rmanbackup
- An RDS for Oracle database instance
Amazon RDS steps
In this section, we walk you through the steps needed on the Amazon RDS side. In a nutshell, we will configure the RDS for Oracle instance, create a database directory inside it, validate the database files, enable archive log retention and finally take the RMAN backup of the instance. This will prepare the RDS for Oracle instance for the next steps.
Configure the RDS for Oracle instance
Create an RDS for Oracle instance with Amazon S3 integration using an IAM role and option group. The IAM role provides the permissions required to transfer files. For instructions, see the user guide.
Create a database directory
Create a database directory in the RDS for Oracle instance with the following code:
Amazon RDS stores the RMAN backup in this directory.
Validate the database files
It’s a best practice to check for the integrity of the database structure, data block, and redo logs. In this step, we validate database files using rdsadmin_rman_util.validate_database
.
We check the data files for any physical or logical corruption using the backup validate command. This command doesn’t create a backup of any data file. Instead, it checks for the validity of the data files and updates the v$database_block_corruption
view if it finds any corruption.
Complete the following steps:
- Check the database structure integrity:
- Run the following query to check the log file of the previous operation:
- Run the following query to open the log file and check for any errors:
- Validate the control file:
- Run the following query to check for the logs:
- Run the following query to open the log file and check for any errors. Replace the file name obtained from the previous query and add it in this query.
- Validate
spfile
with the following code: - Run the following query to check for the logs:
- Run the following query to open the log file and check for any errors. Replace the file name obtained from the previous query and add it in this query.
- Cross-check the archive logs by running the following command:
Enable archive log retention
For this post, we enable the archive log mode on the RDS for Oracle instance and increase the archive log retention period to 24 hours. Because the archive logs are required for a consistent point-in-time restoration, it’s important that the archive logs are retained for at least the duration of the backup. The archive logs are retained in the underlying Amazon Elastic Block Store (Amazon EBS) volumes.
Configure the archive log with the following code:
Take the RMAN backup of Amazon RDS for Oracle
Take an RMAN backup for the entire RDS for Oracle database, along with archive log and control file. The RMAN backup pieces are stored in the underlying EBS volume of the RDS for Oracle instance. It’s imperative that your RDS for Oracle instance has sufficient free space to accommodate the RMAN backup pieces. You can check the free storage space of your RDS for Oracle instance by referring to the Amazon CloudWatch metric FreeStorageSpace
. You can remove the backup pieces from the EBS volumes by using the fremove
command.
- Run the following command to take the RMAN backup of the entire database with two channels:
You can change any parameters depending on your environment. For more details of all parameters of the rdsadmin.rdsadmin_rman_util
package, refer to Performing a full database backup.
- To get the log file name, use the following query:
- Run the following query to open the log file and check for any errors. Replace the file name obtained from the previous query and add it in the next query.
- Run the following query to check the RMAN backup status:
Transfer the backup pieces to an S3 bucket
With Amazon S3 integration, you can transfer files between an RDS for Oracle instance and an S3 bucket. For instructions to set up Amazon S3 integration between your RDS for Oracle instance and the S3 bucket created for copying backup files, refer to Amazon S3 integration. You can also automate RMAN backup on RDS for Oracle instance and upload backup files to Amazon S3. Refer to Automate Amazon RDS backups using the Oracle RMAN utility for more details on this.
Upload the backup pieces to an S3 bucket by running the following command. We use the custom bucket name as input to the parameter p_bucket_name
and specify the database directory name in the parameter p_directory_name
.
The command returns a task ID. Use the following code to check the log file, making sure to insert the task ID. Confirm that the files are uploaded successfully.
Delete the files from the RDS for Oracle instance
After you upload the backup pieces, they’re ready to be downloaded to a self-managed instance like Amazon EC2. As a best practice, delete the files from the RDS for Oracle instance using the following command. This frees up space from the EBS volume. You can observe the increase via CloudWatch metrics.
Self-managed environment steps
In this section, we walk through the steps to complete in your self-managed environment.
You must choose the Linux-x86-64 bit platform for hosting a self-managed database because Amazon RDS for Oracle runs on this platform. It’s always recommended to install the same version of binaries for the restore with the same or higher Patch Set Update (PSU) level in the self-managed target instance.
We use the AWS Command Line Interface (AWS CLI) to complete this process. Make sure that the AWS CLI is installed and configured on the self-managed target server and the S3 bucket is accessible from it.
Download the RMAN backup files and upload them to your local server
Navigate to the directory where you want to store the RMAN backup pieces for the RDS for Oracle instance. Use the following command to download the RMAN backup pieces that are stored in that location:
[ec2-user@ip-xxxx backup]$ aws s3 cp s3://<<YOUR_BUCKET_NAME>> . --recursive
In our case, we use a bucket named aws2p900rmanbackup
:
Prepare the environment for restore
Prepare a dummy parameter file for the target database instance by providing a new instance name in the DB_NAME
parameter, the control file location, and the most important parameters for RMAN duplication like db_file_name_convert
and log_file_name_convert
.
Note the following parameter formats:
- DB_FILE_NAME_CONVERT – (‘Source Location’,’Target Location‘)
- LOG_FILE_NAME_CONVERT – (‘Source Location‘,’Target Location‘)
- Default source data file location –
/rdsdbdata/db/
<DB Name>_A/
datafile/ - Default source redo file location –
/rdsdbdata/db/
<DB Name>_A/
onlinelog/
You can obtain the database name on the Amazon RDS console on the Configuration tab. The target location is the respective mount point and directories created in the target server for hosting the data files and redo log files.
Start the auxiliary instance
To start the auxiliary instance using the dummy parameter file, enter the following code:
Restore the database using the RMAN duplicate method
The following command changes the database name and restores the data files from the backup to the location indicated by DB_FILE_NAME_CONVERT
, updates the new location of the data files in the control file, and recovers the database. In the following example, the location where the RMAN backup was downloaded from in the Amazon S3 environment is ‘/oracle/backup/
’:
The following commands perform the following high-level steps while restoring the database:
- Restore the control file.
- Rename the database file names.
- Restore the data files in the location as specified in
db_file_name_convert
. - Recover the instance.
- Start up the database in read/write mode.
You can check the progress of the RMAN restore using the following queries:
Perform post-recovery steps
The self-managed Oracle instance has sysdba
access; you can customize it according to your organizational policies and standards. After you restore the database, perform the following steps on the self-managed instance:
- Make sure the Oracle binaries and database are at the same Patch Release Update (PSU) or Release Update (RU) level as Amazon RDS for Oracle:
If ORACLE_HOME
is lagging on the PSU or RU level, apply the same PSU or RU used by the RDS for Oracle instance to ORACLE_HOME
of the self-managed instance. Refer the README of the given PSU or RU for more details.
- Make sure the
ORACLE_HOME
used by the self-managed instance has all the required time zone files; otherwise it can throw the errorORA-01804: failure to initialize timezone information
.
You can upgrade the DST manually on your self-managed server to solve this issue by applying DST-related patches to ORACLE_HOME
.
- Drop the
RDSADMIN
user:
The customizations implemented in Amazon RDS for Oracle are achieved by the RDSADMIN user, so you can safely drop this user in a self-managed environment.
Conclusion
In this post, we provided step-by-step guidance on restoring Amazon RDS for Oracle to a self-managed environment using the RMAN duplicate method, which doesn’t require a recovery catalog or connection to the target. You can use the Amazon RDS rdsadmin.rdsadmin_rman_util
package, RMAN, and Amazon S3 integration to restore a physical copy of Amazon RDS for Oracle in a self-managed environment like Amazon EC2 or any other self-managed servers.
We welcome your feedback. If you have questions or suggestions, leave them in the comment section.
About the Authors
Arnab Saha is a Database Administrator with the Support Engineering team at Amazon Web Services. He specializes in Amazon RDS, Amazon Aurora and Amazon Elastic Block Store. He provides guidance and technical assistance to customers thus enabling them to build scalable, highly available and secure solutions in AWS Cloud.
Radhika Chakravarty is a Database Solutions Architect with Amazon Web Services. She works with customers and partners by providing technical assistance to design and implement cloud migration projects, helping them to migrate and modernize their existing databases to AWS Cloud.