Real Application Clusters is one of the revolutionary features in Oracle 9i Database. Real Application Clusters is a breakthrough technology that provides many advantages for Online Transaction Processing (OLTP), Decision Support System (DSS), Online Analytic Processing (OLAP) and hybrid system types. With the increased functionality of Real Application Clusters, above mentioned systems can effectively take the advantages of clustered environments.
Other benefits of using Real Application Clusters is to deliver high performance, increased throughput, and high availability of the database for 365x24x7 environments. But before using Real Application Clusters, we must first understand how Real Application Clusters works, what resources it requires, and how to effectively deploy it.
Prior Experience Of Oracle Architecture is a Must to Know about RAC
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.
What is Real Applications Clusters?
Real Application Clusters is a computing environment that harnesses the processing power of multiple, interconnected computers also knows as nodes. 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 we divide a large task into subtasks and distribute the subtasks among multiple nodes, then we 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 applications to meet increasing data processing demands. As resources are added, Real Application Clusters can exploit them and extend their processing powers beyond the limits of the individual components.
Real Application Clusters can be used 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.
Advantages Of RAC’s
- Improved throughput
- Scalability over single instance systems
- Improved response time
- High availability
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:
- Single instance exclusive
- Shared with a single instance
- Shared with two or more instances
Buffer Cache Management
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.
Fast Commits, Group Commits, and Deferred Writes
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:
- When the blocks have not been used recently and new data requires buffer cache space (in shared or exclusive mode)
- During checkpoints (in shared or exclusive mount mode)
- When another instance needs the blocks (only in shared mode)
- Cache copies of dirty blocks (changed blocks) across the interconnect (write/write consistency).
Row Locking and Multiversion Read Consistency
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.
Online Backups and Archiving
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 we 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.
In ARCHIVELOG mode, we can make both online and offline backups. If we operate Oracle in NOARCHIVELOG mode, then offline backups can be made. If we cannot afford any data loss, then Oracle strongly recommends that production databases must be operated in ARCHIVELOG mode.