4
High Availability Architectures

This chapter describes high availability architectures in an Oracle environment. It includes the following sections:

• Oracle Database High Availability Architectures
• Choosing the Correct HA Architecture
• Assessing Other Architectures

Oracle Database High Availability Architectures

This section defines the top five database architectures that address various high availability business needs. The architectures described are:

• Database only: This is a single instance production database on a standalone machine and uses all of the HA features that come with the Oracle database. Flashback technology can recover quickly from user and logical errors. Online redefinition and reorganization can reduce downtime for most scheduled maintenance activities. Oracle's sophisticated backup and recovery framework with RMAN can be customized for each customer's recovery requirements.
• RAC only: This involves a RAC database. RAC environments can provide continuous service for both planned and unplanned outages within the cluster. If a node or instance fails, then the application service fails over to existing RAC instances quickly and transparently.
• Data Guard only: The primary site contains a production database. The secondary site contains one or more standby databases. If there is a primary site failure or database failure or any failure that cannot be resolved quickly at the local site, then you can use Data Guard to fail over or switch over to a standby database.
• Maximum Availability Architecture (MAA): The primary site contains a RAC production database. The secondary site contains a cluster that hosts both logical and physical standby databases. This architecture provides the most comprehensive set of solutions for both unscheduled and scheduled outages because it inherits the capabilities and advantages of both the RAC and the Data Guard architectures.
• Streams: The primary site contains a production database. The secondary site contains a replicated database using Streams technology. Both sites can be active, and transactions can be synchronized in both directions. The platforms can also be heterogeneous.

Oracle provides a wide array of HA architectural solutions. The "Database only" architecture is not highly available, but it contains many availability features and assets that are used by all other architectures. The "Database only" architecture is the starting point for most customers. "RAC only", "Data Guard only", and Streams architectures provide additional HA capabilities in addition to the "Database only" capabilities. MAA incorporates both RAC and Data Guard advantages and represents the architecture with maximum availability. Figure 4-1 illustrates the hierarchy of the different HA architectures.

Figure 4-1 Hierarchy of HA Architectures

Text description of the illustration maxav032.gif

The following sections describe each architecture and their advantages in more detail:

• "Database Only" Architecture
• "RAC Only" Architecture
• "Data Guard Only" Architecture
• Maximum Availability Architecture
• Streams Architecture

"Database Only" Architecture

Oracle provides HA features that can be used in any of the database architectures. These features make the standalone database on a single machine attractive and available. These features are described in Table 4-1. Chapter 9, "Recovering from Outages" describes when to use these features to resolve different outages, while Chapter 10, "Detailed Recovery Steps" contains details about how to use the features to recover.

Table 4-1 High Availability Features of the Oracle Database  

Feature	Description
Reduced downtime for application and Oracle upgrades	One-step cloning of database objects for faster online redefinition during upgrades Eliminates PL/SQL package invalidation after changes to underlying objects Handles data definition language (DDL) locks on busy tables
Flashback capabilities to protect from user errors and logical corruptions	Flashback Version Query retrieves metadata and historical data for a specific time interval Flashback Transaction Query retrieves metadata and historical data for a specific transaction or for all transactions within a specific time interval Flashback Table recovers a table to its state at a previous point in time Flashback Drop recovers a dropped table Flashback Database provides a more efficient alternative to database point-in-time recovery
Online redefinition and reconfiguration for minimal or no scheduled downtime for changes to object structures or applications	Any physical attribute of a table can be changed online. The table can be moved to a new location. The table can be partitioned. The table can be converted from one type of organization (such as heap-organized) to another (such as index-organized). Many logical attributes can be changed. Column names, types, and sizes can be changed. Columns can be added, deleted, or merged. (The primary key of the table cannot be modified.) Secondary indexes can be created and rebuilt on index-organized tables (IOTs). Secondary indexes support efficient use of block hints (physical guesses). Invalid physical guesses can be repaired online. Index can be created online and analyzed at the same time. CLOB and BLOB datatypes have extended support.
Manage backup and recovery operations automatically	Automated disk-based backup and recovery that provides a simplified and unified storage location for backups, archived redo log files, flashback logs, and other files required for recovery RMAN backup capabilities such as backup standby control file support, simplified cataloging of backup files, simplified backups to disk, and improved incremental backups to avoid scanning an entire datafile RMAN recovery capabilities such as automated file creation during recovery, simplified recovery through resetlogs, and the ability to flash back and recover to different points in time
Fast and efficient object re-creation features	Data Pump
Fast-start recovery during startup	Fast-start checkpointing can be used to reduce instance recovery time
Simple and integrated management framework with Oracle Enterprise Manager	Easy GUI for installation, set-up, and configuration Integrated monitoring and management practices

"RAC Only" Architecture

"RAC only" architecture uses Real Application Clusters and is an inherently high availability system.The clusters that are typical of RAC environments can provide continuous service for both planned and unplanned outages. RAC build higher levels of availability on top of the standard Oracle features. All single instance HA features, such as flashback technologies and online reorganization, apply to RAC as well.

In addition to the standard Oracle features, RAC exploits the redundancy that is provided by clustering to deliver availability with n - 1 node failures in an n-node cluster. All users have access to all as long as there is one available node in the cluster.

This architecture provides the following benefits:

• Fast node and instance failover (measured in seconds)
• Integrated and intelligent connection and service failover across various instances
• Planned node, instance, and service switchover and switchback
• Rolling patch upgrades
• Multiple active instance availability and scalability across multiple nodes
• Comprehensive manageability that integrates database and cluster features

Figure 4-2 shows "RAC only" architecture.

Figure 4-2 "RAC only" Architecture

Text description of the illustration maxav015.gif

"Data Guard Only" Architecture

Data Guard provides a rich set of HA solutions and addresses the requirements of the business community for a disaster recovery solution. Data Guard supports Data Guard Redo Apply and Data Guard SQL Apply technologies to enable two distinct kinds of standby databases: physical standby database and logical standby database.

Physical standby databases have provided HA solutions to thousands of applications since Oracle version 6. The introduction of Oracle Data Guard in Oracle8i and further enhancements in the Oracle9i and Oracle Database 10g releases have provided a simple and sophisticated HA suite. Data Guard physical standby architectures are the most efficient and simplest standby database environments. Logical standby databases, introduced in Oracle9i, enable recovery of transactions while permitting read and write operations to occur simultaneously in the same database. Logical standby databases require additional processing, but for some applications, they can be a very suitable HA solution or can complement other solutions. For some customers, both physical and logical standby databases can be used as part of an HA solution, which is recommended in MAA. The physical standby database becomes the initial switchover and failover target, while the logical standby database is used for reporting, queries, and additional processing to relieve the load on the production database. The logical standby database can also be targeted for switchovers, failovers, and rolling database upgrades.

Physical standby databases provide these advantages:

• Protection from user errors and logical corruptions
• Protection from disasters and site failures if located remotely
• Fast site and database failover (measured in minutes)
• Fast site and database planned switchovers for maintenance
• Backups can be taken from the physical standby database instead of the production database, relieving the load on the production database
• Read-only capability, resulting in better use of system resources

In addition to disaster recovery and data protection, logical standby databases provide the following benefits:

• Enable the standby database to be open for normal operations with both read-only and read/write accessibility
• Enable additional objects to be built and maintained
• Enable rolling database upgrades of the production database

A recommended configuration for many cases includes both physical and logical standby databases. They can reside on the same database machine or cluster, but they should be remote from the production database. The physical standby database can be reserved for failovers in case of disaster, and the logical standby database can continue to be used for reporting. The physical standby database provides a faster apply technology because redo logs do not have to be converted to SQL.

Figure 4-3 shows the production database at the primary site and the standby databases at the secondary site.

Figure 4-3 "Data Guard Only" Architecture on Primary and Secondary Sites

Text description of the illustration maxav020.gif

See Also: Oracle Data Guard Concepts and Administration for more information about datatypes supported by logical standby databases The papers about standby databases at http://otn.oracle.com/deploy/availability/htdocs/maa.htm

Maximum Availability Architecture

RAC and Data Guard provide the basis of the database MAA solution. MAA provides the most comprehensive architecture for reducing downtime for scheduled outages and preventing, detecting, and recovering from unscheduled outages. The recommended MAA has two identical sites. The primary site contains the RAC database, and the secondary site contains both a physical standby database and a logical standby database on RAC.

Identical site configuration is recommended to ensure that performance is not sacrificed after a failover or switchover. Symmetric sites also enable processes and procedures to be kept the same between sites, making operational tasks easier to maintain and execute.

Figure 4-4 provides an overview of the architecture.

Figure 4-4 Maximum Availability Architecture

Text description of the illustration maxav004.gif

Streams Architecture

Streams is meant for information sharing and distribution. It can also provide an efficient and highly available architecture.

Streams provides granularity and control over what is replicated and how it is replicated. It supports bidirectional replication, data transformations, subsetting, custom apply functions, and heterogeneous platforms. It also gives users complete control over the routing of change records from the primary database to a replica database. This enables users to build hub and spoke network configurations that can support hundreds of replica databases.

Streams should be evaluated if one or more of the following conditions are true:

• A full active/active site configuration is required including bidirectional changes
• Site configurations are on heterogeneous platforms
• Fine control of information and data sharing are required
• More investment to build an integrated HA solution is available

For disaster recovery, Data Guard is Oracle's recommended disaster recovery solution.

Figure 4-5 shows Streams architecture.

Figure 4-5 Using Streams in an HA Environment

Text description of the illustration maxav019.gif

Choosing the Correct HA Architecture

This section summarizes the advantages of the HA architectures discusses in this chapter and then provides guidelines for you to choose the correct HA architecture for your business.

Table 4-2 summarizes the advantages of the five basic HA architectures described in this chapter.

Table 4-2 HA Architecture Advantages 

Database HA Architecture	Advantages
Database only Production database on a standalone machine	Reduced downtime for application and Oracle upgrades Flashback capabilities to protect from user errors, and logical corruptions Online redefinition and reconfiguration to minimize scheduled downtime Backup and recovery capabilities Fast and efficient object re-creation features Simple and integrated management framework with Oracle Enterprise Manager Note: All of these advantages are available for the other architectures described in this table, but they will not be repeated.
RAC only RAC production database	RAC HA advantages Transparent to the application See Also: ""RAC Only" Architecture"
Data Guard only Production database (not RAC) on the primary site Standby databases on the secondary or disaster recovery site	Data Guard HA advantages Transparent to the application See Also: ""Data Guard Only" Architecture"
MAA RAC production database on the primary site Standby databases on the secondary or disaster recovery site	RAC HA advantages Data Guard HA advantages Transparent to the application See Also: ""RAC Only" Architecture" and ""Data Guard Only" Architecture"
Streams Primary site: Production database Secondary or additional sites: Database replicated using Streams	Full active/active configuration Database configurations can be heterogeneous platforms See Also: "Streams Architecture"

"RAC only" and "Data Guard only" are the most common Oracle HA architectures, and each provides very significant HA advantages. MAA provides the most redundant and robust HA architecture. It prevents, detects, and recovers from different outages within a small mean time to recover (MTTR), as well as preventing or minimizing downtime for maintenance. The Streams architecture is an alternative high availability solution, but it requires more customization and may not be as transparent to the application.

You must consider your service level agreements in your decision about which HA architecture to implement. To decide whether to implement an Oracle HA architecture that includes RAC or Data Guard, consider the following questions about your service level agreements:

1. Does your production system need to be available 24 hours each day, 7 days each week, 365 days each year?
2. Does your scheduled maintenance currently exceed your service levels?
3. Is disaster recovery required?

Table 4-3 shows the recommended architecture for each set of answers to the questions.

Table 4-3 Service Level Agreements and Recommended HA Architectures  

Answer 1 (Local Site HA)	Answer 2 (Rolling Maintenance)	Answer 3 (Disaster Recovery)	Recommended Architecture
No	No	No	Database only
Yes	No	No	RAC only
No	Yes	No	Data Guard only
No	No	Yes	Data Guard only
Yes	Yes	No	MAA
Yes	No	Yes	MAA
No	Yes	Yes	Data Guard only
Yes	Yes	Yes	MAA

If your business requires any of the following, then you should evaluate Oracle Streams in more depth:

• Full active/active site configuration with bidirectional replication
• Heterogeneous platforms across sites
• Fine control of information and data sharing

Assessing Other Architectures

There are other Oracle and non-Oracle HA solutions. This section focuses on the most common variants. Table 4-4 describes each alternative HA proposal, its disadvantages and the recommended Oracle HA architecture.

Table 4-4 Comparison of HA Architectures  

Alternative Architecture	Disadvantages	Recommended Solutions
Primary site: Oracle database on hardware cluster Note: This is known as cold failover.	No RAC HA capability No Data Guard capability	RAC MAA
Primary site: Production database Secondary site: Remote mirrored database	No RAC HA capability No Data Guard capability High network utilization No Oracle switchover and failover integration Customization required Remote mirroring solution must be part of the Oracle Storage Compatibility Program (OSCP)	Data Guard MAA
Primary site: RAC production database (RAC geo-cluster) Secondary site: At least one node of RAC geo-cluster	Performance impact because of latency between nodes No disaster recovery protection for data or media failures or database corruptions because there are no separate standby databases	Data Guard or Streams MAA
Primary site: RAC production database and local Data Guard	No protection from site disasters and site failures	MAA
Primary site: Production database and local Data Guard	No RAC HA capabilities No protection from disasters and site failures	MAA