Investigacion

Oracle Real Application Clusters
Best Practices on Linux

Kirk McGowan, Oracle Corporation
Roland Knapp, Oracle Corporation

Executive Overview
Oracle Real Application Clusters (RAC) is a multi-node extension to the Oracle database server and a key component in Oracle’s Grid strategy. Commodity hardware, such as blade servers, and commodity OS, such as Linux offer the most compelling costbenefits for Grids. Grids must leverage these commodity components to achieve maximum utilization. Oracle RAC runs real applications on the commodity components and enables high utilization on commodity blade farms. Applications running on RAC can dynamically leverage more blades provisioned to them. Similarly, these applications can easily relinquish these blades when they no longer need them.Much has been written and presented to date on the RAC architecture, and the business benefits of implementing this form of clustering. However, very little has been written regarding strategies and best practices for actually deploying applications on RAC. Oracle’s RAC Pack is a team of RAC implementation specialists that are part of the RAC Development organization. To date, this global team hasassisted over 500 customers successfully deploy their business applications on top of RAC, with a significant percentage of these deployments being on Linux. These applications cover the spectrum - from in-house custom applications, to off-the-shelf applications, and from DSS systems to operational OLTP systems. This paper will present some of the best practices that have been implemented at thesecustomer sites, and that you can use in your own environments to ultimately realize the benefits of moving your IT infrastructure towards a Grid architecture.

Planning
A successful RAC implementation is not all about the mechanics of installing the software, building the database, and tweaking the knobs to make it perform the way you want it to. Many of the challenges that have beenencountered at customer sites have been related to unreasonable expectations, misunderstandings about what RAC is, and what it isn’t, and inadequately defined objectives for the RAC implementation. Having these important issues addressed up front allows you to put together a structured implementation plan that gives the best opportunity to realize the desired business benefits.
Understand RACArchitecture
Understanding the architecture is an obvious initial step prior to implementing any technology, but there is a great deal of confusion and misunderstanding in the marketplace around clustering in general, and this easily creates some fundamental misconceptions about what RAC is, and how to implement it. It is beyond the scope of this paper to provide a complete primer on clusteringarchitectures, and the detailed hardware and software components that make up those architectures, but some things to consider in reviewing cluster-related literature include:
• Distinctions between hardware clustering and database clustering.
• Shared nothing vs. shared data vs. shared cache DB architectures.
• Active-Passive vs. Active-Active.
• Hot standby vs. mutual takeover vs.distributed load clustering
Terminology aside, it is important to note that all clustering architectures provide some degree of high availability through redundancy. However, only RAC, and the hardware cluster architecture on which it is based, provides scalability benefits in addition to HA benefits.
Getting past the terminology is the first step. The next is understanding the hardware and softwarecomponents that comprise the architecture. In the Lintel environment, both IA32 and IA64 architectures are supported, NAS, SCSI, and fiber storage are all compatible, and GigE is currently the best choice for the private interconnect. Each cluster configuration can be a little bit different, so it is important to work closely with the hardware vendor to identify specific driver and/or patch...