Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 

 

 

Failover Database Clusters

Oracle RAC Cluster Tips by Burleson Consulting

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%.


As noted earlier, fail-over (FO) database clusters are implemented by many enterprises to meet their high availability requirement. In this method, when there is a failure on the primary node, the database instance running on the failed node fails over to a backup node, in other words, it restarts the database instance on the surviving node. However, the behavior of a typical Parallel database cluster such as Oracle RAC is much different. An Oracle RAC instance is not failed over, but causes the reconfiguration of resources from the failed instance to the non-failed instance(s) to take place.

This section will explore the fail over database cluster functionality and various components such as resources, resource groups and failover mechanisms.

Resources, Resource Types

Resources are hardware or software entities, such as disks, network interface cards (NIC), IP addresses, applications and database instances controlled by cluster software. Controlling a resource means bringing it online (starting), taking it offline (stopping) as well as monitoring the health or status of the resource.

Depending on the type of resource, the clustering software, through a script or an agent, controls the status by starting and stopping activities. For example, mounting involves starting a file system resource. Starting IP resource involves configuration of the IP address on a network interface card. Monitoring a resource means testing it to determine if it is online or offline. How Cluster Software monitors a resource is also specific to the resource type. For example, a file system resource tests as online if mounted, and an IP address tests as online if configured.

Resource Groups

A resource group is a set of resources working together to provide application services to clients. A resource group is sometimes called a service group or a package. Different cluster vendors call this by different names.

For example, as shown in Figure 3.7, a database resource group might consist of:

* Disk groups on which the physical storage data volumes are located.

* Volumes built in the disk group storage.

* A file system using the volume.

* Network interface card or cards used.

* One or more IP addresses associated with the network card(s).

* A Listener Process.

* Database Instance.

A cluster software script or agent executes operations on resources, including starting, stopping, restarting and monitoring at the resource group level. Resource group operations initiate administrative operations for all resources within the group. For example, when a Resource group is brought online, all the resources within the group are brought online. When failover occurs, resources never fail-over individually rather the entire resource group fails. Thus, the resource is the unit of failover. If there is more than one group defined on a server, one group may fail-over without affecting the other group(s) on the server.

Figure 3.7: Cluster Resource Group and Resources

From a cluster standpoint, there are two significant aspects to this view of an application resource group as a collection of resources:

* If a Resource group is to run on a particular server, all of the   resources it requires must be available to the server.

* The resources comprising a resource group have interdependencies; that is, some resources (e.g., volumes) must be operational before other resources (e.g., the file system) can be made operational.

 


This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters, Rampant TechPress, by Mike Ault and Madhu Tumma.

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.

http://www.rampant-books.com/book_2004_1_10g_grid.htm


 

 
��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational