RAC Adoption Motivators and Benefits

[sukishan]

Early adopters in 2003 primarily deployed RAC for improved availability, as it provides less than 60-second failover when a server or database instance fails in a cluster. Although RAC provides increased availability, most clients implement RAC to increase scalability and flexibility. Scalability is improved through scale-out architectures, enabling horizontal scaling on lower-cost hardware (versus vertical scaling with symmetric multiprocessing [SMP] systems) and the ability to better match investments with increased business demand (versus having to buy hardware in anticipation of demand).

Because many cluster nodes can participate in a 10g grid, any database instance can run on any node, thus improving flexibility. For example, if a node needs to come down for planned downtime, then the database demand can be spread across other nodes in the cluster. One node can even be repurposed from running one instance to another instance. Moreover, if demand is rising from one application and more capacity is needed, then the DBA can add more capacity by starting the database on another node in the grid.

Specific benefits that Oracle customers cited include:

* Shared infrastructure and storage: The increased flexibility and manageability enabled by ASM enable customers to manage many databases in a single cluster of server nodes. Nodes can run any database instance. Because RAC can scale up or down horizontally, DBAs can optimize the capacity of each individual database by scheduling or manually initiating capacity increases or decreases, thus reducing the overprovisioning that occurs with infrastructure islands of databases. In addition, clients that had tried Oracle's Cluster File System (CFS) in 9i indicated that ASM is easier to manage and reduces complexity associated with allocating storage to instances.

* Active/active processing: RAC enables full use of acquired capacity, rather than operating in active/passive mode.

* Horizontal scale and lower-cost x86 servers: Many RAC customers buy into the grid concept by justifying using lower-cost x86 servers, rather than using more-expensive Unix SMP systems. Many Oracle customers cited the ability to scale horizontally with business growth as the primary driver for using RAC. Clients stated they found 80% or more scaling of new nodes added to the grid (10 to 18 nodes total).

* Planned downtime: This referred to migrating instances between nodes to enable hardware and OS maintenance without affecting users.
* Unplanned downtime: Failover time is typically less than one minute. However, depending on the type of application, some organizations measured failover time in tens of seconds. Query transactions are preserved across the cluster without user re-entry (update transactions must be re-entered).
* DBA efficiencies of up to 50% savings over managing 9i RAC: DBAs can provision nodes faster, as well as manage storage and tune the environment with fewer resources.
* Single integrated stack of software (RAC DBMS, ASM and Grid Control) with one-stop support: All the customers with whom we spoke reported excellent support by Oracle for their RAC environments. While all these customers continued to use the OS supplier for OS support, those using Linux noted Oracle's considerable knowledge on the OS side, which aided support calls. For that reason, some were evaluating Oracle's Linux distribution. The integrated stack also reduces third-party software required for tools such as clustering, file systems and diagnostics.