Oracle RAC Cache Fusion and High Availability Oracle Tips by Burleson Consulting

Oracle 11g Grid & Real Application Clusters by Rampant TechPress is written by four of the top Oracle database experts (Steve Karam, Bryan Jones, Mike Ault and Madhu Tumma).  The following is an excerpt from the book.

Cache Fusion

RAC provides a multiple instance, single database system.  In a RAC environment, there is one shared set of datafiles.  Each instance in the cluster will have its SGA (RAM area) and binary processes.  Control files and redo log files will belong to each instance but will reside on shared disk for recovery purposes.

A RAC environment uses cache fusion to bring all the instances in the cluster together.  Each instance has its own buffer cache.  Oracle fuses these caches together into a single global buffer cache.  This occurs over a private network called a private or cluster interconnect.  The cluster interconnect allows each node of the RAC cluster to share cached data located in the buffer cache with any other node on the cluster.

Instance 1 (server 1) queries the centralized storage to find all employees between 1 and 10.  Once this query has been executed and fetched, the data will be cached in Instance 1’s buffer cache.  If Instance 1 were to require any of this data again, it would have to look no further than local RAM.  RAM is much faster than disk, so the query would return much quicker.

Again, in Figure 7.1, suppose Instance 2 runs a query that wants a row that Instance 1 already has cached.  In this case, Instance 2 would receive the data over the high-speed network interconnect using cache fusion.  This RAM-to-RAM transfer over the network is not as fast as local RAM, but it definitely beats going to disk.

High Availability

RAC also provides the benefit of High Availability.  If Instance 2 (Figure 7.1) crashes, Instance 1 will take over the user load.  All connections that would have pointed to Instance 2 will fail over to Instance 1.  In some cases, connections that were already pointing at Instance 2 will also fail over.

Uptime

The primary goal of RAC can be summed up in a single word: Uptime. Data drives business. Applications, DSS, expert systems, reporting, analytics - they all require a steady stream of data to keep them alive.

If a bank loses its core transaction database for even a single hour, it can cause massive amounts of error, possible data corruption and millions of dollars lost. 

Oracle RAC is a High Availability (HA) system.  It makes downtime more bearable by providing connection to multiple nodes.  If, in a four-node RAC cluster, a single node crashes, three nodes will take over immediately without a single second of downtime.

Unplanned Downtime

Unplanned downtime can last from seconds to hours in extreme situations and can happen because of some of the most simple or unexpected issues.

Examples of events causing unplanned downtime:

• Power failure

• Overheated server room

• Flooding in server room

• Kernel panic

• Fat fingered mistake (for instance, a systems administrator kills a required process such as SMON)

• Oracle Internal errors

• Hackers

Planned Downtime

Planned downtime is more graceful than unplanned, of course, but in some ways can be worse than unplanned downtime.  Depending on the software on the server, it could require frequent restarts in order to keep things updated.  Some developers and administrators want daily maintenance periods which can cause planned downtime to be the bulk of the total downtime.

RAC alleviates these issues by allowing a single server to be down while the other RAC server(s) keep processing.  Work can progress in a rolling fashion where one server at a time comes down, thereby allowing the database to always remain online.

Copyright © 1996 -  2011 by Burleson Enterprises. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.