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

Free Oracle Tips


 
HTML Text AOL
 
 

Oracle9i Real Application Clusters

August 7,  2003
Don Burleson

 

Previous versions of Oracle OPS were not very good for OLTP systems, due to pinging and performance issues. Not only is performance improved with RAC, but also reliability. In order to lose the DB with an Oracle9i RAC you would have to either lose the entire LAN, lose the SAN drives, or lose all servers that are running RAC. With modern built in redundancies for the network, SAN drives, and servers, the scenario of total loss is minimized greatly.

Attributes of an Oracle RAC Cluster

The Oracle9i RAC allows for a single or multi system image. This means that the root file and other system files can be either localized in internal or non-shared disks for each server in the RAC or each server can load the operating system from a central set of disks.

If the RAC cluster uses a SAN or other network storage device it is known as a Shared System Disk (root) system.

A RAC system must use a cluster file system or a raw partition, where any server can read or write to any disk in the shared disk subsystem. This allows access to all data files, control files, and redo and rollback areas by any instance. This ability to access all disks allows for instance recovery after an instance failure has occurred. All surviving nodes automatically absorb the failed instance’s tasks until the failed instance is brought back online, at which time it is fully synchronized and restored to service automatically.

A RAC cluster provides for automatic shared execution of Oracle applications. This means that for any Oracle instance application, all queries and other processing are automatically shared among all of the servers in the RAC cluster.

The sharing of application processing by all servers in the RAC cluster leads to automatic load balancing across all cluster members. The ability of a RAC cluster to provide shared application execution and automatic load balancing leads to the true scalability of applications without code or data changes.

One limit on shared-none or federated databases was the amount of time required for failover. Due to the requirements for rebuilding or rehashing of data, fail-over time in a non-shared disk environment can be prohibitive. In a RAC cluster, fail-over time is virtually nil, since Oracle handles the redistribution of work automatically. Furthermore, the rehashing of data is not required because all participating nodes in the RAC cluster share the same data files.

The number of servers that your LAN architecture allows you to connect into the disk farm is the only limit to the number of nodes in a RAC cluster. In the SQL Server 2000, the cluster database has a hard limit of 2 or 4 servers, depending on the level of the server license for Windows 2000 that is loaded on the server. The convoy effect limits the number of servers that an IBM type structure allows.

Due to the cache fusion and the high-speed cluster interconnect, the Oracle9i RAC allows for a virtually unlimited number of nodes in a RAC cluster. The maximum number of instances that can be interconnected is OS platform-dependent. This indicates that you need to plan ahead and determine just how large the RAC cluster is anticipated to grow, before making operating system decisions concerning your RAC environment.

Oracle9i RAC allows for the following protocols to be used in the cluster interconnect:

  • TCP/IP

  • UDP

  • VIA

  • RDG

  • HMP

The speed of the cluster interconnect should be, at a minimum, 100 mbit/sec. The distance allowed between nodes on a cluster interconnect is system and LAN-specific. Again, plan ahead. Some forms of interconnect allow only a couple hundred yards, some allow miles; your choice for network protocol will determine whether nodes must reside in the same room, building, or be spread across your corporate campus.

Oracle RAC offers greater disaster tolerance than either UDB/DB2 or Microsoft SQLServer, because if single or multiple nodes fail, the load is not redistributed between all of the remaining nodes. If the database is globally distributed then a disaster to a single site will not affect other sites.

Building an Oracle RAC Cluster

The first step in building a RAC cluster is to establish the connecting LAN to a SAN or other network storage device via a HUB, fiber channel switch, or shared SCSI (for systems not requiring high performance, IEEE1394 or Firewire drives can also be used). Once the LAN and SAN are configured, servers are attached and configured. If the root, user, and other systems are moved into the shared storage and shared among all cluster members, it greatly reduces the amount of system management overhead and database overhead.

Once the LAN, SAN, and base servers are configured, the cluster manager software from Oracle is installed on all nodes that will participate in the Oracle cluster configuration. Following the cluster manager installation, the main node is loaded with the Oracle software, which is automatically copied to all other nodes, as directed by the person doing the installation.


If you like Oracle tuning, check out my latest book
"Oracle Tuning: The Definitive Reference". 

It's 980 pages of hard-core tuning insights, tips and scripts, and you can buy it direct from the publisher for 30%-off. 

 

 
 

 

 

Burleson Consulting
One Burleson Plaza - First Floor - RN3
 2729 Rocky Ford Road • Kittrell, NC, 27544

Email: • Phone (252) 431-0049

Copyright © 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Burleson Enterprises, Inc. All rights reserved.