# Working with read replicas for Amazon RDS for Oracle
To configure replication between Oracle DB instances, you can create replica databases. For an overview of Amazon RDS read replicas, see [Overview of Amazon RDS read replicasOverview](USER_ReadRepl.md#USER_ReadRepl.Overview). For a summary of the differences between Oracle replicas and other DB engines, see [Differences between read replicas for DB engines](USER_ReadRepl.Overview.Differences.md).
**Topics**
+ [Overview of RDS for Oracle replicas](oracle-read-replicas.overview.md)
+ [Requirements and considerations for RDS for Oracle replicas](oracle-read-replicas.limitations.md)
+ [Preparing to create an Oracle replica](oracle-read-replicas.Configuration.md)
+ [Creating an RDS for Oracle replica in mounted mode](oracle-read-replicas.creating-in-mounted-mode.md)
+ [Modifying the RDS for Oracle replica mode](oracle-read-replicas.changing-replica-mode.md)
+ [Working with RDS for Oracle replica backups](oracle-read-replicas.backups.md)
+ [Performing an Oracle Data Guard switchover](oracle-replication-switchover.md)
+ [Troubleshooting RDS for Oracle replicas](oracle-read-replicas.troubleshooting.md)
+ [Redo transport compression with RDS for Oracle](oracle-read-replicas.redo-transport-compression.md)
# Overview of RDS for Oracle replicas
An *Oracle replica* database is a physical copy of your primary database. An Oracle replica in read-only mode is called a *read replica*. An Oracle replica in mounted mode is called a *mounted replica*. Oracle Database doesn't permit writes in a replica, but you can promote a replica to make it writable. The promoted read replica has the replicated data to the point when the request was made to promote it.
The following video provides a helpful overview of RDS for Oracle disaster recovery.
[](http://www.youtube.com/watch?v=-XpzhIevwVg)
For more information, see the blog post [Managed disaster recovery with Amazon RDS for Oracle cross-Region automated backups - Part 1](https://aws.amazon.com/blogs/database/managed-disaster-recovery-with-amazon-rds-for-oracle-cross-region-automated-backups-part-1/) and [Managed disaster recovery with Amazon RDS for Oracle cross-Region automated backups - Part 2](https://aws.amazon.com/blogs/database/part-2-managed-disaster-recovery-with-amazon-rds-for-oracle-xrab/).
**Topics**
+ [Read-only and mounted replicas](#oracle-read-replicas.overview.modes)
+ [Read replicas of CDBs](#oracle-read-replicas.overview.data-guard)
+ [Archived redo log retention](#oracle-read-replicas.overview.log-retention)
+ [Outages during Oracle replication](#oracle-read-replicas.overview.outages)
## Read-only and mounted replicas
When creating or modifying an Oracle replica, you can place it in either of the following modes:
Read-only
This is the default. Active Data Guard transmits and applies changes from the source database to all read replica databases.
You can create up to five read replicas from one source DB instance. For general information about read replicas that applies to all DB engines, see [Working with DB instance read replicas](USER_ReadRepl.md). For information about Oracle Data Guard, see [Oracle Data Guard concepts and administration](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/oracle-data-guard-concepts.html#GUID-F78703FB-BD74-4F20-9971-8B37ACC40A65) in the Oracle documentation.
Mounted
In this case, replication uses Oracle Data Guard, but the replica database doesn't accept user connections. The primary use for mounted replicas is cross-Region disaster recovery.
A mounted replica can't serve a read-only workload. The mounted replica deletes archived redo log files after it applies them, regardless of the archived log retention policy.
You can create a combination of mounted and read-only DB replicas for the same source DB instance. You can change a read-only replica to mounted mode, or change a mounted replica to read-only mode. In either case, the Oracle database preserves the archived log retention setting.
## Read replicas of CDBs
RDS for Oracle supports Data Guard read replicas for Oracle Database 19c and 21c CDBs in both single-tenant and multi-tenant configurations. You can create, manage, and promote read replicas in a CDB just as you can in a non-CDB. Mounted replicas are also supported. You get the following benefits:
+ Managed disaster recovery, high availability, and read-only access to your replicas
+ The ability to create read replicas in a different AWS Region.
+ Integration with the existing RDS read replica APIs: [CreateDBInstanceReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html), [PromoteReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplica.html), and [SwitchoverReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverReadReplica.html)
To use this feature, you need an Active Data Guard license and an Oracle Database Enterprise Edition license for both the replica and primary DB instances. There are no additional costs related to using CDB architecture. You pay only for your DB instances.
For more information about the single-tenant and multi-tenant configurations of the CDB architecture, see [Overview of RDS for Oracle CDBs](Oracle.Concepts.CDBs.md).
## Archived redo log retention
If a primary DB instance has no cross-Region read replicas, Amazon RDS for Oracle keeps a minimum of two hours of archived redo logs on the source DB instance. This is true regardless of the setting for `archivelog retention hours` in `rdsadmin.rdsadmin_util.set_configuration`.
RDS purges logs from the source DB instance after two hours or after the archive log retention hours setting has passed, whichever is longer. RDS purges logs from the read replica after the archive log retention hours setting has passed only if they have been successfully applied to the database.
In some cases, a primary DB instance might have one or more cross-Region read replicas. If so, Amazon RDS for Oracle keeps the transaction logs on the source DB instance until they have been transmitted and applied to all cross-Region read replicas. For information about `rdsadmin.rdsadmin_util.set_configuration`, see [Retaining archived redo logs](Appendix.Oracle.CommonDBATasks.RetainRedoLogs.md).
## Outages during Oracle replication
When you create a read replica, Amazon RDS takes a DB snapshot of your source DB instance and begins replication. The source DB instance experiences a very brief I/O suspension when the DB snapshot operation begins. The I/O suspension typically lasts about one second. You can avoid the I/O suspension if the source DB instance is a Multi-AZ deployment, because in that case the snapshot is taken from the secondary DB instance.
The DB snapshot becomes the Oracle replica. Amazon RDS sets the necessary parameters and permissions for the source database and replica without service interruption. Similarly, if you delete a replica, no outage occurs.
# Requirements and considerations for RDS for Oracle replicas
Before creating an Oracle replica, familiarize yourself with the following requirements and considerations.
**Topics**
+ [Version and licensing requirements for RDS for Oracle replicas](#oracle-read-replicas.limitations.versions-and-licenses)
+ [Option group limitations for RDS for Oracle replicas](#oracle-read-replicas.limitations.options)
+ [Backup and restore considerations for RDS for Oracle replicas](#oracle-read-replicas.limitations.backups)
+ [Oracle Data Guard requirements and limitations for RDS for Oracle replicas](#oracle-read-replicas.data-guard.requirements)
+ [Multi-tenant configuration limitations for RDS for Oracle replicas](#oracle-read-replicas.limitations.multitenant)
+ [Miscellaneous considerations for RDS for Oracle replicas](#oracle-read-replicas.limitations.miscellaneous)
## 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](USER_UpgradeDBInstance.Oracle.md).
## 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, see [Working with option groups](USER_WorkingWithOptionGroups.md).
+ 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](USER_WorkingWithOptionGroups.md).
+ 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 or multi-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 the `RDS_DATAGUARD` user and to any user whose `AUTHENTICATED_IDENTITY` value is `RDS_DATAGUARD` or `rdsdb`. 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](Appendix.Oracle.CommonDBATasks.RestrictedSession.md).
## Multi-tenant configuration limitations for RDS for Oracle replicas
When using the multi-tenant configuration on an RDS for Oracle replica, note the following limitations:
+ You can only create, delete, or modify tenant databases on the primary DB instance. These changes automatically propagate to the replicas.
+ Tenant databases on an RDS for Oracle primary, source, or replica cannot be created with a custom character set. If you require a custom character set, create the tenant databases before creating read replicas for the DB instance.
## Miscellaneous considerations for RDS for Oracle replicas
Before you create an RDS for Oracle replica, consider the following:
+ When you are creating an RDS for Oracle replica for a DB instance that has additional storage volumes, RDS automatically configure additional storage volumes on the replica. However, any subsequent modifications made in storage volumes of your primary DB instance are not automatically applied to the replica.
+ If you add additional storage volumes in your primary DB instance, RDS does not automatically add additional storage volumes to the replica. You need to modify your replica to add additional storage volumes.
+ If you modify storage volumes configuration such as storage size and IOPS in your primary DB instance, RDS does not automatically modify storage volumes in the replica. You need to modify your replica to update storage volume configurations.
+ When managing datafile locations across volumes, note that changes made on your primary instance don't automatically sync to replicas.
+ For read-only replicas: You can either use parameter group settings to control default file locations, or manually move files after they're created.
+ For mounted replicas: Manual changes to datafile locations in the primary database require recreating the mounted replica to reflect those changes. To avoid this, we recommend using parameter group settings to manage default file locations.
+ 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](https://docs.oracle.com/en/database/oracle/oracle-database/19/lnpls/plsql-triggers.html#GUID-FE23FCE8-DE36-41EF-80A9-6B4B49E80E5B) 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](Appendix.Oracle.CommonDBATasks.BlockChangeTracking.md).
+ You can't create an Oracle read replica when the source database manages master user credentials with Secrets Manager.
# Preparing to create an Oracle replica
Before you can begin using your replica, perform the following tasks.
**Topics**
+ [Enabling automatic backups](#oracle-read-replicas.configuration.autobackups)
+ [Enabling force logging mode](#oracle-read-replicas.configuration.force-logging)
+ [Changing your logging configuration](#oracle-read-replicas.configuration.logging-config)
+ [Setting the MAX\$1STRING\$1SIZE parameter](#oracle-read-replicas.configuration.string-size)
+ [Planning compute and storage resources](#oracle-read-replicas.configuration.planning-resources)
## Enabling automatic backups
Before a DB instance can serve as a source DB instance, make sure to enable automatic backups on the source DB instance. To learn how to perform this procedure, see [Enabling automated backups](USER_WorkingWithAutomatedBackups.Enabling.md).
## Enabling force logging mode
We recommend that you enable force logging mode. In force logging mode, the Oracle database writes redo records even when `NOLOGGING` is used with data definition language (DDL) statements.
**To enable force logging mode**
1. Log in to your Oracle database using a client tool such as SQL Developer.
1. Enable force logging mode by running the following procedure.
```
exec rdsadmin.rdsadmin_util.force_logging(p_enable => true);
```
For more information about this procedure, see [Setting force logging](Appendix.Oracle.CommonDBATasks.Log.md#Appendix.Oracle.CommonDBATasks.SettingForceLogging).
## Changing your logging configuration
For *n* online redo logs of size *m*, RDS automatically creates *n*\$11 standby logs of size *m* on the primary DB instance and all replicas. Whenever you change the logging configuration on the primary, the changes propagate automatically to the replicas.
If you change your logging configuration, consider the following guidelines:
+ We recommend that you complete the changes before making a DB instance the source for replicas. RDS for Oracle also supports updating the instance after it becomes a source.
+ Before you change the logging configuration on the primary DB instance, check that each replica has enough storage to accommodate the new configuration.
You can modify the logging configuration for a DB instance by using the Amazon RDS procedures `rdsadmin.rdsadmin_util.add_logfile` and `rdsadmin.rdsadmin_util.drop_logfile`. For more information, see [Adding online redo logs](Appendix.Oracle.CommonDBATasks.Log.md#Appendix.Oracle.CommonDBATasks.RedoLogs) and [Dropping online redo logs](Appendix.Oracle.CommonDBATasks.Log.md#Appendix.Oracle.CommonDBATasks.DroppingRedoLogs).
## Setting the MAX\$1STRING\$1SIZE parameter
Before you create an Oracle replica, ensure that the setting of the `MAX_STRING_SIZE` parameter is the same on the source DB instance and the replica. You can do this by associating them with the same parameter group. If you have different parameter groups for the source and the replica, you can set `MAX_STRING_SIZE` to the same value. For more information about setting this parameter, see [Turning on extended data types for a new DB instance](Oracle.Concepts.ExtendedDataTypes.md#Oracle.Concepts.ExtendedDataTypes.CreateDBInstance).
## Planning compute and storage resources
Ensure that the source DB instance and its replicas are sized properly, in terms of compute and storage, to suit their operational load. If a replica reaches compute, network, or storage resource capacity, the replica stops receiving or applying changes from its source. Amazon RDS for Oracle doesn't intervene to mitigate high replica lag between a source DB instance and its replicas. You can modify the storage and CPU resources of a replica independently from its source and other replicas.
# Creating an RDS for Oracle replica in mounted mode
By default, Oracle replicas are read-only. To create a replica in mounted mode, use the console, the AWS CLI, or the RDS API.
## Console
**To create a mounted replica from a source Oracle DB instance**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose the Oracle DB instance that you want to use as the source for a mounted replica.
1. For **Actions**, choose **Create replica**.
1. For **Replica mode**, choose **Mounted**.
1. Choose the settings that you want to use. For **DB instance identifier**, enter a name for the read replica. Adjust other settings as needed.
1. For **Regions**, choose the Region where the mounted replica will be launched.
1. Choose your instance size and storage type. We recommend that you use the same DB instance class and storage type as the source DB instance for the read replica.
1. For **Multi-AZ deployment**, choose **Create a standby instance** to create a standby of your replica in another Availability Zone for failover support for the mounted replica. Creating your mounted replica as a Multi-AZ DB instance is independent of whether the source database is a Multi-AZ DB instance.
1. Choose the other settings that you want to use.
1. Choose **Create replica**.
In the **Databases** page, the mounted replica has the role Replica.
## AWS CLI
To create an Oracle replica in mounted mode, set `--replica-mode` to `mounted` in the AWS CLI command [create-db-instance-read-replica](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance-read-replica.html).
**Example**
For Linux, macOS, or Unix:
```
aws rds create-db-instance-read-replica \
--db-instance-identifier myreadreplica \
--source-db-instance-identifier mydbinstance \
--replica-mode mounted
```
For Windows:
```
aws rds create-db-instance-read-replica ^
--db-instance-identifier myreadreplica ^
--source-db-instance-identifier mydbinstance ^
--replica-mode mounted
```
To change a read-only replica to a mounted state, set `--replica-mode` to `mounted` in the AWS CLI command [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html). To place a mounted replica in read-only mode, set `--replica-mode` to `open-read-only`.
## RDS API
To create an Oracle replica in mounted mode, specify `ReplicaMode=mounted` in the RDS API operation [CreateDBInstanceReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html).
# Modifying the RDS for Oracle replica mode
To change the replica mode of an existing replica, use the console, AWS CLI, or RDS API. When you change to mounted mode, the replica disconnects all active connections. When you change to read-only mode, Amazon RDS initializes Active Data Guard.
The change operation can take a few minutes. During the operation, the DB instance status changes to **modifying**. For more information about status changes, see [Viewing Amazon RDSDB instance status](accessing-monitoring.md#Overview.DBInstance.Status).
## Console
**To change the replica mode of an Oracle replica from mounted to read-only**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose the mounted replica database.
1. Choose **Modify**.
1. For **Replica mode**, choose **Read-only**.
1. Choose the other settings that you want to change.
1. Choose **Continue**.
1. For **Scheduling of modifications**, choose **Apply immediately**.
1. Choose **Modify DB instance**.
## AWS CLI
To change a read replica to mounted mode, set `--replica-mode` to `mounted` in the AWS CLI command [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html). To change a mounted replica to read-only mode, set `--replica-mode` to `open-read-only`.
**Example**
For Linux, macOS, or Unix:
```
aws rds modify-db-instance \
--db-instance-identifier myreadreplica \
--replica-mode mode
```
For Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier myreadreplica ^
--replica-mode mode
```
## RDS API
To change a read-only replica to mounted mode, set `ReplicaMode=mounted` in [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html). To change a mounted replica to read-only mode, set `ReplicaMode=read-only`.
# Working with RDS for Oracle replica backups
You can create and restore backups of an RDS for Oracle replica. Both automatic backups and manual snapshots are supported. For more information, see [Backing up, restoring, and exporting data](CHAP_CommonTasks.BackupRestore.md). The following sections describe the key differences between managing backups of a primary and an RDS for Oracle replica.
## Turning on RDS for Oracle replica backups
An Oracle replica doesn't have automated backups turned on by default. You turn on automated backups by setting the backup retention period to a positive nonzero value.
### Console
**To enable automated backups immediately**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**, and then choose the DB instance or Multi-AZ DB cluster that you want to modify.
1. Choose **Modify**.
1. For **Backup retention period**, choose a positive nonzero value, for example three days.
1. Choose **Continue**.
1. Choose **Apply immediately**.
1. Choose **Modify DB instance** or **Modify cluster** to save your changes and enable automated backups.
### AWS CLI
To enable automated backups, use the AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) or [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) command.
Include the following parameters:
+ `--db-instance-identifier` (or `--db-cluster-identifier` for a Multi-AZ DB cluster)
+ `--backup-retention-period`
+ `--apply-immediately` or `--no-apply-immediately`
In the following example, we enable automated backups by setting the backup retention period to three days. The changes are applied immediately.
**Example**
For Linux, macOS, or Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my_db_instance \
--backup-retention-period 3 \
--apply-immediately
```
For Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier my_db_instance ^
--backup-retention-period 3 ^
--apply-immediately
```
### RDS API
To enable automated backups, use the RDS API [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) or [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) operation with the following required parameters:
+ `DBInstanceIdentifier` or `DBClusterIdentifier`
+ `BackupRetentionPeriod`
## Restoring an RDS for Oracle replica backup
You can restore an Oracle replica backup just as you can restore a backup of the primary instance. For more information, see the following:
+ [Restoring to a DB instance](USER_RestoreFromSnapshot.md)
+ [Restoring a DB instance to a specified time for Amazon RDS](USER_PIT.md)
The main consideration when you restore a replica backup is determining the point in time to which you are restoring. The database time refers to the latest applied transaction time of the data in the backup. When you restore a replica backup, you restore to the database time, not the time when the backup completed. The difference is significant because an RDS for Oracle replica can lag behind the primary by minutes or hours. Thus, the database time of a replica backup, and thus the point in time to which you restore it, might be much earlier than the backup creation time.
To find the difference between database time and creation time, 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. The following example shows the difference between the two times:
```
aws rds describe-db-snapshots \
--db-instance-identifier my-oracle-replica
--db-snapshot-identifier my-replica-snapshot
{
"DBSnapshots": [
{
"DBSnapshotIdentifier": "my-replica-snapshot",
"DBInstanceIdentifier": "my-oracle-replica",
"SnapshotDatabaseTime": "2022-07-26T17:49:44Z",
...
"OriginalSnapshotCreateTime": "2021-07-26T19:49:44Z"
}
]
}
```
# Performing an Oracle Data Guard switchover
A *switchover* is a role reversal between a primary database and a standby database. During a switchover, the original primary database transitions to a standby role, while the original standby database transitions to the primary role.
In an Oracle Data Guard environment, a primary database supports one or more standby databases. You can perform a managed, switchover-based role transition from a primary database to a standby database. A *switchover* is a role reversal between a primary database and a standby database. During a switchover, the original primary database transitions to a standby role, while the original standby database transitions to the primary role.
**Topics**
+ [Overview of Oracle Data Guard switchover](#oracle-replication-switchover.overview)
+ [Requirements for the Oracle Data Guard switchover](oracle-switchover.preparing.md)
+ [Initiating the Oracle Data Guard switchover](oracle-switchover.initiating.md)
+ [Monitoring the Oracle Data Guard switchover](oracle-switchover.monitoring.md)
## Overview of Oracle Data Guard switchover
Amazon RDS supports a fully managed, switchover-based role transition for Oracle Database replicas. You can only initiate a switchover to a standby database that is mounted or open read-only.
The replicas can reside in separate AWS Regions or in different Availability Zones (AZs) of a single Region. All AWS Regions are supported.
![\[Switch over a standby instance to make it the primary DB instance\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/read-replica-switchover.png)
A switchover differs from a read replica promotion. In a switchover, the source and replica DB instances change roles. In a promotion, a read replica becomes a source DB instance, but the source DB instance doesn't become a replica. For more information, see [Promoting a read replica to be a standalone DB instance](USER_ReadRepl.Promote.md).
**Topics**
+ [Benefits of Oracle Data Guard switchover](#oracle-replication-switchover.overview.benefits)
+ [Supported Oracle Database versions](#oracle-replication-switchover.overview.engine-support)
+ [Cost of Oracle Data Guard switchover](#oracle-replication-switchover.overview.cost)
+ [How Oracle Data Guard switchover works](#oracle-replication-switchover.overview.how-it-works)
### Benefits of Oracle Data Guard switchover
Just as for RDS for Oracle read replicas, a managed switchover relies on Oracle Data Guard. The operation is designed to have zero data loss. Amazon RDS automates the following aspects of the switchover:
+ Reverses the roles of your primary database and specified standby database, putting the new standby database in the same state (mounted or read-only) as the original standby
+ Ensures data consistency
+ Maintains your replication configuration after the transition
+ Supports repeated reversals, allowing your new standby database to return to its original primary role
### Supported Oracle Database versions
Oracle Data Guard switchover is supported for Oracle Database 19c and higher releases.
### Cost of Oracle Data Guard switchover
The Oracle Data Guard switchover feature doesn't incur additional costs. Oracle Database Enterprise Edition includes support for standby databases in mounted mode. To open standby databases in read-only mode, you need the Oracle Active Data Guard option.
### How Oracle Data Guard switchover works
Oracle Data Guard switchover is a fully managed operation. You initiate the switchover for a standby database by issuing the CLI command `switchover-read-replica`. Then Amazon RDS modifies the primary and standby roles in your replication configuration.
The *original standby* and *original primary* are the roles that exist before the switchover. The *new standby* and *new primary* are the roles that exist after the switchover. A *bystander replica* is a replica database that serves as a standby database in the Oracle Data Guard environment but is not switching roles.
**Topics**
+ [Stages of the Oracle Data Guard switchover](#oracle-replication-switchover.overview.how-it-works.during-switchover)
+ [After the Oracle Data Guard switchover](#oracle-replication-switchover.overview.how-it-works.after-switchover)
#### Stages of the Oracle Data Guard switchover
To perform the switchover, Amazon RDS must take the following steps:
1. Block new transactions on the original primary database. During the switchover, Amazon RDS interrupts replication for all databases in your Oracle Data Guard configuration. During the switchover, the original primary database can't process write requests.
1. Ship unapplied transactions to the original standby database, and apply them.
1. Restart the new standby database in read-only or mounted mode. The mode depends on the open state of the original standby database before the switchover.
1. Open the new primary database in read/write mode.
#### After the Oracle Data Guard switchover
Amazon RDS switches the roles of the primary and standby database. You are responsible for reconnecting your application and performing any other desired configuration.
**Topics**
+ [Success criteria](#oracle-replication-switchover.overview.how-it-works.after-switchover.success)
+ [Connection to the new primary database](#oracle-replication-switchover.overview.how-it-works.after-switchover.connection)
+ [Configuration of the new primary database](#oracle-replication-switchover.overview.how-it-works.after-switchover.success.configuration)
##### Success criteria
The Oracle Data Guard switchover is successful when the original standby database does the following:
+ Transitions to its role as new primary database
+ Completes its reconfiguration
To limit downtime, your new primary database becomes active as soon as possible. Because Amazon RDS configures bystander replicas asynchronously, these replicas might become active after the original primary database.
##### Connection to the new primary database
Amazon RDS won't propagate your current database connections to the new primary database after the switchover. After the Oracle Data Guard switchover completes, reconnect your application to the new primary database.
##### Configuration of the new primary database
To perform a switchover to the new primary database, Amazon RDS changes the mode of the original standby database to open. The change in role is the only change to the database. Amazon RDS doesn't set up features such as Multi-AZ replication.
If you perform a switchover to a cross-Region replica with different options, the new primary database keeps its own options. Amazon RDS won't migrate the options on the original primary database. If the original primary database had options such as SSL, NNE, OEM, and OEM\$1AGENT, Amazon RDS doesn't propagate them to the new primary database.
# Requirements for the Oracle Data Guard switchover
Before initiating the Oracle Data Guard switchover, make sure that your replication environment meets the following requirements:
+ The original standby database is mounted or open read-only.
+ Automatic backups are enabled on the original standby database.
+ The original primary database and the original standby database are in the `available` state.
+ The original primary database and the original standby database don't have pending maintenance actions in any of the following states: `required`, `next window`, or `in progress`. Actions in these states block switchover. To learn how to check the status of pending maintenance updates, see [Viewing pending maintenance updates](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.Maintenance.Viewing).
Pending maintenance actions in the `available` state don't block switchover. RDS for Oracle frequently releases operating system (OS) updates in the `available` state. These pending OS updates won't block a switchover unless you schedule them for the next maintenance window, which puts them in the `next window` state.
**Note**
If you want to defer a scheduled maintenance action so that you can execute a switchover, choose **Actions** and then **Defer upgrade** in the RDS console. You can also prevent a switchover from being blocked by applying a pending maintenance action or moving the maintenance window to an interval before your switchover. For more information, see the re:Post article [How to remove RDS pending maintenance items](https://repost.aws/questions/QUV3dBjmVVRnmVV1pAlzjx1w/how-to-remove-rds-pending-maintenance-item).
+ The original standby database is in the replicating state.
+ You aren't attempting to initiate a switchover when either the primary database or standby database is currently in a switchover lifecycle. If a replica database is reconfiguring after a switchover, Amazon RDS prevents you from initiating another switchover.
**Note**
A *bystander replica* is a replica in the Oracle Data Guard configuration that isn't the target of the switchover. Bystander replicas can be in any state during the switchover.
+ The original standby database has a configuration that is as close as desired to the original primary database. Assume a scenario where the original primary and original standby databases have different options. After the switchover completes, Amazon RDS doesn't automatically reconfigure the new primary database to have the same options as the original primary database.
+ You configure your desired Multi-AZ deployment before initiating a switchover. Amazon RDS doesn't manage Multi-AZ as part of the switchover. The Multi-AZ deployment remains as it is.
Assume that db\$1maz is the primary database in a Multi-AZ deployment, and db\$1saz is a Single-AZ replica. You initiate a switchover from db\$1maz to db\$1saz. Afterward, db\$1maz is a Multi-AZ replica database, and db\$1saz is a Single-AZ primary database. The new primary database is now unprotected by a Multi-AZ deployment.
+ In preparation for a cross-Region switchover, the primary database doesn't use the same option group as a DB instance outside of the replication configuration. For a cross-Region switchover to succeed, the current primary database and its read replicas must be the only DB instances to use the option group of the current primary database. Otherwise, Amazon RDS prevents the switchover.
# Initiating the Oracle Data Guard switchover
You can switch over an RDS for Oracle read replica to the primary role, and the former primary DB instance to a replica role.
## Console
**To switch over an Oracle read replica to the primary DB role**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the Amazon RDS console, choose **Databases**.
The **Databases** pane appears. Each read replica shows **Replica** in the **Role** column.
1. Choose the read replica that you want to switch over to the primary role.
1. For **Actions**, choose **Switch over replica**.
1. Choose **I acknowledge**. Then choose **Switch over replica**.
1. On the **Databases** page, monitor the progress of the switchover.
![\[Monitor the progress of the Oracle Data Guard switchover.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/oracle-switchover-progress.png)
When the switchover completes, the role of the switchover target changes from **Replica** to **Source**.
![\[The source and replica databases change roles.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/oracle-switchover-complete.png)
## AWS CLI
To switch over an Oracle replica to the primary DB role, use the AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-read-replica.html](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-read-replica.html) command. The following examples make the Oracle replica named *replica-to-be-made-primary* into the new primary database.
**Example**
For Linux, macOS, or Unix:
```
aws rds switchover-read-replica \
--db-instance-identifier replica-to-be-made-primary
```
For Windows:
```
aws rds switchover-read-replica ^
--db-instance-identifier replica-to-be-made-primary
```
## RDS API
To switch over an Oracle replica to the primary DB role, call the Amazon RDS API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverReadReplica.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverReadReplica.html) operation with the required parameter `DBInstanceIdentifier`. This parameter specifies the name of the Oracle replica that you want to assume the primary DB role.
# Monitoring the Oracle Data Guard switchover
To check the status of your instances, use the AWS CLI command `describe-db-instances`. The following command checks the status of the DB instance *orcl2*. This database was a standby database before the switchover, but is the new primary database after the switchover.
```
aws rds describe-db-instances \
--db-instance-identifier orcl2
```
To confirm that the switchover completed successfully, query `V$DATABASE.OPEN_MODE`. Check that the value for the new primary database is `READ WRITE`.
```
SELECT OPEN_MODE FROM V$DATABASE;
```
To look for switchover-related events, use the AWS CLI command `describe-events`. The following example looks for events on the *orcl2* instance.
```
aws rds describe-events \
--source-identifier orcl2 \
--source-type db-instance
```
# Troubleshooting RDS for Oracle replicas
This section describes possible replication problems and solutions.
**Topics**
+ [Monitoring Oracle replication lag](#oracle-read-replicas.troubleshooting.lag)
+ [Troubleshooting Oracle replication failure after adding or modifying triggers](#oracle-read-replicas.troubleshooting.triggers)
## Monitoring Oracle replication lag
To monitor replication lag in Amazon CloudWatch, view the Amazon RDS `ReplicaLag` metric. For more information about replication lag time, see [Monitoring read replication](USER_ReadRepl.Monitoring.md) and [Amazon CloudWatch metrics for Amazon RDS](rds-metrics.md).
For a read replica, if the lag time is too long, query the following views:
+ `V$ARCHIVED_LOG` – Shows which commits have been applied to the read replica.
+ `V$DATAGUARD_STATS` – Shows a detailed breakdown of the components that make up the `ReplicaLag` metric.
+ `V$DATAGUARD_STATUS` – Shows the log output from Oracle's internal replication processes.
For a mounted replica, if the lag time is too long, you can't query the `V$` views. Instead, do the following:
+ Check the `ReplicaLag` metric in CloudWatch.
+ Check the alert log file for the replica in the console. Look for errors in the recovery messages. The messages include the log sequence number, which you can compare to the primary sequence number. For more information, see [Amazon RDS for Oracle database log files](USER_LogAccess.Concepts.Oracle.md).
## Troubleshooting Oracle replication failure after adding or modifying triggers
If you add or modify any triggers, and if replication fails afterward, the problem may be the triggers. Ensure that the trigger excludes the following user accounts, which are required by RDS for replication:
+ User accounts with administrator privileges
+ `SYS`
+ `SYSTEM`
+ `RDS_DATAGUARD`
+ `rdsdb`
For more information, see [Miscellaneous considerations for RDS for Oracle replicas](oracle-read-replicas.limitations.md#oracle-read-replicas.limitations.miscellaneous).
# Redo transport compression with RDS for Oracle
Use RDS for Oracle redo transport compression to improve the replication performance between your primary DB instance and standby replicas. This is particularly useful in environments that have limited network bandwidth or high-latency connections.
## Obtaining a license for redo transport compression
Redo transport compression is part of the [Oracle Advanced Compression](//www.oracle.com/database/advanced-compression/) option. To use redo transport compression, you need a valid license for the Oracle Advanced Compression option. For licensing information, contact your Oracle representative.
## Configuring redo transport compression
To configure redo transport compression, you can use the `rds.replica.redo_compression` parameter. This parameter is available for Oracle versions 19c and 21c.
The `rds.replica.redo_compression` parameter accepts the following values:
+ `DISABLE` – Default value that disables redo transport compression.
+ `ENABLE` – Value that enables redo transport compression through the default algorithm [ZLIB](https://zlib.net/).
+ `ZLIB` – Value that explicitly enables redo transport compression using the ZLIB algorithm, which provides good compression ratios.
+ `LZO` – Value that explicitly enables redo transport compression using the [LZO](https://www.oberhumer.com/opensource/lzo/) algorithm, which optimizes compression speed, particularly during decompression.
## Performance considerations for redo transport compression
Compression and decompression operations consume CPU resources on both the primary and standby instances. If you use redo transport compression, consider instance resource usage and network conditions.
## Related topics for redo transport compression
For more information on configuring redo transport compression, see the following resources:
+ [DB parameter groups for Amazon RDS DB instances](USER_WorkingWithDBInstanceParamGroups.md)
+ [RedoCompression](https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/oracle-data-guard-broker-properties.html#GUID-5E6DDFD0-6196-48EB-94AF-21A1AFBB7DE1) in the Oracle Database 19c release notes