Guidelines and limitations for RDS Custom for Oracle replication

When you create RDS Custom for Oracle replicas, not all RDS Oracle replica options are supported.

General guidelines for RDS Custom for Oracle replication

When working with RDS Custom for Oracle, follow these guidelines:

• You can use RDS Custom for Oracle replication only in Oracle Enterprise Edition. Standard Edition 2 isn't supported.

• Don't modify the RDS_DATAGUARD user. This user is reserved for RDS Custom for Oracle automation. Modifying this user can result in undesired outcomes, such as an inability to create Oracle replicas for your RDS Custom for Oracle DB instance.

• Don't change the replication user password. It is required to administer the Oracle Data Guard configuration on the RDS Custom host. If you change the password, RDS Custom for Oracle might put your Oracle replica outside the support perimeter. For more information, see RDS Custom support perimeter.

  The password is stored in AWS Secrets Manager, tagged with the DB resource ID. Each Oracle replica has its own secret in Secrets Manager. The format for the secret is the following.

  do-not-delete-rds-custom-db-DB_resource_id-6-digit_UUID-dg

• Don't change the DB_UNIQUE_NAME for the primary DB instance. Changing the name causes any restore operation to become stuck.

• Don't specify the clause STANDBYS=NONE in a CREATE PLUGGABLE DATABASE command in an RDS Custom CDB. This way, if a failover occurs, your standby CDB contains all PDBs.

General limitations for RDS Custom for Oracle replication

RDS Custom for Oracle replicas have the following limitations:

• You can't create RDS Custom for Oracle replicas in read-only mode. However, you can manually change the mode of mounted replicas to read-only, and from read-only to mounted. For more information, see the documentation for the create-db-instance-read-replica AWS CLI command.

• You can't create cross-Region RDS Custom for Oracle replicas.

• You can't change the value of the Oracle Data Guard CommunicationTimeout parameter. This parameter is set to 15 seconds for RDS Custom for Oracle DB instances.

Networking requirements and limitations for RDS Custom for Oracle replication

Make sure that your network configuration supports RDS Custom for Oracle replicas. Consider the following:

• Make sure to enable port 1140 for both inbound and outbound communication within your virtual private cloud (VPC) for the primary DB instance and all of its replicas. This is required for Oracle Data Guard communication between read replicas.

• RDS Custom for Oracle validates the network while creating a Oracle replica. If the primary DB instance and the new replica can't connect over the network, RDS Custom for Oracle doesn't create the replica and places it in the INCOMPATIBLE_NETWORK state.

• For external Oracle replicas, such as those you create on Amazon EC2 or on-premises, use another port and listener for Oracle Data Guard replication. Trying to use port 1140 could cause conflicts with RDS Custom automation.

• The /rdsdbdata/config/tnsnames.ora file contains network service names mapped to listener protocol addresses. Note the following requirements and recommendations:

  • Entries in tnsnames.ora prefixed with rds_custom_ are reserved for RDS Custom when handling Oracle replica operations.

    When creating manual entries in tnsnames.ora, don't use this prefix.

  • In some cases, you might want to switch over or fail over manually, or use failover technologies such as Fast-Start Failover (FSFO). If so, make sure to manually synchronize tnsnames.ora entries from the primary DB instance to all of the standby instances. This recommendation applies to both Oracle replicas managed by RDS Custom and to external Oracle replicas.

    RDS Custom automation updates tnsnames.ora entries on only the primary DB instance. Make sure also to synchronize when you add or remove a Oracle replica.

    If you don't synchronize the tnsnames.ora files and switch over or fail over manually, Oracle Data Guard on the primary DB instance might not be able to communicate with the Oracle replicas.

External replica limitations for RDS Custom for Oracle

RDS Custom for Oracle external replicas, which include on-premises replicas, have the following limitations:

• RDS Custom for Oracle doesn't detect instance role changes upon manual failover, such as FSFO, for external Oracle replicas.

  RDS Custom for Oracle does detect changes for managed replicas. The role change is noted in the event log. You can also see the new state by using the describe-db-instances AWS CLI command.

• RDS Custom for Oracle doesn't detect high replication lag for external Oracle replicas.

  RDS Custom for Oracle does detect lag for managed replicas. High replication lag produces the Replication has stopped event. You can also see the replication status by using the describe-db-instances AWS CLI command, but there might be a delay for it to be updated.

• RDS Custom for Oracle doesn't promote external Oracle replicas automatically if you delete your primary DB instance.

  The automatic promotion feature is available only for managed Oracle replicas. For information about promoting Oracle replicas manually, see the white paper Enabling high availability with Data Guard on Amazon RDS Custom for Oracle.

Replica promotion limitations for RDS Custom for Oracle

Promoting RDS Custom for Oracle managed Oracle replicas is the same as promoting RDS managed replicas, with some differences. Note the following limitations for RDS Custom for Oracle replicas:

• You can't promote a replica while RDS Custom for Oracle is backing it up.

• You can't change the backup retention period to 0 when you promote your Oracle replica.

• You can't promote your replica when it isn't in a healthy state.

  If you issue delete-db-instance on the primary DB instance, RDS Custom for Oracle validates that each managed Oracle replica is healthy and available for promotion. A replica might be ineligible for promotion because automation is paused or it is outside the support perimeter. In such cases, RDS Custom for Oracle publishes an event explaining the issue so that you can repair your Oracle replica manually.

Replica promotion guidelines for RDS Custom for Oracle

When promoting a replica, note the following guidelines:

• Don't initiate a failover while RDS Custom for Oracle is promoting your replica. Otherwise, the promotion workflow could become stuck.

• Don't switch over your primary DB instance while RDS Custom for Oracle is promoting your Oracle replica. Otherwise, the promotion workflow could become stuck.

• Don't shut down your primary DB instance while RDS Custom for Oracle is promoting your Oracle replica. Otherwise, the promotion workflow could become stuck.

• Don't try to restart replication with your newly promoted DB instance as a target. After RDS Custom for Oracle promotes your Oracle replica, it becomes a standalone DB instance and no longer has the replica role.

For more information, see Troubleshooting replica promotion for RDS Custom for Oracle.