Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

   
Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





   

 

 

 

Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation

 

 


 

 

 

        
 

 Oracle RAC Design Considerations
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.

This chapter focuses on the issues that must be considered when designing for Real Application Cluster (RAC). The reasons for utilizing RAC must be well understood before a proper implementation can be achieved. These are the key reasons to use RAC:

  • Spread the CPU load across multiple servers

  • Provide high availability (HA)

  • Take advantage of larger SGA sizes than can be accommodated by a single instance commodity server

  • Scalability

Conversely, there are cases where RAC may not be an appropriate design option.  It would be wise for both technical and non-technical team members to keep the following in mind when considering RAC.

  • If RAC is being used as a cost savings solution, be sure to analyze both hardware and software costs

  • Do not expect RAC to scale if the application will not scale on SMP

  • Be realistic about the latency difference between local only memory-cache instance communication and inter-node network based multi-instance cache fusion communication

A high availability RAC design must have no single point of failure, a transparent application failover, and reliability.  Failure of the local data center must also be considered.  A high availability design requires attention to equipment, software, and the network.

 

The following sections provide a look into two key design considerations. The first is the design of the equipment needed to support a HA RAC configuration. Next, the methods of configuring RAC instances in a RAC cluster to meet performance and HA requirements will be addressed.

Designing Equipment for Real Application Clusters

The most important design feature of the equipment used in HA RAC clusters is an architecture that eliminates any single point of failure (SPF). The diagram in Figure 4.1 implements a number of design flaws that does not adhere to the definition of high availability. 

 

Figure 4.1: Non-Redundant Configuration

Figure 4.1 shows a RAC configuration. However, this configuration, other than the RAC cluster itself, has no redundancy and many single points of failure. The single points of failure are:

  • Firewall

  • Application Server

  • Fabric Switch

  • SAN array

A failure of any one of these single points will result in unscheduled downtime, no matter how well the RAC cluster is designed and tuned.

 

It is critical to ensure that there is no single point of failure in a high availability configuration. Figure 4.2 illustrates exactly what eliminating single points of failure means.

 

Figure 4.2: Example of a Redundant RAC Configuration

The system shown in Figure 4.2 has had the following redundancies added:

  • Second firewall with an independent connection to the web

  • Second application server

  • Second fabric switch with redundant pathways

  • Second SAN array

  • Set of load balancers

  • Geo-remote RAC Guard configuration

Now the single points of failure in Figure 4.1 have been eliminated. A third server has also been added as well as a SAN array in a geographically remote location. This third server and SAN ensure that not even a disaster at the primary location will bring the application down.  The application server and firewall for this third server are not shown and may not be required if the firewalls and application servers are in a different location from the database servers.

 

In addition, the SAN, perhaps a Hitachi, EMC Clariion or EMC Symmetrix, should be configured using redundant disk configurations such as RAID -1 or RAID-5.  It should be stressed that application performance can suffer horribly from a disk failure during either a disk rebuild with installed spares or a rebuild of the information using parity information from the other disks in a RAID-5 set. 

     

Remote DBA Service
 

Oracle Tuning Book

 

Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software

 

 

 

 

 

 

 

 

 

BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.