About Standby Databases

Provides information about enabling and using Autonomous Data Guard for disaster recovery on Autonomous Database.

When you use Autonomous Data Guard, the system creates a standby database that is continuously 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, or you can add both a local and a remote standby.

Note:

Autonomous Data Guard is available with the Data Warehouse and Transaction Processing workload types. Autonomous Data Guard is not available with the JSON and APEX workload types.

By selecting from the disaster recovery options that Autonomous Database provides, you can choose the features and options that meet your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) requirements

By default, each Autonomous Database instance provides a local Backup-Based Disaster Recovery peer database.

To add automatic failover and to lower your Recovery Time Objective (RTO), you can use a local Autonomous Data Guard standby database.

To use the most resilient disaster recovery option that Autonomous Database offers, you can use a local Autonomous Data Guard standby database and a cross-region Autonomous Data Guard standby.

In addition, other options using Backup-Based Disaster Recovery enable you to provide lower cost and higher Recovery Time Objective (RTO) disaster recovery options, as compared to Autonomous Data Guard. See Use Backup-Based Disaster Recovery for details on Backup-Based Disaster Recovery.

Autonomous Data Guard with Local Standby
When you use an Autonomous Data Guard standby database in the current region, Autonomous Database provisions a local standby database and monitors the primary database; if the primary database goes down, the standby instance automatically assumes the role of the primary instance.
Autonomous Data Guard with Cross-Region Standby
When you add a standby database in a different region, if the primary instance goes down, Autonomous Data Guard provides a standby database that is physically separated in a remote region. The standby database is available to assume the role of the unavailable primary instance.
Autonomous Data Guard Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
Autonomous Data Guard monitors the primary database and if the instance goes down, the local standby instance assumes the role of the primary instance, according to the Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
Autonomous Data Guard Operations
Autonomous Database provides the following operations with Autonomous Data Guard:
Autonomous Database Disaster Recovery Status
Autonomous Database provides information about disaster recovery status on the Autonomous Database Details page.
Autonomous Data Guard Events
You can use Oracle Cloud Infrastructure events to respond when Autonomous Database changes its state due to an Autonomous Data Guard related event such as a failover or switchover operation.

Parent topic: Use Standby Databases with Autonomous Data Guard for Disaster Recovery

Autonomous Data Guard with Local Standby

When you use an Autonomous Data Guard standby database in the current region, Autonomous Database provisions a local standby database and monitors the primary database; if the primary database goes down, the standby instance automatically assumes the role of the primary instance.

Local Autonomous Data Guard peer databases incur the additional cost of the base CPUs and the storage of the Primary database, including any auto-scaled storage usage, billed on the Primary database itself. Auto-scaled CPUs of the Primary database are not billed for additionally on the local Autonomous Data Guard peer database. 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.

With a local standby database, Autonomous Data Guard provides an identical standby database that allows the following, depending on the state of the primary database:

If your primary database goes down, Autonomous Data Guard converts the standby database to the primary database with minimal interruption. After failover completes, Autonomous Data Guard creates a new standby database for you.
You can perform a switchover operation, where the primary database becomes the standby database, and the standby database becomes the primary database.

Autonomous Database does not provide access to a standby database in the current region. You perform all operations, such as scaling up the ECPU count (OCPU count if your database uses OCPUs) and enabling compute auto scaling on the primary database, and Autonomous Data Guard then performs the same actions on the local standby database. Likewise, you only perform actions such as stopping or restarting the database on the primary database.

A local standby database is created in the same region as the primary database (current region). For better resilience, the standby database is provisioned as follows:

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

See Regions and Availability Domains for more information on availability domains.

All Autonomous Database features from the primary database are available when the local standby instance becomes the primary, after the system fails over or after you perform a switchover operation, including the following:

Database Options: The ECPU count (OCPU count if your database uses OCPUs), Storage, Display Name, Database Name, Auto Scaling, Tags, and Licensing options have the same values after a failover to the standby database or after you perform a switchover.
OML Notebooks: Notebooks and users created in the primary database are available in the standby.
APEX Data and Metadata: APEX information created in the primary database is copied to the standby.
ACLs: The Access Control List (ACL) of the primary database is duplicated for the standby.
Private Endpoint: The private endpoint from the primary database applies to the standby.
APIs or Scripts: Any APIs or scripts you use to manage the Autonomous Database continue to work without any changes after a failover operation or after you perform a switchover.
Client Application Connections: Client applications do not need to change their connection strings to connect to the database after a failover to the standby database or after you perform a switchover.
Wallet Based Connections: You can continue using your existing wallets to connect to the database after a failover to the standby database or after you perform a switchover.

Parent topic: About Standby Databases

Autonomous Data Guard with Cross-Region Standby

When you add a standby database in a different region, if the primary instance goes down, Autonomous Data Guard provides a standby database that is physically separated in a remote region. The standby database is available to assume the role of the unavailable primary instance.

A cross-region standby database is a replica of the primary database and may be used for recovery in case of failure or when the primary is not available. Enabling Autonomous Data Guard with a cross-region standby provides a low RTO solution for disaster recovery in the event an entire region is not available or when the primary database is down for any reason.

Autonomous Data Guard cross-region standby databases incur the additional cost of the base CPUs and twice the storage of the Primary database, including any auto-scaled storage usage, billed on the remote peer database. Auto-scaled CPUs of the Primary are not billed for additionally on the remote peer database. The number of base CPUs is specified by the number of ECPUs (OCPUs if your database uses OCPUs) as shown in the ECPU count (OCPU count) field on the Oracle Cloud Infrastructure Console.

Autonomous Data Guard allows you to create one remote standby database in a paired region. Paired regions are remote regions where you can create a cross-region standby database. See Autonomous Database Cross-Region Paired Regions for more information on paired regions.

You perform almost all operations, such as scaling up the ECPU count (OCPU count if your database uses OCPUs) and enabling compute auto scaling on the primary database. Autonomous Data Guard then performs the same actions on the cross-region standby database.

After you add a remote standby database, Autonomous Database provides access to the remote standby database from the Oracle Cloud Infrastructure Console. Autonomous Database provides access to the remote standby database so that you can perform some operations independently on the remote standby, such as configuring networks and VCNs for private endpoints and adding tagging to define keys and values that are not replicated between the primary database and the remote standby.

Note:

Autonomous Data Guard does not perform automatic failover for a cross-region standby. If the primary database is unavailable and a local standby is unavailable, you can perform a manual failover to make the standby database assume the primary role.

You cannot connect to a cross-region standby while the it operates as a standby database, and it is not available for read-only operations. You can connect to the database in the following cases:

When the database assumes the primary role after a failover or switchover operation. See Perform a Switchoverand Perform a Manual Failover for more information.
After you convert the standby database to a snapshot standby database. See Convert Cross Region Disaster Recovery Peer to a Snapshot Standby for more information.

The following areas have differences for failover or switchover from the primary database to the remote standby database, when compared to failover or switchover to a local standby:

Display Name: The display name has a "_Remote" extension.
OML Notebooks: After a cross-region switchover or failover, OML notebooks from primary that was switched over or failed over are not present in the primary database (the current primary database after the role change). New OML notebooks can be created.
Private Endpoint: You can independently configure and update private endpoints on the standby database before failover or before you perform a switchover. This allows you to have a private endpoint that is configured differently, after failover or after you perform a switchover. Autonomous Database does not keep the networking configuration synchronized from the primary to the standby.

VCN Peering and domain forwarding are required for wallets to work across regions, with Autonomous Databases with a private endpoint with an Autonomous Data Guard standby, where the primary and the standby database are in different VCNs. See Remote VCN Peering using an RPC and DNS in Your Virtual Cloud Network for information on VCN peering and domain forwarding.
APIs or Scripts: Any APIs or scripts you use to manage the Autonomous Database need to be updated to call the APIs on the primary database, the current primary database, after a failover or after you perform a switchover.

For mTLS connections, you must download a wallet from the primary database, the current primary database, after a failover or after you perform a switchover. See Cross-Region Disaster Recovery Connection Strings and Wallets for more information.
Client Applications: Client applications need to connect using the connection strings and wallet you download from the primary database, the current primary database, after a failover or after you perform a switchover. See Cross-Region Disaster Recovery Connection Strings and Wallets for more information.
Wallet Based Connections: You must download a wallet and connect using the connection strings from the primary database, the current primary database, to connect to the database after a failover or after you perform a switchover. See Cross-Region Disaster Recovery Connection Strings and Wallets for more information.
Autonomous Database Tools: The tools have different URLs in the primary database, the current primary database, after a failover or after you perform a switchover (the tools URLs do not change for a switchover or failover to a local standby):
- Database Actions
- Oracle APEX
- Oracle REST Data Services (ORDS)
- Graph Studio
- Oracle Machine Learning Notebooks
- Data Transforms
- MongoDB API
Oracle Cloud Infrastructure Object Storage Usage: After you failover or switchover from the primary database to the standby database, on the primary database (the current primary database) the credentials and the URLs that provide access to Object Storage continue to work as they did before the failover or the switchover, providing access to the following:
- External tables
- External partitioned tables
- External hybrid partitioned tables
Note:
This applies when the Object Storage is available. For rare scenarios when the Object Storage is not available, Oracle recommends having Object Storage backups or replication to a different region. If the Object Storage is not available (that is the Object Storage resource you used with the Primary before a switchover or failover), you may update your user credentials and parameters that set URLs for Object Storage so that the parameters specify values to access an available region's Object Storage. See Using Replication for more information.

Autonomous Data Guard Database Role
After you add a cross-region standby database, each database has a designated role: primary, standby, or snapshot standby.
Autonomous Data Guard Cross Region Failover and Switchover
You can have one local disaster recovery peer and optionally you can add one cross-region peer. In both the local and cross-region cases, either peer can be a Backup-Based Disaster Recovery copy or an Autonomous Data Guard standby.
Autonomous Data Guard Database Cross Region Backup and Restore
After you add an Autonomous Data Guard cross-region standby database, backup and restore from backup is handled as follows:
Cross-Region Disaster Recovery Connection Strings and Wallets
When you add an Autonomous Data Guard cross-region (remote) standby database, or when you use a cross-region Backup-Based Disaster Recovery peer, the wallet and connection string from the primary database contains only the hostname of the primary database.
Autonomous Data Guard with Customer Managed Keys
When you add an Autonomous Data Guard cross-region standby, there are special considerations when the primary database is using customer-managed keys, or if you want to switch to using customer-managed keys on the primary database.
Replicating Backups to a Cross-Region Autonomous Data Guard Standby
When you add a cross-region Autonomous Data Guard standby you can enable cross-region backup replication so that automatic backups from the primary are also available on the remote region.

Parent topic: About Standby Databases

Autonomous Data Guard Database Role

After you add a cross-region standby database, each database has a designated role: primary, standby, or snapshot standby.

The role specifies the current state of a database, primary, standby, or snapshot standby, and this value changes after you perform a switchover or a failover or after you convert a standby database to a snapshot standby. You can view the Autonomous Database role in the icon that shows next to the display name on the Autonomous Database Information page. For example:

Description of the illustration adb_adg_primary.png

Description of the illustration adb_adg_standby.png

After you add a cross-region standby database, you can view the role in the Disaster recovery area on the details page. The role is one of:

The Role shows Primary on the primary database.
After a switchover or failover, the same database shows the Role Standby.
After you convert a cross-region peer to a snapshot standby, the database shows the Role Snapshot Standby.

To view details for the peer, on the Autonomous Database Information page, under Resources select Disaster recovery:

Standby (local): the Peer role column shows Standby and the database has the same display name in the Peer Autonomous Database column. The Region column shows the name of the current region.
Standby (cross-region) the Peer role column shows Standby for a remote standby database and the database has the same with an "_Remote" extension in the Peer Autonomous Database column. You can click the link to access the remote database. The Region column shows the name of the remote region.
Snapshot standby (local): the Peer role column shows Snapshot standby and the database has the same display name in the Peer Autonomous Database column. The Region column shows the name of the remote region.

Description of adb_data_guard_resources.png follows

Description of the illustration adb_data_guard_resources.png

Parent topic: Autonomous Data Guard with Cross-Region Standby

Autonomous Data Guard Cross Region Failover and Switchover

You can have one local disaster recovery peer and optionally you can add one cross-region peer. In both the local and cross-region cases, either peer can be a Backup-Based Disaster Recovery copy or an Autonomous Data Guard standby.

With both a current region and a cross-region Autonomous Data Guard standby database, depending on the state of the primary database, you have the following options:

If your primary database goes down and the local standby database is available, Autonomous Data Guard automatically performs failover to convert the local standby database to the primary database, with minimal interruption. After failover completes, Autonomous Data Guard creates a new local standby database for you. If automatic failover is not possible, you have the option to perform a manual failover.

Autonomous Data Guard continues to use the same cross-region standby.
If your primary database goes down and the local standby database is not available, you can perform a manual failover to the cross-region standby database and the cross-region standby database becomes the primary database.

In this case, after the failover completes, Autonomous Data Guard does not create a new local standby database (by default you have a backup copy peer).
You can perform a switchover operation, where the primary database becomes the local standby database, and the local standby database becomes the primary database.

Autonomous Data Guard continues to use the same cross-region standby.
You can perform a switchover operation, where the cross-region standby database becomes the primary database (and the database that was the primary is recreated as a new standby database so that it becomes the standby database).

A switchover changes the roles of the primary and the standby database. If you perform a switchover two times, the primary database returns to again be the primary database.

Parent topic: Autonomous Data Guard with Cross-Region Standby

Autonomous Data Guard Database Cross Region Backup and Restore

After you add an Autonomous Data Guard cross-region standby database, backup and restore from backup is handled as follows:

If the primary database is restored from a backup, a new remote standby is created from the restored primary database.
Automatic Backups are only taken on the primary database (the database showing Role: Primary). For example, after a switchover or failover, the database with the primary role starts to perform automatic backups. The database with the standby role no longer takes backups. If you switchover again, the database that becomes the primary role database starts taking backups again.
You cannot restore or clone from a backup when either the primary database or the standby database is in the Standby role. Backups are only taken on the database in the Primary role, and the restore operation is not available from the Oracle Cloud Infrastructure Console on the Standby database.

Parent topic: Autonomous Data Guard with Cross-Region Standby

Cross-Region Disaster Recovery Connection Strings and Wallets

When you add an Autonomous Data Guard cross-region (remote) standby database, or when you use a cross-region Backup-Based Disaster Recovery peer, the wallet and connection string from the primary database contains only the hostname of the primary database.

In addition, the wallet and connection string from the remote database contains only the hostname of the remote database. This applies for both instance and regional wallets.

Oracle recommends that you configure your applications running on the Primary Role database to use the wallet or connection string downloaded from the Primary database. For applications that run on the remote database, use the wallet or connection string downloaded from the remote database (where the remote database is the current primary database after a failover or after you perform a switchover). You can obtain these connection strings or the wallet by clicking Database connection on the Oracle Cloud Infrastructure Console.

For example, if your cross-region Autonomous Data Guard is setup with the primary in Ashburn (IAD) and a cross-region standby in Phoenix (PHX), Oracle recommends that your mid-tier applications running in IAD use the connection string or wallet from the primary database in IAD, and your corresponding applications that run in PHX after a failover or after you perform a switchover, use the connection string or wallet from the standby database in PHX. During regional failover or switchover, Oracle recommends failing over both your database and your mid-tier applications to the new Primary role database for optimum performance and to minimize any cross-regional latency.

See Download Client Credentials (Wallets) for more information.

If required by your application, you may manually construct connection strings containing both primary and remote database hostnames, to support connecting to either instance that is available and open for connections automatically, the primary or the remote database.

For details on the steps to manually create these connection strings see:

Parent topic: Autonomous Data Guard with Cross-Region Standby

Autonomous Data Guard with Customer Managed Keys

When you add an Autonomous Data Guard cross-region standby, there are special considerations when the primary database is using customer-managed keys, or if you want to switch to using customer-managed keys on the primary database.

In order for a remote standby to be able to use the same master encryption key as the primary database, the master encryption key must be replicated to the remote region. Replication of vaults and keys across regions is only possible if you select the virtual private vault option when you create the vault.

Consider the following cases:

Adding an Autonomous Data Guard remote standby is allowed if the Autonomous Database is using customer-managed keys. When the database is using a customer-managed key and you add an Autonomous Data Guard cross-region standby, the Region list in the Add peer database dialog only shows the regions that contain the replicated vault and keys. If you don't see a remote region listed, you need to replicate your vault and keys to the region where you want your standby database (this must be a paired region).
Switching to customer-managed keys is allowed on the primary when you have an Autonomous Data Guard cross-region standby. In the case when the database is using Oracle-managed keys and you switch to customer-managed keys on the primary, you only see the keys that are replicated in both the primary and the standby regions. The Manage Encryption Key Vault and Master encryption key lists only show vaults and keys that are replicated across both the primary and the standby regions. If you don't see a key listed, replicate your vault and keys to a paired region.

See the following for more information:

Parent topic: Autonomous Data Guard with Cross-Region Standby

Replicating Backups to a Cross-Region Autonomous Data Guard Standby

When you add a cross-region Autonomous Data Guard standby you can enable cross-region backup replication so that automatic backups from the primary are also available on the remote region.

By default the backups taken on the primary are not replicated to a cross-region standby database. When you enable cross-region backup replication, up to 7 days of automatic backups for the primary are replicated to a cross-region standby database. When this feature is enabled, automatic backups are available in the remote region as follows:

After a switchover or failover you can restore or clone to any timestamp in the past seven (7) days, or to any timestamp in the specified retention period when the retention period is set to less than seven days.
All backups for the primary that are replicated to the remote region are deleted on the remote region peer after seven days, or after the retention period number of days when the retention period is set to less than seven days.
You cannot modify the backup retention period for replicated backups, except if you modify the backup retention period on the primary to specify a value less than seven days. In this case, the retention period for replicated backups on the remote region matches the automatic backup retention period set on the primary.

Cross-region backup replication incurs an additional cost. See Oracle Autonomous Database Serverless Features Billing for more information.

See Add a Cross-Region Standby Database and Enable or Disable Backup Replication for an Existing Cross Region Standby for more information.

Note the following for cross-region automatic backup replication:

After a switchover or a failover, while the cross-region database is in the primary role, backups are taken on the current primary and are replicated to the current (remote) standby.
In the remote region you can create a clone from a replicated backup while the database is in the standby role.

Parent topic: Autonomous Data Guard with Cross-Region Standby

Autonomous Data Guard Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

Autonomous Data Guard monitors the primary database and if the instance goes down, the local standby instance assumes the role of the primary instance, according to the Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

If a local Autonomous Data Guard standby instance is not available and you have enabled cross-region disaster recovery, you can manually fail over to the cross-region standby.

If you do not add a cross-region Autonomous Data Guard standby, you have the option to add a cross-region Backup-Based Disaster Recovery peer. See Backup-Based Disaster Recovery Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for details on the RTO and RPO with Backup-Based Disaster Recovery.

The RTO is the maximum amount of time required to restore database connectivity to a standby database after a manual or automatic failover is initiated. The RPO is the maximum duration of potential data loss on the primary database.

Local Autonomous Data Guard Standby

When you add a local standby database Autonomous Data Guard provides these options for failover or switchover:

Automatic Failover or Switchover:

When you enable Autonomous Data Guard you can select a data loss limit. The default data loss limit for automatic failover is 0 (valid values are 0 to 3600 seconds). For example, a data loss limit of 0 means that Autonomous Data Guard only performs automatic failover when there is no data loss. This means if Autonomous Data Guard can verify that there is no data loss, it automatically fails over in case of a problem. When there is a problem and Autonomous Data Guard determines that the possible data loss is greater than the data loss limit, automatic failover does not happen and you have the option to perform a manual failover.
Manual Failover: the RTO is two (2) minutes and the RPO 10 seconds

Cross-Region Autonomous Data Guard Standby

When you add a cross-region standby database, the RTO and RPO numbers for failover to the Autonomous Data Guard cross-region standby are as follows:

Switchover: the RTO is fifteen (15) minutes and RPO is zero (0).
Automatic Failover: Not available
Manual Failover: the RTO is fifteen (15) minutes and RPO is up to one (1) minute.

See the following for more information:

Automatic Failover with a Standby Database for details on automatic failover.
Perform a Switchover
Perform a Manual Failover
Service Level Objectives (SLOs)

Parent topic: About Standby Databases

Autonomous Data Guard Operations

Autonomous Database provides the following operations with Autonomous Data Guard:

Enable: If you are using Backup-Based Disaster Recovery, you can update your disaster recovery type to local (current region) Autonomous Data Guard, or you can add an Autonomous Data Guard cross-region standby.

See Enable Autonomous Data Guard and Add a Cross-Region Standby Database for details.
Disable: If you have a local standby database or a cross-region standby database, you can change the disaster recovery type to Backup-Based Disaster Recovery for the local standby or you terminate the cross-region standby. In either case, disabling Autonomous Data Guard terminates the standby database.

See Update Standby to Use a Backup Copy Peer or Disable a Cross Region Standby Database for details.
Switchover: When Autonomous Data Guard is enabled, switchover changes the roles of the primary and the standby, the standby database becomes the primary, and the primary database becomes the standby. If you have both a local standby database (current region), and a cross-region standby database (remote), you can choose to switchover to either the local standby or the remote standby.

See Perform a Switchover for details.
Manual Failover: If the primary database is not available you can perform a manual failover to change roles to make a standby database the primary database:
- If a local standby is available, you can manually failover to the local standby (you do not have the option to failover to a remote standby if a local standby is available).
- If a local standby is not available, you have the option to manually failover to a remote standby.
See Perform a Manual Failover for details.
Terminate: If you want to terminate the primary instance, select More actions and Terminate. Terminating the primary instance also terminates a local standby database.

If you have both a local standby database (current region), and a cross-region standby database, you must terminate the cross-region standby database before you terminate the primary database.

See Terminate a Cross-Region Standby Database for details.

Parent topic: About Standby Databases

Autonomous Database Disaster Recovery Status

Autonomous Database provides information about disaster recovery status on the Autonomous Database Details page.

In the Disaster recovery area:

The Role field shows the role of the current database, as follows:

When you have either a local backup copy peer or a local Autonomous Data Guard standby, the Oracle Cloud Infrastructure Console shows the Role field value Primary. Autonomous Database does not provide access to a local standby database (or to a local backup copy peer).
When using either a cross-region backup copy peer or a cross-region Autonomous Data Guard standby, the Oracle Cloud Infrastructure Console shows the Role field value Primary if you are viewing the primary database and shows Standby if you are viewing the details for the standby database.
Switchover: Provides a link so that you can perform a switchover operation.
Failover: When the primary database is not available and you have a local standby and automatic failover was not successful, the failover link allows you initiate a manual failover.

When the primary database is not available and you have a cross-region standby and failover to a local standby is not possible, the failover link allows you initiate a manual failover to the remote standby database.

To view the peer Autonomous Database information, under Resources click Disaster recovery. This area lists the peer autonomous database information. The State column shows the state of a standby database, as follows:

Provisioning
- This state shows when you enable Autonomous Data Guard and indicates that a standby database is provisioning (until the standby database state changes to Standby).
- This state shows after a failover to a local standby when a local standby database is being recreated.
- This state shows if a restore from backup operation is performed on the primary database, the local standby is recreated and the State column shows Provisioning.
Standby: Indicates that a standby is available and ready for either a switchover or a failover operation.

Note:
When the standby database is stopped, the standby state shows Standby. A standby database never shows the Stopped state.
Role Change in Progress: Indicates a failover or switchover operation started.

Parent topic: About Standby Databases

Autonomous Data Guard Events

You can use Oracle Cloud Infrastructure events to respond when Autonomous Database changes its state due to an Autonomous Data Guard related event such as a failover or switchover operation.

Autonomous Database events include the following:

Begin automatic failover
End automatic failover
Begin disable Autonomous Data Guard
Begin enable Autonomous Data Guard
Begin failover
Begin switchover
End disable Autonomous Data Guard
End enable Autonomous Data Guard
End failover with failover result of success or failure.
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.

Parent topic: About Standby Databases