|Oracle9i Real Application Clusters Concepts
Release 1 (9.0.1)
Part Number A89867-02
This chapter introduces cluster database processing and the features of Real Application Clusters.
In release 9i, Real Application Clusters embodies a breakthrough technology that offers significant advantages for Online Transaction Processing (OLTP), Decision Support System (DSS), and hybrid system types. With the increased functionality of Real Application Clusters, such systems can effectively exploit the redundancy of clustered environments.
You can also use Real Application Clusters to deliver high performance, increased throughput, and high availability. Before deploying Real Application Clusters, you must first understand how Real Application Clusters works, what resources it requires, and how to effectively deploy it.
This chapter includes the following topics:
Before reading about Real Application Clusters, you should be familiar with single instance Oracle processing.
Because you typically use Real Application Clusters in environments with more than one node, you have to configure at least two instances of Oracle so that they share access to an Oracle database. Having at least two instances means your administrative tasks are more complex than with single instance Oracle. For example, the way Oracle manages rollback segments, redo log files, System Change Number (SCN) generation, and so on, is more complex in Real Application Clusters than in single instance Oracle environments.
There are also additional architectural components in Real Application Clusters. These components synchronize data access within Real Application Clusters environments.
This manual assumes that you understand the terminology associated with single instance databases and client/server architecture. Each new term is shown in bold face type.
Real Application Clusters introduces new terminology. Refer to the Glossary for new terms and definitions.
Real Application Clusters is a computing environment that harnesses the processing power of multiple, interconnected computers. Real Application Clusters software and a collection of hardware known as a cluster unites the processing power of each component to become a single, robust computing environment. A cluster generally comprises two or more computers, (or nodes). A cluster is also sometimes referred to as a loosely coupled computer system.
In Real Application Clusters environments, all nodes concurrently execute transactions against the same database. Real Application Clusters coordinates each node's access to the shared data to provide consistency and integrity.
Harnessing the power of multiple nodes offers obvious advantages. If you divide a large task into subtasks and distribute the subtasks among multiple nodes, then you can complete the task faster than if only one node did the work. Cluster database processing is clearly more efficient than sequential processing. It also provides increased performance for processing larger workloads and for accommodating growing user populations.
Real Application Clusters can effectively scale your applications to meet increasing data processing demands. As you add resources, Real Application Clusters can exploit them and extend their processing powers beyond the limits of the individual components.
You can use Real Application Clusters for many system types. For example, data warehousing applications accessing read-only data are prime candidates for Real Application Clusters. In addition, Real Application Clusters successfully manages increasing numbers of Online Transaction Processing (OLTP) systems as well as hybrid systems that combine the characteristics of both read-only and read/write applications.
Real Application Clusters also serves as an important component of robust high availability solutions. A properly configured Real Application Clusters environment can tolerate failures with minimal downtime.
Some of the most important benefits beyond the obvious advantages of cluster database processing are described in the following sections. These benefits include improved throughput and scalability over single instance systems and improved response time. Real Application Clusters also provides an ideal high availability solution by resolving node failure in a clustered environment.
Real Application Clusters environments are functionally transparent when compared to single instance environments because they are functionally identical to single instance environments.
Scalability is the ability to add additional nodes to Real Application Clusters and achieve markedly improved performance. Real Application Clusters can take advantage of additional equipment and harness the processing power of multiple systems.
The term high availability refers to systems with redundant components that provide consistent, uninterrupted service, even in the event of hardware or software failures. In most high availability configurations, nodes are isolated from each other so a failure at one node does not affect the entire system. In such a case, surviving nodes compensate for the loss of the failed node through recovery and the system continues to provide data access to users. This means data is consistently available, more so than it would be with a single node upon node failure. High availability also implies increased database availability.
The concept of transparency is the functional equivalent of single instance Oracle and shared configurations that use Real Application Clusters. Applications that run on single instance Oracle execute with the same results using Real Application Clusters. An Oracle database can be configured to execute in three different modes:
Real Application Clusters takes advantage of the cluster database processing in a computer cluster without sacrificing Oracle's inherent transaction processing features.
The following subsections discuss Oracle features, both in exclusive and shared modes, that result in improved application performance when these applications run by using Real Application Clusters.
Within a single instance, Oracle stores resources, such as data block information, in a buffer cache that resides in memory. Storing this information locally reduces the disk Input/Output (I/O) necessary for database operations. Since each node in Real Application Clusters has its own memory that is not shared with other nodes, Real Application Clusters must coordinate the buffer caches of different nodes while minimizing additional disk I/O that could reduce performance. The Oracle Global Cache Service technology maintains the high-performance features of Oracle while coordinating multiple buffer caches.
Oracle9i Database Concepts for detailed information about the buffer cache
Fast commits, group commits, and deferred writes operate on each instance in Oracle and work the same whether in exclusive or shared mode.
Oracle only reads data blocks from disk if they are not already in the buffer caches of one of the instances. Because data block writes are deferred, they often contain modifications from multiple transactions.
Optimally, Oracle writes modified data blocks to disk only when necessary:
Oracle's row locking feature allows multiple transactions from separate nodes to lock and update different rows of the same data block. This is done without any of the transactions waiting for the others to commit. If a row has been modified but not yet committed, then the original row values are available to all instances for read access. This is called multiversion read consistency.
Real Application Clusters supports all Oracle backup features that are available in exclusive mode, including both online and offline backups of either an entire database or individual tablespaces.
If you operate Oracle in
ARCHIVELOG mode, then each online redo log file is made into an archive (ARCH) file before it is overwritten. In Real Application Clusters, each instance can automatically archive its own redo log files or one or more instances can manually archive the redo log files for all instances.
ARCHIVELOG mode, you can make both online and offline backups. If you operate Oracle in
NOARCHIVELOG mode, then you can only make offline backups. If you cannot afford any data loss, then Oracle strongly recommends that you operate your production databases in