About Deployment

Deploy the application and database in two Azure AZs for high availability and set up the key management and automated database backup in OCI.

Deploy Application Tier on Azure

MAA solutions require applications to be deployed with redundancy and fault tolerance.

1. Deploy the application tier over at least two AZs. The process and solution to deploy over multiple AZs varies based on Azure services and resources involved. With Azure Kubernetes Service (AKS), you can deploy a private cluster of worker nodes in different AZs. Kubernetes control plane maintains and synchronizes the pods and the workload.
2. See Explore More for Application Checklist for Continuous Service for MAA Solutions, and follow the steps to ensure your applications efficiently reconnect to available primary RAC instances or standby RAC instances during planned maintenance and outage scenarios. These simple configuration best practices include creating a clusterware-managed database service for your application, using an MAA-recommended connect string that is primary- and standby-SCAN aware, enabling Fast Application Notification (FAN) and application draining for graceful application switchover. Following, at a minimum, level 1 and level 2 steps are prerequisites for reducing application service downtime.

Set Up Database Tier on OCI

Oracle Data Guard maintains a standby database by transmitting and applying redo data from the primary database. For planned maintenance or a disaster recovery test, use Oracle Data Guard switchover. If the primary database becomes unavailable, use Oracle Data Guard failover to resume service.

The following steps describe the process to enable Oracle Data Guard across AZs for Oracle Database@Azure by the OCI managed network. OCI is the preferred network for performance (latency, throughput), and no egress or ingress costs are incurred.

When Exadata clusters are created in Azure, each will be in a different OCI Virtual Cloud Network (VCN). For resources in different VCNs to communicate with each other, as is required by Oracle Data Guard, additional steps are required to peer the VCNs and allow the IP address ranges access to each other. Follow these steps to configure that communication between VCNs.

1. Log in to the OCI Console and create a local peering gateway (LPG) in the VCNs of the primary and standby Exadata VM clusters.
2. Establish a peer connection between primary and standby LPG and select the unpeered peer gateway in the standby VCN.

   Note:

   Each VCN can have only one local peering gateway (LPG). A hub VCN will need to be configured if there are multiple databases on a given Exadata VM cluster that will have standby databases on different Exadata VM clusters.
3. Update the default route table to route the traffic between the primary and standby databases via the OCI network without incurring any inbound and outbound data transfer costs.

   Note:

   To update the default route table, you currently need to create a support ticket providing the tenancy name and DRG OCID.
4. Update the primary and standby Network Security Group to create a security rule to allow primary and standby client subnet ingress for TCP port 1521. Optionally, you can add SSH port 22 for direct SSH access to the database servers.
5. Enable Data Guard or Active Data Guard for the primary database. From the Oracle Database details page, click on Data Guard Associations, then on the Enable Data Guard button.
6. On the Enable Data Guard page:
   1. Select the standby availability domain mapped to Azure AZ.
   2. Select the standby Exadata infrastructure.
   3. Select the desired standby VM cluster.
   4. Choose Data Guard or Active Data Guard. MAA recommends Active Data Guard for auto block repair of data corruptions and ability to offload reporting.
   5. Choose a protection mode and redo transport type that satisfies your RTO and RPO.
   6. Select an existing or create a new database home. It's recommended to use the same database software image of the primary database for the standby database home, so both have the same patches available.
   7. Enter the password for the SYS user and enable Data Guard.
   After Data Guard is enabled, the standby database will be listed in the Data Guard Associations section.
7. (Optional) Enable automatic failover (Fast-Start Failover) to reduce the recovery time in case of failures, by installing Data Guard Observer on a separate VM, preferably in a separate location or in the application network. For more information, follow the documentation for Fast-Start Failover, and Configure and Deploy Oracle Data Guard. (These are currently manual steps, and not part of cloud automation.)

About Expected Resolutions with Planned Maintenance and Outages

Using the this playbook's Oracle Data Guard configuration, which includes Oracle RAC databases on Exadata hardware, planned and unplanned outage events can be mitigated.

This table shows outage events and the resolutions that provide data protection.

Event	Resolution
Protection against database instance and hardware failures.	High availability and redundancy provided by ExaDB-D and Oracle RAC.
Planned maintenance: Rolling updates (patching) without downtime.	High availability and redundancy provided by ExaDB-D, Oracle RAC, and cloud automation. See Explore More for Exadata Cloud Database 19c Rolling Upgrade With DBMS_ROLLING (Doc ID 2832235.1).
Planned maintenance: Rolling upgrades with minimal (five minutes) downtime.	Data replication and protection provided by Oracle Data Guard DBMS_ROLLING across AZs.
Protection against database, cluster, and AZ failures.	Data replication and protection provided by Oracle Data Guard across AZs.
AZ data plane site failure.	Data replication and protection provided by Oracle Data Guard across AZs.
Database session interruption during maintenance events and unplanned outages.	See Explore More for incorporating Continuous Availability for Applications best practices.