Working with Data Guard Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data.
Using the Console to Manage an Oracle Data Guard group Learn how to enable a Data Guard group between databases, change the role of a database in a Data Guard group using either a switchover or a failover operation, and reinstate a failed database.
About Using Oracle Data Guard with Oracle Exadata Database Service on
Cloud@Customer π
Oracle Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions.
Oracle Data Guard maintains these standby databases as copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Oracle Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Oracle Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability. Oracle Data Guard transport services are also used by other Oracle features such as Oracle Streams and Oracle GoldenGate for efficient and reliable transmission of redo from a source database to one or more remote destinations.
Prerequisites for Using Oracle Data Guard with Oracle Exadata Database Service on
Cloud@Customer π
Review the list of prerequisites for using Data Guard with Oracle Exadata Database Service on
Cloud@Customer.
VM Clusters A VM cluster Data Guard implementation requires two Exadata database VM Clusters, one containing the primary database and one containing the standby database.
Password To change the SYS password or rotate TDE keys, use OCI API.
Adding a Node to a VM Cluster When adding a node to a VM cluster, an instance of the Data Guard database is automatically created on the new node.
Removing a Node from a VM Cluster When removing a node from a VM cluster, the instance and it's metadata on the removing node is deleted automatically.
A VM cluster Data Guard implementation requires two Exadata database VM
Clusters, one containing the primary database and one containing the
standby database.
Note
Oracle strongly recommends the primary and standby databases
for any production workloads be on different Exadata
Cloud Infrastructures for better fault isolation and
disaster protection.
Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data.
The primary and standby databases constitute a Data Guard group. Most of your applications access the primary database. A standby database is a transactionally consistent copy of the primary database.
Data Guard maintains the standby database by transmitting and applying redo data from the primary database. If the primary database becomes unavailable, you can use Data Guard to switchover or failover the standby database to the primary role. This is true even if you have more than one standby database.
Switchover A switchover reverses the primary and standby database roles.
Failover A failover transitions the standby database into the primary role after the existing primary database fails or becomes unreachable.
Reinstate Reinstates a database into the standby role in a Data Guard group.
A switchover reverses the primary and standby database roles.
Each database continues to be part of the Data Guard group in its new role. A switchover ensures no data loss. You can use a switchover before you perform planned maintenance on the primary database. Performing planned maintenance on a Exadata database compute node with a Data Guard group is typically done by switching the primary to the standby role, performing maintenance on the standby, and then switching it back to the primary role.
Reinstates a database into the standby role in a Data Guard group.
You can use the reinstate command to return a failed database into service after correcting the cause of failure.
Note
You cannot terminate a primary database that is part of a Data Guard group that contains one or more standby databases. You will have to terminate the standby databases first. Alternatively, you can switch over the primary database to the standby role, and then terminate the former primary.
You cannot terminate a VM cluster that includes Data Guard enabled databases. You must first terminate the standby databases that are part of the Data Guard group.
Using the Console to Manage an Oracle Data Guard group π
Learn how to enable a Data Guard group between databases, change the role of a database in a Data Guard group using either a switchover or a failover operation, and reinstate a failed database.
When you enable Data Guard, a separate Data Guard group is created between the primary and the standby databases.
Using the Console To Reinstate a Database After you fail over a primary database to its standby, the standby assumes the primary role and the old primary is identified as a disabled standby.
Using the Console to Enable Data Guard on an Oracle Exadata Database Service on
Cloud@Customer System
π
Learn to set up a Data Guard group between databases.
Note
Data Guard relies on a reliable network with sufficient throughput between the primary and standby clusters. Since Oracle does not own the network, some evaluation should be done prior to implementing Data Guard to ensure the required network bandwidth is available. It is recommended that Assessing and Optimizing Network Performance be followed to understand the achievable throughput between the clusters and evaluate whether the requirements of the database are met. By default, the maximum socket buffer size is set to a higher value for cross-region ExaDB-C@C Data Guard configurations.
Note
When you configure a Data Guard group, the primary and standby databases must be on the same major release version while the standby database can be on a higher minor version.
As part of the latest release we are introducing an enhanced user experience and new APIs to improve performance and provide additional Data Guard capabilities including support for multiple standby databases via cloud automation.
With the new API, your new Data Guard configuration will be created as a Data Guard group resource.
If you have an existing Data Guard setup, you can continue to use current capabilities with no impact. However, if you wish to create multiple standby databases, you will need to migrate to the new API model, which can be done at any time.
If you currently have automation that manages Data Guard operations using the existing Data Guard Association API, you will need to update your applications to use the new API to take advantage of these new capabilities
Oracle currently supports both the existing Data Guard Association API and the new Data Guard group API and the associated user interfaces.
Note
A parallel operation on the Standby, if it fails, should be retried after a 5-minute interval.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
VM Clusters is selected by default.
Select your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
In the list of VM clusters, click the VM cluster that contains the database for
which you want to assume the primary role, and then click the name of that
database.
Under Resources, click Data Guard
Associations.
Click Add standby.
On the Add standby page, configure your Data Guard group.
Choose the Data Guard experience:
Use the new Data Guard group Resource With this option, your new Data Guard configuration will be created as a Data Guard group resource. This option with new APIs supports adding multiple standby databases and provides other enhancements. If you currently have automation that manages Data Guard operations using the existing Data Guard Association API, you can update your applications to use the new API to take advantage of these new capabilities.
Use the existing Data Guard Association Resource Choose this option if your automation for managing Data Guard operations relies on the existing Data Guard Association API. However, you will not be able to add multiple standby databases and will not get the enhancements provided by the new API.
Data Guard group details:
Select a Data Guard type, Active Data Guard or Data Guard, based on the Oracle Database software license type you have deployed. If you have deployed Oracle Database Enterprise Edition Extreme Performance (License Included), then you may choose either Data Guard or Active Data Guard. If you have deployed Bring Your Own License (BYOL) Oracle Database Enterprise Edition without the Active Data Guard option, then you would select Data Guard, which is the default.
Active Data Guard: Active Data Guard is a licensed option to the Oracle Database Enterprise Edition and enables advanced capabilities that extend the basic Data Guard functionality. These capabilities include Real-Time Query and DML Offload, Automatic Block Repair of physical data corruptions, Standby Block Change Tracking, Global Data Services, and Application Continuity.
Data Guard: Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as transactionally consistent copies of the production database.
Protection mode: The protection mode used for this Data Guard group.
Maximum Performance provides the highest level of data protection that is possible without affecting the performance of a primary database.
Maximum Availability provides the highest level of protection of data with zero data loss synchronous transport without compromising the availability of the database.
Transport type: The redo transport type used for the Data Guard association between the primary and this standby database.
Async: Asynchronous transport mode used with Maximum Performance protection mode.
Sync: Synchronous transport mode used with Maximum Performance and Maximum Availability protection mode.
Protection Mode and Transport Type:Rules for Standby Database Creation
Creating the first standby: You cannot modify the Protection Mode or Transport Type for the first standby database.
The default settings are:
Protection Mode: Max Performance
Transport Type: Async
Creating the second to Nth standby: You cannot modify the Protection Mode or Transport Type for any subsequent standby databases.
The Protection Mode is inherited from the first standby.
The default Transport Type is set to Async.
Select peer VM cluster: Specify the following values for the standby:
Peer Region: The primary and standby databases could be running on two different VM clusters on a shared ExaDB-C@C system or on two geographically separated ExaDB-C@C systems managed from the same or different Oracle Cloud Infrastructure regions.
Peer Exadata Cloud@Customer infrastructure: Select the Exadata Database Service on Cloud@Customer infrastructure where the standby database is located. Click the CHANGE COMPARTMENT hyperlink to choose a compartment.
Peer VM Cluster: Select the Exadata database compute node that contains the standby database. Click the CHANGE COMPARTMENT hyperlink to choose a compartment.
Choose Database Home: Select an existing Database Home or create one as applicable.
Select an existing Database Home: If one or more Database Homes already exist for the database version you have selected, then this option is selected by default. And, you will be presented with a list of Database Homes. Select a Database Home from the list.
Note
Although only Database homes of the same version and RU are listed, the homes displayed may have different one-off patches than the primary. Though acceptable to have different one-offs, the best practice is to have identical database homes between primary and standby.
Create a new Database Home: If no Database Homes exist for the database version you have selected, then this option is selected by default. You can create the new Database Home with the same DSI as the primary database, or choose a different image. Note that DSIs are not available across regions. A separate DSI must be created in the peer region using the same RU as the primary.
Click Change Database Image to select a database software image for the new Database Home.
In the resulting Browse Database Images, do the following:
Select the compartment containing the database software image you want to use to create the new Database Home.
Select the Oracle Database software version that the new Database Home will use, then choose an image from the list of available images for your selected software version.
Click Select.
Note
If you are using the new Data Guard group resource, you must first create the database home before adding the standby database.
Configure standby database:
Provide a unique name for the database:
Note
You cannot modify the db_name, db_unique_name, and SID prefix after creating the database.
Optionally, specify a unique name for the database. This attribute defines the value of the db_unique_name database parameter. The value is case insensitive. The db_unique_name must contain only the permitted characters.
Review the following guidelines when selecting a database name:
maximum of 30 characters
can contain alphanumeric and underscore (_) characters
begin with an alphabetic character
unique across the fleet/tenancy
If a unique name is not entered, then the db_unique_name defaults to the following format <db_name>_<3 char unique string>_<region-name>.
Database password: Enter the database admin password of the primary database in the Database password field. This same database admin password will be used for the standby.
The admin password and the TDE password must be the same. If they are not, follow the instructions in Changing the Database Passwords to align them.
TDE wallet password: Enter the TDE wallet password.
(Optional) Select Show Advanced Options.
Provide the Oracle SID prefix: Optionally, specify the Oracle SID prefix for the database. The instance number is automatically appended to the SID prefix to become the instance_name database parameter. If not provided, then the SID prefix defaults to the first 12 characters of the db_unique_name.
Review the following guidelines when selecting a database name:
maximum of 12 characters
contain only alphanumeric characters
begin with an alphabetic character
unique in the VM cluster
Click Add standby.
A work request is issued to configure the Data Guard association. The progress of the request and the stages of provisioning can be viewed on the Work Requests page of the respective Standby database.
When the association is created, the details for a database and its peer display their respective roles as Primary or Standby.
Using the Console To Perform a Database
Switchover π
You can initiate a switchover operation on a standby database that is a member of the Data Guard group.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
VM Clusters is selected by default.
Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
In the list of VM clusters, click the VM cluster that contains the primary
database you want to switch over.
Click the name of the primary database.
Under Resources, click Data Guard group.
Select the standby database in the Data Guard group on which you want to perform a switchover. Click the Actions icon (three dots), and then click Switchover.
In the Switchover database dialog box, enter the database admin password, and then click Switchover.
This database should now assume the role of the standby, and the standby should assume the role of the primary in the Data Guard group.
Using the Console To Perform a Database
Failover π
You can initiate a failover operation on a standby database that is a member of the Data Guard group.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
VM Clusters is selected by default.
Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
In the list of VM clusters, click the VM cluster that contains the primary
database's peer standby you want to fail over to.
Click the name of the standby database.
Under Resources, click Data Guard group.
Select the standby database in the Data Guard group on which you want to perform a failover. Click the Actions icon (three dots), and then click Failover.
In the Failover database dialog box, enter the database admin password, and then click Failover.
Note
You can initiate a failover even if the primary database is in a healthy state; however, exercise caution when performing a failover.
This database should now assume the role of the primary, and the old primary's role
should display as Disabled Standby.
After you fail over a primary database to its standby, the standby assumes the primary role and the old primary is identified as a disabled standby.
After you correct the cause of failure, you can reinstate the failed database as a functioning standby for the current primary.
Before you can reinstate a version 12.2 or later database, you must perform some
steps on the database host to stop the database or start it in
MOUNT mode.
Set your ORACLE_UNQNAME environment variable to the
value of the Database Unique Name, and then run these
commands:
srvctl stop database -d db-unique-name -o abort
srvctl start database -d db-unique-name -o mount
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
VM Clusters is selected by default.
Choose your Compartment.
A list of VM Clusters is displayed for the chosen Compartment.
In the list of VM clusters, click the VM cluster that contains the primary database.
Click the name of the primary database.
Under Resources, click Data Guard group.
You will see the database you want to reinstate listed.
Click the Actions icon (three dots), and then click Reinstate.
In the Reinstate database dialog box, enter the database admin password, and then click Reinstate.
This database should now be reinstated as the standby in the Data Guard group.
Perform a failover to transition a standby database
identified by the databaseId parameter into the
specified Data Guard association's primary role after the existing
primary database fails or becomes unreachable.