What should I consider before I restore an Amazon RDS Oracle snapshot?
I want to understand the best practices for Amazon Relational Database Service (Amazon RDS) for Oracle snapshot restores. I want to prevent lazy loading after I restore an RDS for Oracle DB snapshot.
Features and limitations of DB snapshot restores
Before you perform a restore, review the following features and limitations of RDS for Oracle DB snapshot restores:
You can't restore from an RDS for Oracle DB snapshot to an existing DB instance. When you perform a restore, Amazon RDS creates a new DB instance.
When you restore an RDS for Oracle DB instance, you choose a number of specifications for your new DB instance. This includes the Oracle DB engine, license model, DBName (SID), and DB instance class that the new DB instance uses.
Note: You can't change the license from Oracle Database Enterprise Edition to Oracle Database Standard Edition 2 during the restore process.
When you restore an RDS for Oracle DB instance, you can use a different storage type than that of the source DB snapshot. But the restoration process is slower because of the additional work required to migrate the data to the new storage type.
When you restore a DB instance, the default DB option group is associated with the restored DB instance in most cases. The exception is when the source DB instance is associated with an option group that contains a persistent or permanent option. In this use case, the restored DB instance must use an option group that contains the same persistent or permanent option.
When you restore a DB instance, the default virtual private cloud (VPC), DB subnet group, and VPC security group are associated with the restored instance. However, you can specify otherwise.
You can't restore a DB instance from a DB snapshot that's both shared and encrypted. Instead, make a copy of the DB snapshot and restore the DB instance from the copy. To do this, you must have access to the AWS Key Management Service (AWS KMS) key that was used to encrypt the snapshot.
Best practices for DB snapshot restores
To avoid the incompatible-parameters status on your RDS for Oracle DB instance, use the following best practices:
Use same parameter group that the original instance uses. Also, use the same memory parameter and instance class.
When you restore a DB instance that uses extended data types, you must specify the same or a new parameter group with the MAX_STRING_SIZE parameter set to EXTENDED. If you specify the default parameter group or any other parameter group with MAX_STRING_SIZE set to STANDARD, then the DB instance goes into the incompatable-parameters status.
Decrease lazy loading after a snapshot restore
When you restore an RDS for Oracle DB instance from a snapshot, the instance is available as soon as the infrastructure is provisioned. However, an ongoing process called lazy loading continues in the background. There's no fixed duration for lazy loading, but you can decrease its effects. When lazy loading is in progress, I/O operations might wait until the requested data is read from Amazon Simple Storage Service (Amazon S3). As a result, I/O latency increases. To reduce any related slowness, read all data blocks as soon as the restore is complete. For more information, see Restoring from a DB snapshot.
To reduce the time it takes for lazy loading to complete, use the following options:
Note: These options are engine-native commands so affect only the primary instance for Multi-AZ Amazon RDS for Oracle DB clusters.
Use the rdsadmin.rdsadmin_rman_util.validate_database package to run a database-level validate command. To avoid throttling, you can modify parallelism based on the number of vCPU.
Perform a Data Pump full export with parallelism based on your engine licensing.
Perform an explicit select on all large or the most heavily used tables individually with parallel hint. You can perform operations that involve full-table scans, such as SELECT *. This allows Amazon RDS to download all of the table data that's backed up from Amazon S3.
For restore from snapshot or point-in-time recovery (PITR) operations on Multi-AZ, first perform the RMAN validation. Reboot with failover, and then perform RMAN validation again.
If you use Data Pump (expdp), then you must perform the export on both hosts in a Multi-AZ setup.
Note: If you use a Data Pump database with 10 TiB of data, then you must have at least 10 TiB of free space on your RDS for Oracle DB instance.