Skip Headers

Oracle® Database High Availability Architecture and Best Practices
10g Release 1 (10.1)

Part Number B10726-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

4 High Availability Architectures

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

4.1 Oracle Database High Availability Architectures

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

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

Description of maxav032.gif follows
Description of the illustration maxav032.gif

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

4.1.1 "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

4.1.2 "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

Description of maxav015.gif follows
Description of the illustration maxav015.gif

4.1.3 "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

Description of maxav020.gif follows
Description of the illustration maxav020.gif


See Also:

4.1.4 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

Description of maxav004.gif follows
Description of the illustration maxav004.gif

4.1.5 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

Description of maxav019.gif follows
Description of the illustration maxav019.gif

4.2 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:

4.3 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

  1. RAC
  2. 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)

  1. Data Guard
  2. 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

  1. Data Guard or Streams
  2. 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