Oracle database High Availability – Data Guard, Standby, RAC
In my previous article I described some best practices in architecting database systems for first 2,5 High Availability Levels (HA) describing some technical solutions based on SAN, cluster, Clusterware, Oracle ASM, Cold Failover Cluster (CFC). This time I’ll continue till Availability level 3 describing single and cluster database solutions including Data Guard, Standby database and Oracle Real Application Cluster (RAC). I suggest reviewing a few my previous articles on database High Availability including the Availability Continuum graph that illustrates and depicts the increases in availability that can be gained with the progression between levels of availability:
High Availability and SLA requirements for Oracle database
Oracle High Availability – ASM, Clusterware, Cold Failover
Availability Level 2b: Oracle Data Guard / Standby
Another option of Level 2 availability is employing Oracle Data Guard to replicate the database to the failover hardware. Some down time is incurred during the failover to the redundant system.
At this point we consider Data Guard at one physical location. Applying Data Guard for disaster recovery solutions refers to Availability Level 4.
Oracle Data Guard provides the benefits of system-level, site-level, and data-level protection, resulting in high levels of availability and disaster recovery without loss of data. Data Guard addresses primary servers / site failures and data protection through transactionally consistent Primary and Standby databases that do not share disks, enabling recovery from server / site disasters and data corruption.
Standby database architecture consists of the following key components
– Primary database resides on server A.
– Standby database resides on server B. If zero data loss is required with minimum performance impact on the primary database.
– Fast-start failover is recommended to provide automatic failover without user intervention and bounded recovery time. If the primary database uses the asynchronous redo transport, configure your maximum data loss tolerance or the Oracle Data Guard broker’s FastStartFailoverLagLimit property to meet your business requirements.
– Use a Data Guard Redo Apply (Physical Standby database) if read-only access is sufficient.
– Evaluate Data Guard SQL Apply (Logical Standby database) if additional indexes or materialized views are required for reporting purposes and/or you have to replicate changes to Standby side only for several schemas. Logical Standby has more restrictions and more work in database configuration.
Data Guard Redo Apply (Physical Standby database) has proven to be a popular solution for disaster recovery due to its relative simplicity, high performance, and superior level of data protection. Beginning with Oracle Database 11g, a Physical Standby database can be open read-only while redo apply is active. This means that you can run queries and reports against an up-to-date Physical Standby database without compromising data protection or extending recovery time in the event a failover is required. This option is called Active Data Guard and licensed separately giving some more benefits.
Note that beginning with Oracle Database 11g, the Primary and Standby systems in a Data Guard configuration can have different CPU architectures, operating systems (for example, Windows and Linux for Physical Standby database only with no EM support for this combination), operating system binaries (32-bit and 64-bit), and Oracle database binaries (32-bit and 64-bit).
You can use a combination of Multiple Standby Databases at the same time to achieve a particular required High Availability (HA) level.
Availability Level 3a: Recovery via Redundant Components – Oracle RAC
Level 3 availability introduces true redundancy of live components, with multi-node Oracle RAC used for the database, hosted at the same physical location. Oracle RAC addresses system failures by providing rapid and automatic recovery from failures, such as node failures and instance crashes. Oracle Database with Oracle RAC architecture is designed primarily as a scalability and availability solution that resides in a single data center. I’ll touch an Extended Oracle RAC configuration in the next article though.
Below I list the main Infrastructure components that are required to build Oracle RAC system at one physical location:
– 2 or multiple-nodes cluster
– OS with Oracle Clusterware / GRID Infrastructure
– Shared storage is mandatory for database files and can be placed on Oracle ASM, OCFS2, NFS or any other certified cluster file system (see what options are certified by Oracle in my other article)
– Multiple Oracle database instance running in RAC mode
Oracle RAC pros and cons
+ Increased availability with Hot-failover functionality
+ Increased scalability across database instances
+ Ability of increasing capacity without downtime
+ Optimal computer resources usage
+ Rolling upgrades and patching
+ DB connection load-balancing
– Licensed separately (~+50% on top of CPU license)
– Might affect DML intensive performance
– Solid DBA experience required on Oracle RAC
– Strict requirements for the cluster interconnect
I’d like to mention one important point related to Oracle RAC here. Switching from single database instance to a RAC database will bring extra maintenance complexity and will require considerable RAC training and/or experience from company DBAs. This is not only how to install and configure RAC but also understanding a behavioral change in many parts of a RAC database including backup and recovery, performance tuning, etc.
As summary with this article I covered two more High Availability (HA) levels describing database solutions including Data Guard, Standby database and Oracle RAC. I’ll continue next time with Extended Oracle RAC and Oracle Maximum Availability Architecture (MAA).