Plan High Availability for Databases
The Oracle Cloud Infrastructure Database service lets you quickly launch an Oracle Database System (DB System) and create one or more databases on it. The Database service supports several types of DB Systems, ranging in size, price, and performance.
- Use these key tools: Exadata Database systems, 2-Node RAC DB Systems, and Data Guard.
- Configure your CPU and storage layer to scale automatically.
Use Exadata Database Systems
Exadata Database Systems allow you to leverage the power of Exadata within the Oracle Cloud Infrastructure.
An Exadata Database System consists of a quarter rack, half rack, or full rack of Compute nodes and storage servers, tied together by a high-speed, low-latency InfiniBand network and intelligent Exadata software. You can configure automatic backups, optimize for different workloads, and scale up the system to meet increased demands.
Exadata DB systems provide built-in high availability capabilities. All the existing best practices with your on-premises Exadata DB systems are applicable.
Use 2-Node RAC DB Systems
Oracle Cloud Infrastructure offers 2-node RAC DB Systems on virtual machine Compute instances. 2-node RAC DB systems provide built-in high availability capabilities, so we recommend using 2-node RAC DB Systems for your solutions that require high availability.
You can configure the Database service to automatically back up to Oracle Cloud Infrastructure Object Storage. The following diagram shows the deployment of a 2-node RAC DB System to support the high availability of a three-tier web application:
Description of the illustration rac-db.png
Note:
The architecture shows multiple availability domains (ADs). For a region that has a single AD, adjust the architecture to distribute your resources across the fault domains within the AD.Use Data Guard
For solutions with a single-node DB system, use Oracle Data Guard to achieve high availability. Data Guard ensures high availability, data protection, and disaster recovery for enterprise data.
Implementation of Data Guard in the Oracle Cloud Infrastructure Database service requires two databases, one in a primary role and one in a standby role. The two databases compose a Data Guard association. Most of your applications access the primary database. The standby database is a transactional consistent copy of the primary database. To improve availability and disaster recovery, we recommend placing the DB System of the standby database in a different availability domain from the DB System of the primary database. The high-performance network between Oracle Cloud Infrastructure availability domains enables this deployment.
Description of the illustration db-dg.png
Note:
The architecture shows multiple availability domains (ADs). For a region that has a single AD, adjust the architecture to distribute your resources across the fault domains within the AD.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 switch the standby database to the primary role.
- Switchover: Reverses the primary and standby database roles. Each database continues to participate in the Data Guard association in its new role. A switchover ensures no data loss. You can use a switchover before you perform planned maintenance on the primary database.
- Failover: Transitions the standby database into the primary role after the existing primary database fails or becomes unreachable. A failover might result in some data loss when you use Maximum Performance protection mode.
- Reinstate: Reinstates a database into the standby role in a Data Guard association. You can use the reinstate command to return a failed database to service after correcting the cause of the failure.
Scale CPU and Storage Automatically
To achieve high availability for your solutions, you must ensure that your DB Systems have sufficient capacity. Database services on Oracle Cloud Infrastructure can dynamically scale CPU cores or database storage based on the different shapes of your Database service.
For DB Systems based on bare metal Compute instances, we recommend that you start with minimum CPU cores and dynamically increase the number of CPU cores as needed. For DB Systems based on virtual machine shape, you can dynamically increase the CPU cores and storage size.