Use Backup-Based Disaster Recovery

Backup-Based Disaster Recovery provides a lower-cost disaster recovery option for Autonomous Database (the RTO is higher with this option, as compared to using Autonomous Data Guard).

Autonomous Database Disaster Recovery Options

Backup-Based Disaster Recovery uses backups to instantiate a peer database at the time of switchover or failover. For local backup-based disaster recovery, existing local backups are utilized. There are no additional costs for a local Backup-Based Disaster Recovery. Cross-Region Backup-Based Disaster Recovery incurs an additional cost.

Autonomous Data Guard When you add an Autonomous Data Guard standby database, the system creates a standby database that continuously gets updated with the changes from the primary database. You can use Autonomous Data Guard with a standby in the current region, a local standby, or with a standby in a different region, a cross-region standby. You can also use Autonomous Data Guard with both a local standby and a cross-region standby. See Use Standby Databases with Autonomous Data Guard for Disaster Recovery for information about Autonomous Data Guard.

• About Backup-Based Disaster Recovery
  Backup-Based Disaster Recovery uses backups to instantiate a peer database at the time of switchover or failover. This enables you to have a lower cost and higher Recovery Time Objective (RTO) disaster recovery option for your Autonomous Database, as compared with Autonomous Data Guard.
• View Backup-Based Disaster Recovery Peer
  Backup-Based Disaster Recovery with a local peer is enabled by default for a newly created Autonomous Database instance, and for existing databases. A local Backup-Based Disaster Recovery peer does not incur any additional cost.
• Add a Cross-Region Disaster Recovery Peer
  In addition to a local Backup-Based Disaster Recovery peer, you can add a second peer that is a remote (cross-region) Backup-Based Disaster Recovery peer.
• Update Disaster Recovery Type
  Describes the steps to change to an alternative Disaster Recovery option.
• Disable a Cross-Region (Remote) Peer
  Describes the steps to terminate a cross-region (remote) peer.
• Perform a Switchover to a Backup Copy Peer
  When you perform a switchover, the primary database becomes the backup copy and the backup copy becomes the primary database, with no data loss.
• Perform a Failover
  When the primary database goes down, with Backup-Based Disaster Recovery you can perform a manual failover to make the local peer the primary database.
• Convert Cross Region Backup-Based Disaster Recovery Peer to Snapshot Standby
  A cross-region Backup-Based Disaster Recovery peer can be converted to a snapshot standby. This converts the peer to a read-write database for up to two days.
• Use the API
  Provides links for details on using API operations to manage Backup-Based Disaster Recovery.
• Backup-Based Disaster Recovery Events
  You can use Oracle Cloud Infrastructure events to respond when Autonomous Database changes its state due to a Backup-Based Disaster Recovery related event.

About Backup-Based Disaster Recovery

Backup-Based Disaster Recovery uses backups to instantiate a peer database at the time of switchover or failover. This enables you to have a lower cost and higher Recovery Time Objective (RTO) disaster recovery option for your Autonomous Database, as compared with Autonomous Data Guard.

Note:

Backup-Based Disaster Recovery (backup copy) is available in all Autonomous Database workload types. Backup-Based Disaster Recovery is not available with Always Free Autonomous Database.

Backup-Based Disaster Recovery with Local Peer

For local backup-based disaster recovery, existing local backups are utilized. There are no additional costs for local Backup-Based Disaster Recovery.

Description of the illustration backup-based-dr-local.eps

For better resilience for Backup-Based Disaster Recovery, a peer is instantiated as follows:

• In regions with more than one availability domain, a local peer is instantiated in a different availability domain than the primary database.
• In regions with a single availability domain, a local peer is instantiated in a different fault domain than the primary database (that is, on a different physical machine).

All Autonomous Database features from the primary database are available when a peer is instantiated and becomes the primary, after the system fails over or after you perform a switchover operation. See Autonomous Data Guard with Local Standby for more information.

Backup-Based Disaster Recovery with Cross-Region Peer

For backup-based disaster recovery with a cross-region peer, backups are copied to the remote region. Cross-Region Backup-Based Disaster Recovery incurs additional costs.

Description of the illustration backup-based-dr-cross-region.eps

Billing for Backup-Based Disaster Recovery with a cross-region peer:

• ECPU Billing: for cross-region Backup-Based Disaster Recovery with ECPUs, billing is twice (2x) the amount of backup storage required for the replicated cross-region backups, billed to the remote peer.

• OCPU Billing: for cross-region Backup-Based Disaster Recovery with OCPUs, billing is twice (2x) the amount of storage required for backups replicated to the remote region, billed to the remote peer as database storage, rounded up to the nearest TB.

• Backup-Based Disaster Recovery Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
  When you perform a failover using with Backup-Based Disaster Recovery enabled, the peer instance assumes the role of the primary instance, according to the Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

Backup-Based Disaster Recovery Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

When you perform a failover using with Backup-Based Disaster Recovery enabled, the peer instance assumes the role of the primary instance, according to the Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

The RTO is the maximum amount of time required to restore database connectivity to a backup copy database after a failover is initiated. The RPO is the maximum duration of potential data loss, in minutes, on the primary database.

Backup-Based Disaster Recovery RTO and RPO numbers are:

Backup-Based Disaster Recovery Configuration	RTO	RPO
Local backup copy	one (1) hour + 1 hour per 5 TB	10 seconds
Cross-region (remote) backup copy	one (1) hour + 1 hour per 5 TB	1 min

View Backup-Based Disaster Recovery Peer

Backup-Based Disaster Recovery with a local peer is enabled by default for a newly created Autonomous Database instance, and for existing databases. A local Backup-Based Disaster Recovery peer does not incur any additional cost.

Perform the following prerequisite steps as necessary:

• Open the Oracle Cloud Infrastructure Console by clicking the next to Oracle Cloud.

• From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload click one of: Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing.

• On the Autonomous Databases page select your Autonomous Database from the links under the Display Name column.

To view the current Disaster recovery configuration for your Autonomous Database, do the following:

On the Autonomous Database Details page, in the Resources area click Disaster recovery. The DR Type field indicates the type of disaster recovery, either Backup-Based Disaster Recovery (Backup copy) or Autonomous Data Guard.

For example:

Description of the illustration adb_backup_copy_resources.png

Add a Cross-Region Disaster Recovery Peer

In addition to a local Backup-Based Disaster Recovery peer, you can add a second peer that is a remote (cross-region) Backup-Based Disaster Recovery peer.

Perform the following prerequisite steps as necessary:

• Open the Oracle Cloud Infrastructure Console by clicking the next to Oracle Cloud.

• From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload click one of: Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing.

• On the Autonomous Databases page select your Autonomous Database from the links under the Display Name column.

To add a cross-region Backup-Based Disaster Recovery peer, do the following:

1. On the Autonomous Database Details page, under Disaster recovery, in the Cross-region field, click Add peer database link, alternatively in the Resources area click Disaster recovery.
   
   

   
   Description of the illustration adb_bbdr_ui_update.png

   
   

   
   Description of the illustration adb_backup_copy_resources.png
2. Click Add peer database.
3. In the Region drop-down list, select a region.

   The region list shows the available remote regions where you can create a cross-region peer. When you add a peer database, the list of available regions only shows a remote region if your tenancy is subscribed to the remote region (you must be subscribed to the paired remote region). See Autonomous Database Cross-Region Paired Regions for more information.

4. In the Select a compartment drop-down list, select a compartment.
5. Select the disaster recovery type. In addition, when the source database is configured with a private endpoint, enter the private endpoint information for the peer.
   1. Select the disaster recovery type: Backup-based disaster recovery.
      
      Description of the illustration adb_add_backup_peer_select_type.png
   2. When the source database is configured with a private endpoint, in the Network access for standby area enter the Virtual cloud network and the Subnet.
      
      Description of the illustration adb_create_cross_region_peer_private_endpoint.png

      In these Network access for standby fields you specify the private endpoint's VCN and Subnet on the remote region where the standby is created.

      Note:

      If you change your network access on the source database to enable a private endpoint after the standby is created, you must manually access the standby to enable a private endpoint on the peer.
6. Click Add peer database.

   The Autonomous Database Lifecycle State changes to Updating. In the Resources area, the number next to Disaster recovery shows that you now have two peers (2), one local and one remote, and the State field shows Provisioning for the new peer.

   Note:

   While you add a new peer, the primary database is available for read/write operations. There is no downtime on the primary database.

Notes for adding a second peer with Backup-Based Disaster Recovery:

• Autonomous Database generates a work request. To view the work request, under Resources click Work Requests.

• After you add a cross-region (remote) peer, the wallet, and connection string from the primary database will contain only the hostname of the primary database, and the wallet and connection string from the remote database will contain only the hostname of the remote database. This applies to both instance and regional wallets.

  See Cross-Region Disaster Recovery Connection Strings and Wallets for more information.

• When you add a cross region peer there are special considerations when the primary instance is using customer-managed keys, or if you want to switch to use customer-managed keys. See Autonomous Data Guard with Customer Managed Keys for more information.

• While you add a peer with Backup-Based Disaster Recovery when the Lifecycle State field shows Updating, the following actions are disabled for the primary database:

  • Move Resource. See Move an Autonomous Database to a Different Compartment for information on moving an instance.

  • Stop. See Stop Autonomous Database for information on stopping an instance.

  • Restart. See Restart Autonomous Database for information on restarting an instance.

  • Restore. See Restore and Recover your Autonomous Database for information on restoring.

Update Disaster Recovery Type

Describes the steps to change to an alternative Disaster Recovery option.

Backup-Based Disaster Recovery is enabled by default for an Autonomous Database with one local peer. Disaster Recovery cannot be disabled for an Autonomous Database instance. However, you can choose to update your Disaster recovery type to Autonomous Data Guard. See Using Standby Databases with Autonomous Database for Disaster Recovery for more information about Autonomous Data Guard.

To update the Disaster recovery type:

1. On the Primary Autonomous Database, on the Autonomous Database Details page under Resources, select Disaster recovery.
   
   Description of the illustration adb_backup_copy_resources.png
2. In the row showing the database's disaster recovery details, click at the end of the row and select Update disaster recovery type.
3. On the Update disaster recovery type page, choose Autonomous Data Guard.
   
   Description of the illustration adb_update_dr_type_data_guard.png
4. Click Submit. This starts provisioning an Autonomous Data Guard standby database.
5. The disaster recovery type is changed to, Autonomous Data Guard, as shown in the DR Type column.

Disable a Cross-Region (Remote) Peer

Describes the steps to terminate a cross-region (remote) peer.

Perform the following prerequisite steps as necessary:

• Open the Oracle Cloud Infrastructure Console by clicking the next to Oracle Cloud.

• From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload click one of: Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing.

• On the Autonomous Databases page select your Autonomous Database from the links under the Display Name column.

To terminate a cross-region (remote) peer:

1. On the Primary database, on the Autonomous Database Details page under Resources, select Disaster recovery.
2. Access the Oracle Cloud Infrastructure Console for the remote region peer.

   On the Primary database, the Disaster recovery information area shows the Peer Autonomous Database. The remote peer has the same display name as the Primary Database. However, the display name has an "_Remote" extension.

   Under Peer Autonomous Database, click the link for the remote peer to access the cross-region peer.

3. On the Oracle Cloud Infrastructure Console for the remote peer, on the Details page, from the More actions drop-down list, select Terminate.
4. On the Terminate Autonomous Database page, enter the database name to confirm that you want to terminate the cross-region peer.
5. Click Terminate Autonomous Database.

   While the peer is terminating, the Lifecycle State changes to Terminating.

There are limitations for disabling when an instance has a cross-region Backup-Based Disaster Recovery peer, as follows:

• A peer in the remote region cannot be disabled from the primary database.

• When Backup-Based Disaster Recovery is enabled with a cross-region peer, you must terminate the cross-region peer before you terminate the primary role database. If you attempt to terminate the primary, the system gives you an error.

  In this case, after you terminate the cross-region (remote) peer you can terminate the primary database.

Perform a Switchover to a Backup Copy Peer

When you perform a switchover, the primary database becomes the backup copy and the backup copy becomes the primary database, with no data loss.

A switchover is typically done to test failover to the backup copy for audit or certification reasons, or to test your application's failover procedures when you have added a backup copy peer.

For switchover to a backup copy peer, the Autonomous Database Details page, shows the Switchover link under Disaster recovery and the Oracle Cloud Infrastructure Console on the primary database also shows a Switchover link in the Role field when both the primary database and a backup copy peer are available. You can perform a switchover when the primary database Lifecycle State shows Available or Stopped, and a backup copy is available (the State field shows Standby).

To see the peer state, under Resources click Disaster recovery and for the peer listed in the Peer Autonomous Database column, check that the State shows Standby.

Using the Autonomous Database API, you can initiate the switchover operation at any time. See Use the API for more information.

• Perform a Switchover to a Local Backup Copy Peer
  When you perform a switchover the primary database becomes the peer, and the peer becomes the primary database, with no data loss.
• Perform a Switchover to a Cross-Region Backup Copy Peer
  When you perform a switchover, the primary database becomes the peer database and the peer database becomes the primary database, with no data loss.
• Notes for Performing a Switchover to a Backup Copy Peer
  Provides notes for Backup-Based Disaster Recovery switchover:

Perform a Switchover to a Local Backup Copy Peer

When you perform a switchover the primary database becomes the peer, and the peer becomes the primary database, with no data loss.

A switchover is typically done to test failover to the peer for audit or certification reasons or to test your application's failover procedures with Backup-Based Disaster Recovery.

For a switchover to a backup copy, the Autonomous Database Details page, the Oracle Cloud Infrastructure Console on the database with the Primary role shows a Switchover link in the Role field when both the primary database and a peer are available. You can perform a switchover when the primary database Lifecycle State shows Available or Stopped and a peer is available (the State field shows Standby).

To see the peer status, under Resources click Disaster recovery and for the peer listed in the Peer Autonomous Database column, check that the State field shows Standby.

Using the Autonomous Database API, you can initiate the switchover operation at any time. See Use the API for more information.

Perform the following prerequisite steps as necessary:

• Open the Oracle Cloud Infrastructure Console by clicking the next to Oracle Cloud.

• From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload click one of: Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing.

• On the Autonomous Databases page select your Autonomous Database from the links under the Display Name column.

To perform a switchover, do the following:

1. On the Autonomous Database Details page, under Disaster recovery, in the Role field, click Switchover.
   As an alternative, to initiate a switchover you can select More actions and Switchover or select Disaster recovery under Resources and Switchover.
2. In the Confirm switchover to peer dialog, in the Select peer list, choose the peer to switchover.
3. Enter the database name to confirm that you want to switch over.
4. Click Confirm switchover to peer.

   When concurrent operations such as scaling are active, the confirmation also confirms either pausing or canceling the concurrent operation. See Concurrent Operations on Autonomous Database for more information.

   The database Lifecycle State changes to Updating. To see the state of the peer, under Resources, click Disaster recovery where the State column shows Role Change in Progress.

When the switchover completes, Backup-Based Disaster Recovery does the following:

• The Backup-Based Disaster Recovery resource information is updated to reflect the switchover. Select Disaster recovery under Resources to see the updated information.

• Autonomous Database reports the time in the Role Changed On the field.

Perform a Switchover to a Cross-Region Backup Copy Peer

When you perform a switchover, the primary database becomes the peer database and the peer database becomes the primary database, with no data loss.

Note:

For a cross-region switchover you must initiate the switchover from the cross-region peer.

You have several options to access the cross-region peer:

• Select the remote region in Oracle Cloud Infrastructure Console and then access the peer directly.

• Access the primary, and from the primary database you can access the peer from the Autonomous Database Details page by selecting Disaster recovery, under Resources and clicking the link for the backup copy peer in the Peer Autonomous Database column.

To perform a switchover:

1. On the cross-region peer, on the Autonomous Database Details page, under Disaster recovery, in the Role field, click Switchover.

   As an alternative, in the row showing the database's disaster recovery details, click at the end of the row and select Switchover.

2. In the Confirm switchover to peer dialog, enter the peer database name to confirm that you want to switch over.
3. In the Confirm switchover to peer dialog, click Confirm switchover to peer.

   When concurrent operations such as scaling are active, the confirmation also confirms either pausing or canceling the concurrent operation. See Concurrent Operations on Autonomous Database for more information.

   The database Lifecycle State changes to Role change in progress. To see the state of the peer database, under Resources click Disaster recovery. The state State shows Updating.

When the switchover completes, Autonomous Database does the following:

• The display name shows the Primary indicator.

• The Disaster recovery resource information is updated to reflect the switchover. Under Resources select Disaster recovery to see the updated information.

• Autonomous Database reports the time of the last switchover when you hover over the in the Role field.

See Notes for Performing a Switchover for more information.

Notes for Performing a Switchover to a Backup Copy Peer

Provides notes for Backup-Based Disaster Recovery switchover:

• For a cross-region switchover, you must initiate the switchover from the cross-region peer.

• During the switchover, most of the actions on the Oracle Cloud Infrastructure Console are not available and the Autonomous Database Information page shows the Lifecycle State with the value Updating.

• The switchover operation keeps the original state of the Primary database. If the Primary database is stopped when you perform a switchover, the Primary database is stopped after the switchover.

• Autonomous Database generates the Switchover Autonomous Database work request. To view the request, under Resources click Work Requests.

• After a switchover or failover to the peer, the peer becomes the Primary and the graphs on the Database Dashboard card in Database Actions and the Oracle Cloud Infrastructure Metrics display information about the Primary database. The graphs and metrics do not contain information about the database that was the Primary before the switchover or failover operation.

• You cannot cancel a cross-region switchover operation after the switchover begins and the State shows Role change in progress. Your options to cancel the switchover are:

  • Try or retry a switchover or a failover until the operation succeeds.

  • File a service request at Oracle Cloud Support or contact your support representative.

Perform a Failover

When the primary database goes down, with Backup-Based Disaster Recovery you can perform a manual failover to make the local peer the primary database.

Backup-Based Disaster Recovery does not provide an automatic failover option. If you want to provide automatic failover, where the system monitors the primary instance and automatically fails over to a local standby database in certain scenarios, you need to change the disaster recovery type for the local instance to use Autonomous Data Guard.

With both a local Backup-Based Disaster Recovery peer and a cross-region Backup-Based Disaster Recovery peer, Oracle recommends that you attempt a manual failover to the local peer first (not to the cross-region peer).

Depending on how you enable Backup-Based Disaster Recovery, there are different steps to perform a manual failover to a peer:

• When you configure Backup-Based Disaster Recovery with only a local peer:

  When you have a local peer and the switchover is not successful, the Oracle Cloud Infrastructure console shows a banner with information about why the switchover was not successful and the Oracle Cloud Infrastructure console shows a failover link in the Role field that you can click to initiate a failover to the local peer. The failover link only shows when the Primary database is unavailable and a peer is available. That is, the Primary database Lifecycle State field shows Unavailable and the local peer is available. Using the API, you can initiate manual failover at any time. See Use the API for information on using the API.

  To see the peer status, under Resources click Disaster recovery and for the peer listed in the Peer Autonomous Database column check that the State field shows Available or Stopped.

• When you use Backup-Based Disaster Recovery with both a local peer and a cross-region (remote) peer:

  With Backup-Based Disaster Recovery enabled with both a local peer and a cross-region peer, and the local peer is available, Oracle recommends that you attempt a manual failover to the local peer first (not to the cross-region peer).

  If a local peer is unavailable or a manual failover to the local peer fails, you can perform a manual switchover to the cross-region peer. If the switchover to the cross-region peer fails, on the peer the Oracle Cloud Infrastructure console shows a failover link in the Role field that you can click to initiate a manual failover to the peer.

When you initiate a manual failover it is failed over to the peer based on the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets. See Backup-Based Disaster Recovery Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for more information.

Perform the following prerequisite steps as necessary:

• Open the Oracle Cloud Infrastructure Console by clicking the next to Oracle Cloud.

• From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload click one of: Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing.

• On the Autonomous Databases page select your Autonomous Database from the links under the Display Name column.

To initiate a manual failover to a cross-region backup copy, do the following:

1. On the peer, perform a switchover. See Perform a Switchover to a Local Backup Copy Peer for details.

2. If the switchover attempt in Step 1 fails, on the peer the Role field shows a Failover link. On the peer, click the Failover link.

   This shows the Confirm manual failover to peer dialog, along with information on possible data loss that may result if you perform the manual failover to the peer.

3. In the Confirm manual failover to peer dialog, enter the Autonomous Database name to confirm that you want to failover.

4. In the Confirm manual failover to peer dialog, click Confirm manual failover to peer.

   When concurrent operations such as scaling are active, the confirmation also confirms either pausing or canceling the concurrent operation. See Concurrent Operations on Autonomous Database for more information.

To initiate a manual failover when the Primary database is unavailable and the local Peer is available, do the following:

1. On the Details page, under Disaster recovery, in the Role field, click Failover.

   This shows the Confirm manual failover to peer dialog, along with information on possible data loss that may result if you perform the manual failover to peer.

   
   Description of the illustration adb_failover_manual.png
2. In the Confirm manual failover to peer dialog, enter the Autonomous Database name to confirm that you want to failover.
3. In the Confirm manual failover to peer dialog, click Confirm manual failover to peer.

When the failover completes, Backup-Based Disaster Recovery does the following:

• After a manual failover operation completes you can see any data loss associated with the manual failover in the message on the Oracle Cloud Infrastructure console banner and if you hover over the in the Role field. The manual failover data loss is specified in minutes.

• After a manual failover with Backup-Based Disaster Recovery, if there was a regional failure, when the region comes back online the peer is automatically reconnected or if required reprovisioned.

• After you perform a manual failover to the cross-region peer, the cross-region peer becomes the primary database. In this case, if a local Autonomous Data Guard standby was enabled, a local Standby will be created and attached. If a local Autonomous Data Guard was not enabled before the failover in the primary database, as is the default, you have a local backup copy.

Convert Cross Region Backup-Based Disaster Recovery Peer to Snapshot Standby

A cross-region Backup-Based Disaster Recovery peer can be converted to a snapshot standby. This converts the peer to a read-write database for up to two days.

Snapshot standby CPU usage is billed based on the base CPU count and any additional CPU usage if compute auto scaling is enabled. The number of base CPUs is specified by the number of ECPUs (OCPUs if your database uses OCPUs) as shown in the ECPU count or OCPU count field on the Oracle Cloud Infrastructure Console.

Snapshot standby storage usage is billed based on the storage of the snapshot standby plus 1 x the storage of the primary database.

Topics

• About Disaster Recovery Snapshot Standby Databases

• Convert Cross Region Disaster Recovery Peer to a Snapshot Standby

• Convert Snapshot Standby Back to a Cross-Region Disaster Recovery Peer

Use the API

Provides links for details on using API operations to manage Backup-Based Disaster Recovery.

For information about using the API and signing requests, see REST APIs and Security Credentials.

For information about SDKs, see Software Development Kits and Command Line Interface.

Use these API operations to manage Disaster Recovery:

• To enable or disable Backup-Based Disaster Recovery, use UpdateAutonomousDatabase.

• To initiate a manual failover operation, use FailOverAutonomousDatabase.

• To initiate a switchover operation, use SwitchOverAutonomousDatabase.

Use these Terraform APIs to manage Autonomous Database resources:

For information about Terraform, see Terraform Provider and for information about Terraform APIs, see Data Source: oci_database_autonomous_database.

Backup-Based Disaster Recovery Events

You can use Oracle Cloud Infrastructure events to respond when Autonomous Database changes its state due to a Backup-Based Disaster Recovery related event.

Autonomous Database events include the following:

• Begin manual failover
• End manual failover with failover result of success or failure.
• Begin switchover
• End switchover with switchover result of success or failure.

Based on events you can perform actions or send notifications. See Events and Notifications for a Standby Database for more information on using events and producing notifications.