This is an excerpt from the bestselling book
Oracle Grid & Real Application Clusters. To get immediate
access to the code depot of working RAC scripts, buy it
directly from the publisher and save more than 30%.
No doubt, there is wide
acceptance of failover (FO) clusters, and in most situations, FO
clusters provide an excellent failover mechanism, but there are some
hidden risks with the nature and implementation of FO clusters.
The hidden risks with FO
clusters are as follows:
* Database Failover is a time
consuming process. It is usually a cold fail-over (Active/passive).
A fresh database instance starts on the surviving node. For example,
the un-mounting of a file system may hang and as a result off-line
activity may take longer time.
* The entire process of
monitoring and failover depends on scripts. Scripts can become
problematic with bugs and sometimes they may not take care of all
* Cluster technology cannot
protect against software corruption and human-induced failures. If
the server operating system crashes in such a manner that it
corrupts the file system, recovery by the other member of a cluster
may not be possible.
* If the owner of a file
accidentally deletes it from the file system, the cluster will be
unable to recover the file. Even after failing over to the second
node, the same problem of file loss exists.
* Maintenance and backup is a
challenge. In the case of active/active architecture for a database
cluster, the executables and other related files that you store on
local storage have to be kept synchronized. Any mismatch of
executables or patches might have an effect on the start up of the
standby database during the fail over process.
* Configuration of the critical
resources that make up the resource or service group is very
significant and careful thought has to be given to the design
configuration. Dependencies have to be accurately reflected, for
example, in a service group, MQ Series, the database instance and
Listener are defined as critical resources. In this situation, even
if MQ-series fails for any reason, the database instance and
listener are brought down or failover unnecessarily.
So far, many details about the
FO Clusters and Database deployment and failure process have been
covered. Now it is time to move on to basic features of parallel
Clustered Database (PDB) is a complex application, which provides
access to the same database, or group of data tables, indexes and
other objects, from any server in the cluster concurrently without
compromising data integrity. Well known examples include Oracle Real
Application Cluster (Oracle RAC), the subject matter of this book,
IBM UDB DB2 Enterprise Extended Edition (EEE), and IBM S/390
Parallel Sysplex Clusters.
Databases typically contain multiple nodes or servers accessing the
same physical storage or data concurrently. PDB Architecture allows
multi-server data sharing technology, allowing direct concurrent
read/write access to shared data from all the processing nodes in
the parallel configuration. However, this necessitates complex lock
management to maintain the data integrity and resource coordination.
In terms of
storage access type, a Parallel Clustered System is implemented in
two ways, the Shared Nothing Model and the Shared Disk Model.