| Oracle® Database High Availability Architecture and Best Practices 10g Release 1 (10.1) Part Number B10726-02 |
|
|
View PDF |
| Oracle® Database High Availability Architecture and Best Practices 10g Release 1 (10.1) Part Number B10726-02 |
|
|
View PDF |
This chapter describes high availability architectures in an Oracle environment. It includes the following sections:
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.
The following sections describe each architecture and their advantages in more detail:
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 |
|
| Flashback capabilities to protect from user errors and logical corruptions |
|
| Online redefinition and reconfiguration for minimal or no scheduled downtime for changes to object structures or applications |
|
| Manage backup and recovery operations automatically |
|
| 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 |
|
"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.
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
|
See Also:
|
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.
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.
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:
Does your production system need to be available 24 hours each day, 7 days each week, 365 days each year?
Does your scheduled maintenance currently exceed your service levels?
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
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 | No RAC HA capability
No Data Guard capability |
|
| 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) |
|
| 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 |
|
| 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 |
