Requirements and considerations for RDS for Oracle replicas (original) (raw)

Before creating an Oracle replica, familiarize yourself with the following requirements and considerations.

Topics

• Version and licensing requirements for RDS for Oracle replicas
• Option group limitations for RDS for Oracle replicas
• Backup and restore considerations for RDS for Oracle replicas
• Oracle Data Guard requirements and limitations for RDS for Oracle replicas
• Miscellaneous considerations for RDS for Oracle replicas

Version and licensing requirements for RDS for Oracle replicas

Before you create an RDS for Oracle replica, consider the following:

• If the replica is in read-only mode, make sure that you have an Active Data Guard license. If you place the replica in mounted mode, you don't need an Active Data Guard license. Only the Oracle DB engine supports mounted replicas.
• Oracle replicas are supported only for Oracle Enterprise Edition (EE).
• Oracle replicas of non-CDBs are supported only for DB instances created using non-CDB instances running Oracle Database 19c.
• Oracle replicas are available for DB instances running only on DB instance classes with two or more vCPUs. A source DB instance can't use the db.t3.small instance class.
• The Oracle DB engine version of the source DB instance and all its replicas must be the same. Amazon RDS upgrades the replicas immediately after upgrading the source DB instance, regardless of a replica's maintenance window. For major version upgrades of cross-Region replicas, Amazon RDS automatically does the following:
  • Generates an option group for the target version.
  • Copies all options and option settings from the original option group to the new option group.
  • Associates the upgraded cross-Region replica with the new option group.
    For more information about upgrading the DB engine version, see Upgrading the RDS for Oracle DB engine.

Option group limitations for RDS for Oracle replicas

When working with option groups for your RDS for Oracle replica, consider the following:

• You can't use a replica option group different from the source DB instance option group when the source and replica are in the same AWS Region.
  Modifications to the source option group or source option group membership propagate to Oracle replicas. These changes are applied to the replicas immediately after they are applied to the source DB instance, regardless of the replica's maintenance window. For more information about option groups, seeWorking with option groups.
• You can't remove an RDS for Oracle cross-Region replica from its dedicated option group, which is automatically created for the replica.
• You can't add the dedicated option group for an RDS for Oracle cross-Region replica to a different DB instance.
• You can't add or remove nonreplicated options from a dedicated option group for an RDS for Oracle cross-Region replica, with the exception of the following options:
  • NATIVE_NETWORK_ENCRYPTION
  • OEM
  • OEM_AGENT
  • SSL
    To add other options to an RDS for Oracle cross-Region replica, add them to the source DB instance's option group. The option is also installed on all of the source DB instance's replicas. For licensed options, make sure that there are sufficient licenses for the replicas.
    When you promote an RDS for Oracle cross-Region replica, the promoted replica behaves the same as other Oracle DB instances, including the management of its options. You can promote a replica explicitly or implicitly by deleting its source DB instance.
    For more information about option groups, see Working with option groups.
• You can't add the EFS_INTEGRATION option to RDS for Oracle cross-Region replicas.

Backup and restore considerations for RDS for Oracle replicas

Before you create an RDS for Oracle replica, consider the following:

• To create snapshots of RDS for Oracle replicas or turn on automatic backups, make sure to set the backup retention period manually. Automatic backups aren't turned on by default.
• When you restore a replica backup, you restore to the database time, not the time that the backup was taken. The database time refers to the latest applied transaction time of the data in the backup. The difference is significant because a replica can lag behind the primary for minutes or hours.
  To find the difference, use the describe-db-snapshots command. Compare the snapshotDatabaseTime, which is the database time of the replica backup, and the OriginalSnapshotCreateTime field, which is the latest applied transaction on the primary database.

Oracle Data Guard requirements and limitations for RDS for Oracle replicas

Before you create an RDS for Oracle replica, note the following requirements and limitations:

• If your primary DB instance uses the single-tenant configuration of the multitenant architecture, consider the following:
  • You must use Oracle Database 19c or higher with the Enterprise Edition.
  • Your primary CDB instance must be in an ACTIVE lifecycle.
  • You can't convert a non-CDB primary instance to a CDB instance and convert its replicas in the same operation. Instead, delete the non-CDB replicas, convert the primary DB instance to a CDB, and then create new replicas
• Make sure that a logon trigger on a primary DB instance permits access to theRDS_DATAGUARD user and to any user whoseAUTHENTICATED_IDENTITY value is RDS_DATAGUARD orrdsdb. Also, the trigger must not set the current schema for the RDS_DATAGUARD user.
• To avoid blocking connections from the Data Guard broker process, don't enable restricted sessions. For more information about restricted sessions, see Enabling and disabling restricted sessions.

Miscellaneous considerations for RDS for Oracle replicas

Before you create an RDS for Oracle replica, consider the following:

• If your DB instance is a source for one or more cross-Region replicas, the source DB retains its archived redo log files until they are applied on all cross-Region replicas. The archived redo logs might result in increased storage consumption.
• To avoid disrupting RDS automation, system triggers must permit specific users to log on to the primary and replica database. System triggers include DDL, logon, and database role triggers. We recommend that you add code to your triggers to exclude the users listed in the following sample code:

-- Determine who the user is  
SELECT SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY') INTO CURRENT_USER FROM DUAL;  
-- The following users should always be able to login to either the Primary or Replica  
IF CURRENT_USER IN ('master_user', 'SYS', 'SYSTEM', 'RDS_DATAGUARD', 'rdsdb') THEN  
RETURN;  
END IF;  

• Block change tracking is supported for read-only replicas, but not for mounted replicas. You can change a mounted replica to a read-only replica, and then enable block change tracking. For more information, see Enabling and disabling block change tracking.
• You can't create an Oracle read replica when the source database manages master user credentials with Secrets Manager.