Why Oracle RAC Might Not Be Suitable For You

A Competitive Review of Real Application Clusters (RAC)

SQL Server White Paper

Writer:

Published: March 2012

Applies to: SQL Server 2012

Introduction:
In this white paper, we discuss the main reasons why customers might not want to implement
Oracle Real Application Clusters (RAC) in their database solution. We also visit common
database scenarios where a SQL Server solution makes more sense than Oracle RAC. Finally,
we explain common myths or misunderstanding about Oracle RAC. It is assumed that the
reader has a working knowledge of Oracle RAC and Microsoft SQL Server concepts and
features.

Why Oracle RAC Might Not Be Suitable For You

Copyright
The information contained in this document represents the current view of Microsoft Corporation
on the issues discussed as of the date of publication. Because Microsoft must respond to
changing market conditions, it should not be interpreted to be a commitment on the part of
Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the
date of publication.
This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,
EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the
rights under copyright, no part of this document may be reproduced, stored in, or introduced into
a retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written
permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

2012 Microsoft Corporation. All rights reserved.

Microsoft & SQL Server are trademarks of the Microsoft group of companies.

All other trademarks are property of their respective owners.

Why Oracle RAC Might Not Be Suitable For You

Contents
Executive Summary ................................................................................................................... 4
Cloud Computing for Scalability ................................................................................................. 6
Few customers deploying Oracle RAC in production.................................................................. 7
Oracle RAC is too costly ............................................................................................................ 9
Microsoft provides equivalent functionalities with lower TCO ....................................................10
High-Availability (HA) .............................................................................................................10
SQL Server Solution in High-Availability ................................................................................11
Scale-out OLTP applications .................................................................................................12
SQL Server Solution in Scale-out OLTP applications ............................................................12
Data Warehouse applications ................................................................................................13
SQL Server Solution in Data Warehouse applications ...........................................................13
Consolidation and Private Cloud............................................................................................14
SQL Server Solution in Consolidation and Private Cloud .......................................................14
Common myths or misunderstanding about Oracle RAC ..........................................................14
Conclusion ................................................................................................................................16

Why Oracle RAC Might Not Be Suitable For You

Executive Summary
Oracle RAC and its predecessor Oracle Parallel Server (OPS) have been around for about 20
years since the first release of OPS in 1992. Oracle RAC is a complex and archaic architecture
that might not be suitable for customers, especially in the cloud computing era. Newer cloud
computing applications require much larger scale (more nodes) than the practical scalability
limits of Oracle RAC. Customers should look at cloud computing architectures for their
applications, considering longer term needs (> 12 months) in application scalability in this new
cloud computing era. Microsoft has a strong vision and offerings to usher customers to the full
benefits of next generation cloud computing paradigm.
In addition, Microsoft offers database solution to meet customers requirements with much
better value than Oracle RAC. Customers need to pay a much higher cost for Oracle RAC
compared with SQL Server solution that will satisfy the equivalent requirements. The main
question customers must ask themselves is whether it is justified to deploy Oracle RAC as a
solution where it could cost more than 5X the SQL Server solution. Given that it can cost 5X
more, does Oracle RAC provide more than 5X of better performance, scalability, and highavailability than SQL Server?
We believe the answer is no, and customers should be looking at SQL Server solutions
instead. Oracle customers seem to agree and understand as Oracle RAC customers make up a
very small percentage of the entire Oracle install base (< 5%). Very few customers have
deployed Oracle RAC in production because the cost and complexity of Oracle RAC
deployment, management, and troubleshooting simply outweigh the benefits. In fact, in some
cases, customers who have implemented or evaluated Oracle RAC have since decided to
switch to SQL Server:

City of Virginia Beach: Based on our experience with Oracle RAC, we knew that a
Microsoft high-availability solution would be much easier to implement, simpler to
support, and less expensive. The licensing cost for SQL Server 2012 for our particular
configuration is about $120,000 less than for an Oracle RAC solution. - Elena Balitsky,
Team Leader, Database Administration Group
Carter Holt Harvey: Building manufacturer chose SQL Server after looking at Oracle
RAC on Linux, Oracle RAC on Unix, and SQL Server on Windows. SQL Server on
Windows has proven to be highly cost effective compared with our previous system
Chris Lowe, Architect
Powerco: When we first set up Oracle we configured Oracle RAC to support
active/active clusters, high availability and automatic failover. However, Microsoft SQL
Server has many of the same features and we can get the same redundancy from SQL
Server as we can from Oracle. Weve saved a significant amount of money, almost
$390,000 per annum, in migrating from Oracle to SQL Server. Weve been able to save
on rack space, reduce hardware, maintenance and licensing costs and have created
numerous efficiencies through simplifying the server environment Huw Griffiths,
Infrastructure Manager

Why Oracle RAC Might Not Be Suitable For You

Finally, with economy conditions requiring IT to do more with less, Oracle RAC might not be the
soundest investment. SQL Server can meet the same requirements with lower TCO (initial
implementation cost and ongoing maintenance) than Oracle RAC. Customers should contact
their Microsoft representatives and perform a SQL Server technology evaluation today.

Why Oracle RAC Might Not Be Suitable For You

Cloud Computing for Scalability

Choosing the right database technology at the right time is crucial for all organizations and plays
an important role in the companys ability to plan for current and future market directions. Over
the past several years, the concept of elastic cloud computing (the ability to scale out to
hundreds of nodes as well as down) to meet user demand has become more realistic and
affordable.
Microsoft has started to provide the tools that architects and developers need to keep their
companies thriving in a competitive marketplace. The most recent capability from Microsoft is
SQL Azure Federation. Federations in SQL Azure are a way to achieve greater scalability
(hundreds of nodes) and performance from the database tier of the application through
horizontal partitioning. Federations bring in the sharding pattern into SQL Azure as a first class
citizen. Sharding pattern is used for building many sites on the web such as social networking
sites, auction sites or scalable email applications such as Facebook, eBay and Hotmail. By
bringing in the sharding pattern into SQL Azure, federations enable building scalable and elastic
database tiers and greatly simplify developing and managing modern multi-tenant cloud
applications. An example is shown in figure below.

Figure 1: SQL Azure Federation

The figure above shows a root database Sales_DB that contains a federation. Federation
members contain ranges of atomic units (AU) and all the AUs contain the collection of all data
for the given federation key instance.

Why Oracle RAC Might Not Be Suitable For You

Federations in SQL Azure answers two common challenges for scale out by making it easier to
distribute/repartition data and provides built-in routing support that requires no downtime for
application even when repartitioning operations are moving data around in the system.
For online partitioning of data, SPLIT operation allows spreading of a federation into multiple
members of data (collection of atomic units). MERGE operation allows gluing back of federation
members data together. These operations can be easily done by administrators without
downtime.
For connection routing, all connections are established to the database containing the
federation (a.k.a. root database). This eliminates the need for applications to cache any routing
or directory information when working with federations. SQL Azure Federation guarantees that
applications will always be connected to the correct federation member regardless of any
repartitioning operation.

Few customers deploying Oracle RAC in production

In this section we will explore the consequences of the high cost implementation of Oracle RAC.
Oracle RAC and its predecessor Oracle Parallel Server or OPS have been around for about 20
years since the first release of OPS in 1992 as part of Oracle 7 release. Oracle has tried to
improve the product over that long period of time and engaged in multiple marketing campaigns
for product adoption.
Recently, Oracle released pre-installed RAC in Exadata to help overcome installation
complexity. However, Exadata does not take away complexity in ongoing management and
troubleshooting. As a result, very few customers (<5% of all Oracle customers) have deployed
the technology after evaluation because of its complexity in deployment, management, and
troubleshooting.

According to Oracle, total Oracle database customers worldwide: 380,000

According to Gartner, total production Oracle RAC customers worldwide: 15,000 (<5%)

This result shows that most customers do understand that the cost and complexity of Oracle
RAC far outweigh the benefits that Oracle claims to provide. Customers who are currently
evaluating Oracle RAC understand the risk of using a database technology that is complex and
expensive. These customers should also look at the high value solutions that Microsoft provides
to address their requirements. In fact, in some cases, customers who have implemented or
evaluated Oracle RAC have since decided to switch to SQL Server:

City of Virginia Beach: The City of Virginia Beach decided to deploy a solution based on
Microsoft SQL Server 2012 data management software. Microsoft technologies offer
maximum flexibility, easy management, and an integrated, user-friendly environment,
says Elena Balitsky, Team Leader, Database Administration Group. With Microsoft, we
can also get all the same functionality offered by other vendors at an unbeatable price.

Why Oracle RAC Might Not Be Suitable For You

Balitsky explains that she looked past Oracle, even though she had once worked as an
Oracle consultant. Previously, one of our departments deployed Oracle Real Application
Clusters for a mission-critical application and contracted with external Oracle consultants
for support, she says. However, the Oracle Real Application Clusters (RAC) solution
was costly and struggled to meet requirements. To achieve high availability for these
applications databases, Virginia Beach will take advantage of SQL Server 2012
AlwaysOn, an enhancement of database mirroring that supports as many as four
secondary databases, including two synchronous secondaries. To avoid competition for
resources between the two applications, Virginia Beach will organize each into its own
AlwaysOn availability group, a logical collection of databases that automatically fail over
even across subnets. The solution will replicate each database on a server in another
location, providing database, machine, and data-center redundancy.

Carter Holt Harvey: Carter Holt Harvey undertook an in-depth analysis to determine
which solution would have the best strategic fit within the business. Solutions
investigated included Oracle on Windows, Oracle RAC on Linux, Oracle RAC on Unix
and SQL Server on Windows. Building manufacturer chose SQL Server after looking at
Oracle RAC on Linux, Oracle RAC on Unix, and SQL Server on Windows. SAP, running
on Microsoft SQL Server Database Management System, and Microsoft Windows
Server 2008 proved to be the best strategic fit for the company. We chose the Microsoft
high availability data platform as this was the best strategic fit for the company, allowing
us to leverage commodity hardware, provide scalable and extensible infrastructure to
accommodate business growth, and deploy system upgrades and enhancements in the
future. SQL Server on Windows has proven to be highly cost effective compared with
our previous system, says Chris Lowe, Team Leader, Solutions Architects.

Powerco: Powerco is New Zealand's second largest electricity and gas distribution
company. Powerco had previously maintained both Oracle RAC and Microsoft SQL
Server platforms, which meant the business incurred the expense of supporting,
operating and maintaining two systems. Powerco sought to consolidate to a single
server platform to help simplify its IT environment, and identified SQL Server as the most
cost-effective and manageable solution. With the help of Microsoft Gold Partner, SQL
Services Ltd, Powerco has commenced migration to SQL Server. The consolidation has
enabled Powerco to eliminate significant costs, making it easier to manage and maintain
systems in-house, without the need to invest in external consultants. The migration to
SQL Server has helped Powerco to streamline its IT systems and cut total cost of
ownership by $390,000 a year. When we first set up Oracle we configured Oracle RAC
to support active/active clusters, high availability and automatic failover. However,
Microsoft SQL Server has many of the same features and we can get the same
redundancy from SQL Server as we can from Oracle. The Oracle platform was more
expensive to license, maintain and support, particularly because of the specialized
knowledge it required. It was clear that migrating to SQL Server would save money.
Weve saved a significant amount of money, almost $390,000 per annum, in migrating
from Oracle to SQL Server. Weve been able to save on rack space, reduce hardware,

Why Oracle RAC Might Not Be Suitable For You

maintenance and licensing costs and have created numerous efficiencies through
simplifying the server environment Huw Griffiths, Infrastructure Manager.

Oracle RAC is too costly

Customers constantly look to implement IT solutions that both meets their requirements and are
at the same time affordable. An Oracle RAC solution is not a good investment because it is too
costly. Rather, customers should look at SQL Server solutions as an alternative that satisfies
their database requirements. For example, SQL Server gives a comparable response in terms
of recovery time compared to Oracle RAC (see table below) while providing better overall
pricing.
Technology
Recovery Time (approx.)
Oracle RAC
30 60 seconds*
SQL Server 2012 AlwaysOn Availability Groups
<45 seconds
SQL Server 2012 AlwaysOn Failover Cluster
Seconds to minutes
*According to Oracle document entitled Oracle Database High Availability Best Practices 11g
Release 2 on recovery times.
The following will illustrate why an Oracle RAC implementation is costly in both software and
hardware terms. In order to implement Oracle RAC successfully, customers need to follow
Oracles Maximum Availability Architecture (MAA). MAA recommends having the exact same
configuration of Oracle RAC in QA, Production, and DR environment. Plus, the Active Data
Guard option is needed to ensure high availability between Production and DR. This is a
massive requirement that means additional licenses are required for Oracle RAC in QA and DR
environment as well as a different technology called Active Data Guard. In addition, special
Oracle-certified switches are required to implement Cache Fusion, a way for Oracle RAC to
share memory among member nodes. And usually redundant copies of switches are required
for high-availability. These will add to the cost of implementing Oracle RAC and every customer
should know that. The very simplified comparison table below illustrates an example of SQL
Server vs. Oracle RAC software processor cost comparison for a 2-node production
environment without the consideration of QA and DR environment (each node is a 2 CPUs,
quad core machine).
Pricing is based on price list for Enterprise Edition of SQL Server 2012 and Oracle 11gR2.
Component

SQL Server
Oracle RAC
Solution
Solution
Core Database
USD$115K
USD$380K
HA option
Included
USD$184K
Total
USD$115K
USD$564K
Note: The cost of the Oracle solution will be considerably higher if we factor in QA
and DR environment where Oracle recommends Active Data Guard
(additional USD$10K per processor) and an exact replica of Oracle RAC.

Why Oracle RAC Might Not Be Suitable For You

Customers need to pay a much higher cost for Oracle RAC compared with SQL Server
solutions that will satisfy the equivalent requirements. Another question customers must ask
themselves is whether it is justified to deploy Oracle RAC as a solution where it cost more than
5X the SQL Server solution. Does Oracle RAC provide more than 5X better performance,
scalability, and high-availability than SQL Server? We believe the answer is no and customers
should be looking at a SQL Server solution instead.

Microsoft provides equivalent functionalities with lower TCO

Microsoft SQL Server is known to provide great performance and scalability in the enterprise.
The latest release of SQL Server 2012 provides many major enhancements. SQL Server 2012
is a cloud-ready information platform that will help organizations unlock breakthrough insights
across the organization and quickly build solutions to extend data across on-premises and
public cloud, backed by mission critical confidence.

According to analyst firm IDC, SQL Server is an enterprise-level database platform and
is more competitive with other platforms. As an example, SQL Server 2012 includes
AlwaysOn providing high availability, disaster recovery, and active secondaries
(Active/Active).
According to real-life customers study from Alinean, it takes fewer database
administrators to manage mission-critical SQL Server databases compared with Oracle
databases. The study concluded that Total Cost of Administration (TCA) for SQL Server
databases is much lower (~5X) than Oracle databases.
According to the National Institute of Standards and Technology (NIST) and analyst firm
ITIC, SQL Server has the lowest number of security vulnerabilities among major
database vendors (Oracle, IBM DB2, MySQL) in the last 10 years.
Finally, SQL Server 2012 Enterprise Edition provides more advanced functionality outof-the-box, without the need to buy additional options or separate products compared to
Oracle in the area of high availability, disaster recovery, advanced security, data
warehousing, advanced compression, manageability, non-relational data, advanced
business intelligence, master data management, data quality, and complex event
processing.

In the following sections we will examine common scenarios for database solutions, outline the
main reasons Oracle RAC is not suitable for these scenarios causing few customers to deploy,
and provide the best SQL Server solution.

High-Availability (HA)
In this section we will examine the scenario of high-availability (HA). Usually this scenario
involves having redundant computers or nodes which are then used to provide the database
service when one of the computers or nodes fails. Usually the HA system detects hardware or
software faults and immediately transfers all the service to the standby server without
administrative intervention, a process known as failover.
10

Why Oracle RAC Might Not Be Suitable For You

Oracle RAC is not a good solution for HA scenario. It is known to have a stability issue that
happens in Linux environment where node is randomly evicted from the cluster for no apparent
reason. This creates additional downtime risk for customers and extra burden for the DBAs,
because the need to monitor the RAC cluster more closely requires installing an additional
monitoring tool from Oracle. The most recent news about an outage experienced by major bank
JP Morgan Chase shows the seriousness of database outages for businesses.
In addition, Oracle RAC uses many shared components such as processes (cluster ready
services) and hardware (voting disk and SAN) that has a single point of failure. This means the
entire cluster will be down if any of those components fails. It is also important to note that
patching Oracle RAC almost always requires shutting down the entire cluster. The most recent
blog posting by EMC engineers showed the role of Oracle RAC in enterprise database
deployments becoming less every day.

SQL Server Solution in High-Availability

On the other hand, SQL Server 2012 provides a new capability called AlwaysOn. AlwaysOn is a
new integrated, flexible, cost-efficient high availability and disaster recovery solution that was
built on a very stable failover clustering platform. AlwaysOn Failover Cluster instances provides
server-level redundancy on a certified Microsoft Cluster Services configuration and enables
seamless failover capabilities in the event of a CPU, memory, or other non-storage hardware
failure by sharing disk access between nodes and automatically restarting SQL Server on a
working node in the event of a failure. AlwaysOn Failover Cluster instances support multisite
clustering across subnets, which enables cross-data-center failover of SQL Server instances.
Also new, AlwaysOn Availability Groups greatly enhance the capabilities of database mirroring
and help ensure availability of application databases, and they enable zero data loss through
log-based data movement for data protection without shared disks. AlwaysOn Availability
Groups provide an integrated set of options including automatic and manual failover of a logical
group of databases, support for up to four secondary replicas, fast application failover, and
automatic page repair.
SQL Server 2012 also supports deployments on Windows Server Core, a minimal, streamlined
deployment option for Windows Server 2008 and Windows Server 2008 R2. This operating
system configuration can reduce planned downtime by minimizing operating system patching
requirements by as much as 60 percent according to internal Microsoft study. SQL Server 2012
AlwaysOn can facilitate rolling upgrades and patching of instances, which helps significantly to
reduce application downtime. Enhanced support for online operations like LOB re-indexing and
adding columns with default values also helps to reduce downtime during database
maintenance operations.

11

Why Oracle RAC Might Not Be Suitable For You

Scale-out OLTP applications

In this section we will examine the scenario of scale-out online transaction processing (OLTP)
applications. Scaling usually refers to the process of adding resources to a tier so that it can
handle increased workloads. Scale-out increases the processing power of a system designed in
a modular fashion, such as becoming a cluster of computers, by adding one or more additional
computers (also called nodes) to the system. Scale-out usually has some initial hardware cost
advantages eight of four-processor servers generally cost less than one 32-processor server.
But this advantage is often cancelled out when licensing and maintenance costs are included.
Oracle RAC is not a good solution for scale-out OLTP scenarios. Oracle RAC is not ideal for
database operations such as bulk load, long-running transactions, and high-update applications
because those operations require a bigger buffer. Overall performance will suffer because
Oracle RAC needs to transfer large amount of buffer among the nodes through the interconnect
Cache Fusion. Another type of application that uses a lot of serialization (such as Oracles
sequence request and index update) will require a waiting period by the rest of the nodes and
the operations cannot be scalable.
According to an Oracle OpenWorld presentation customers need to redesign their applications
to use hash partitioning to mitigate that issue. Oracle RAC best practice says that it cannot
make a non-scalable application scale and suggests data partitioning to minimize the traffic
inside the interconnect. Coincidentally, this approach is the same of using Data Dependent
Routing (DDR) and customers do not need to pay for the extra cost of Oracle RAC to implement
DDR. Moreover, Oracle documentation states that an application will not scale on Oracle RAC if
it does not scale on a SMP system.

SQL Server Solution in Scale-out OLTP applications

SQL Server provides a technology called Distributed Partitioned View (DPV) which adds a
scale-out capability to the database backend. This implementation is designed for high-end
OLTP applications with update-intensive applications.
SQL Server also provides Data Dependent Routing (DDR), where the data is partitioned among
databases. In this architecture, SQL Server understands how the data is partitioned, and
decides where to go to find the data. DDR requires a data layer that understands how to locate
and access data entities from the database where it is stored. The DDR solution is designed for
high transaction volumes, and therefore it is a clear winner for applications with very high
update frequencies. Other SQL Server architectures that support scale out are Scalable Shared
Databases and Peer-to-peer replication.
In order to scale database applications to hundreds of nodes and supporting an elastic cloud
computing paradigm, SQL Azure Federation provides a great way to bring sharding pattern into
existing database in order to do scale out. With Federations, database tiers can be elastically
scaled-out much like the middle and front tiers of the application based on application workload.
12

Why Oracle RAC Might Not Be Suitable For You

Using federations, applications can expand and contract the number of nodes that service the
database workload without requiring any downtime.

Data Warehouse applications

In this section we will examine the scenario of data warehouse (DW). Usually this scenario
involves pulling together a large amount of data from different sources in order to facilitate
decision support system (reporting, analysis, and business intelligence). Data warehouse
applications are quite different from traditional online transaction applications (OLTP) which are
mostly read-only operations that contain table-scan operations, usually involving joining multiple
large tables in its query, and returning large datasets to support reporting.
Oracle RAC is not a good solution for data warehouse scenarios. The issues that Oracle RAC
has in the scale-out OLTP scenario will be magnified greatly in the data warehouse scenario. In
other words, large dataset queries such as table-scan will suffer greatly under Oracle RAC
because it will clobber the interconnect Cache Fusion. The inter-node parallel query on a RAC
cluster system has very high overhead because the parallel query coordinator must
communicate with the slave processes over the network and large table results will have to be
transferred across the interconnect bus.

SQL Server Solution in Data Warehouse applications

SQL Server 2012 provides a technology called xVelocity Columnstore Index that will
substantially accelerate common data warehouse queries. Columnstore indexes group and
store data for each column and then join all the columns to complete the whole index. The SQL
Server query processor can take advantage of the Columnstore layout to significantly improve
query execution times (on the order of 10X 100X).
SQL Server also provides the Fast Track Data Warehouse offering that accelerates deployment
of SQL Server data warehouses using scalable reference architectures from HP, Dell, and Bull.
This reduces cost, saves time, and reduces risk with reliable, pre-tested hardware and best
practices for warehousing.
For IT decision makers with the most demanding data warehouses (hundreds of terabytes in
size), SQL Server Parallel Data Warehouse (PDW) offers massive scalability to hundreds of
terabytes and high performance through a Massive Parallel Processing (MPP) architecture.
Parallel Data Warehouse offers flexibility and choice with leading hardware vendors such as HP
and Dell. In addition, through customized connectors for Hadoop, Parallel Data Warehouse
enables customers to analyze structured and unstructured data in a Data Warehouse or
Hadoop environment.

13

Why Oracle RAC Might Not Be Suitable For You

Consolidation and Private Cloud

In this section we will examine the scenario of server consolidation or simply consolidation.
Consolidation is the act of gathering applications from multiple physical locations to a single
location. It can occur either by installing all of those applications onto a single physical machine
or by creating multiple virtual computers (virtualization) on one physical set of hardware. This
results in better utilization of available hardware capacity. Modern IT servers can handle
significantly greater workloads, meaning that it is now possible to consolidate servers without
sacrificing performance or availability. The costs associated with buying and maintaining servers
are reduced and administration is more efficient, which in turn yields further savings. The new
architecture of Private Cloud provides resource pooling, scale on demand, and self-service in
consolidated databases.
Oracle RAC is not a good solution for the consolidation scenario. Usually in the consolidation
scenario customers will host multiple tier 2 applications with smaller database sizes and/or a
smaller number of concurrent users and/or smaller number of transactions compared to tier 1
applications. Conversely, customers usually prefer a dedicated system for tier 1 applications
because they are the most important and have the highest availability requirements. Paying for
very expensive technology such as Oracle RAC to host tier 2 applications does not seem to be
the greatest investment choice for customers. Customers should be using more targeted and
less expensive technology such as SQL Server instead. Moreover, consolidation introduces
additional management complexity on top of already very complex Oracle RAC manageability.

SQL Server Solution in Consolidation and Private Cloud

Microsoft offers a comprehensive solution for optimizing your databases for Private Cloud.
Optimizing SQL Server for Private Cloud solutions will help ensure that your computer, network
and storage resources are used efficiently, reducing physical footprint, as well as capital and
operational expenses. It will give you the ability to scale your resources efficiently and deploy
the resources on demand without compromising control.
To speed up deployment, Microsoft and HP provide a ready-to-deploy appliance called HP
Enterprise Database Consolidation (DBC) appliance. DBC is a complete, ready-to-use solution
for consolidating and optimizing database workloads to gain the full benefits of a private cloud.
DBC is the first appliance in the industry which consolidates and manages thousands of
databases, integrates hardware, software and support and is scalable to meet changing
business needs.

Common myths or misunderstanding about Oracle RAC

Because of long and extensive product marketing by Oracle, many customers have
misunderstandings about the real capabilities and limitations of Oracle RAC. We list some of the
common myths about Oracle RAC by sharing the truth behind its market perception.
14

Why Oracle RAC Might Not Be Suitable For You

Myth: Oracle RAC has 100% availability and no failover downtime. In reality, according
to Oracle document the failover time for Oracle RAC is around 30-60 seconds depending
on configuration and workload. In other words, when an Oracle RAC node fails, the cluster
needs some recovery time to perform rebalancing processes that includes the following:
Redistribution of resource management to the surviving nodes.
Recovery of database blocks by reading the redo log of the failed node.
Collect all database blocks that need to be recovered.
Perform the first step of database recovery process called rolling forward where all
the collected redo logs are applied to the database.
Perform the second step of the database recovery process called undo where all the
uncommitted transactions are applied to the database.
It is important to note that the cluster is not available during most of the rebalancing
process. In fact, to achieve maximum availability, Oracle recommends customers use
another technology called Data Guard in addition to Oracle RAC.
Myth: Oracle RAC has gone mainstream. Gartner published a report that Oracle RAC
has gained mainstream implementation. In reality, very small percentages (<5%) of Oracle
customers are deploying RAC after 20 years of launching the technology.
Myth: Oracle RAC has no maintenance downtime. In reality, few Oracle-certified
patches for rolling upgrades are available. Moreover, rolling upgrade of patches is currently
available for one-off patches only and it is not available for patchsets. In real life situations,
very few Oracle DBAs will patch their database using one-off patches but rather by
applying patchsets. Again, to achieve maximum availability, Oracle recommends another
technology called Data Guard for applying patchsets in rolling upgrade fashion according to
Oracles documentation. It is also important to note that major version upgrades are also
not supported according to Oracles documentation.
Myth: Oracle RAC provides linear scale out. In reality, as nodes increases, more Cache
Fusion traffic will occur among nodes and performance degrades. This prevents Oracle
RAC from scaling linearly. Oracle also provides many ways to tune Oracle RAC by
changing the application. In the best scenario using application tuning such as partitioning,
adding nodes will achieve up to 80% of scalability. However, this requires application
changes and adds to its complexity.
Myth: Any applications will run in Oracle RAC without modifications. In reality,
according to an Oracle OpenWorld presentation on Oracle RAC Performance Experts
Reveal All, any serialization operation will seriously impact the performance of the Oracle
RAC cluster. For example, an Oracle sequence request and an index update will require a
sequential waiting period. In other words, this operation cannot be scalable regardless of
how many nodes are in the cluster. In order to mitigate this, Oracle recommends customers
re-design their applications by using hash partitioning or re-write their applications without
using sequences.

15

Why Oracle RAC Might Not Be Suitable For You

Myth: Oracle RAC provides failover transparency. In reality, application code must be
modified to be able to re-run statements that occurred after the last commit to restore other
elements of an active database connection, such as active DML transactions and serverside package state. It is also important to note that failover transparency feature in Oracle
RAC called Transparent Application Failover (TAF) works only for SELECT queries and not
INSERT or UPDATE or DELETE queries.
Myth: Oracle RAC will be able to scale my applications more than SMP. In reality,
according to an Oracle RAC best practice white paper applications will not scale on Oracle
RAC if they do not scale on SMP. In other words, Oracle RAC cannot make a non-scalable
application scale. Scalability is a direct function of the degree of contention introduced by
the application for system resources and data. If the application wont scale in moving from
a 4 processor to an 8 processor SMP configuration, then it certainly wont scale going from
a single 4 processor box to a cluster of 2 4 way boxes. A similar reference is found in
another Oracles document: Oracle 11g Oracle RAC administration & deployment guide
which says that if an application does not scale on an SMP system, then moving the
application to an Oracle RAC database cannot improve performance.
Myth: Oracle RAC is cheap because Oracle Standard Edition comes with Oracle
RAC. In reality, although Oracle Standard Edition comes with Oracle RAC, Standard
Edition is positioned to be a low-end database and has hardware and scale limitations. In
fact, Oracle Standard Edition lacks the ability to use some of the more standard features in
the database such as compression, partitioning, advanced security, and Active Data Guard.
This makes an Oracle RAC implementation on Oracle Standard Edition incomplete and it
does not support DR environment for maximum high-availability.

Conclusion
Oracle RAC and its predecessor Oracle Parallel Server (OPS) have been around for about 20
years since the first release of OPS in 1992. Oracle RAC is a complex and archaic architecture
that might not be suitable for customers, especially in the cloud computing era. Microsoft has a
strong vision and offerings to usher customers to the full benefits of next generation cloud
computing paradigm. In fact, Microsoft SQL Server offers database solution to meet customers
requirements with lower TCO than Oracle RAC in terms of initial implementation cost and
ongoing maintenance. In some cases, customers who have implemented or evaluated Oracle
RAC have since decided to switch to SQL Server.
For more information:
SQL Server Web site http://www.microsoft.com/sqlserver/en/us/default.aspx
SQL Azure Federation Web site http://msdn.microsoft.com/enus/library/windowsazure/hh597452.aspx

16

Why Oracle RAC Might Not Be Suitable For You

SQL Azure Federation Blog http://blogs.msdn.com/b/cbiyikoglu/
Did this paper help you? Please give us your feedback. Tell us on a scale of 1 (poor) to 5
(excellent), how would you rate this paper and why have you given it this rating? For example:
Are you rating it high due to having good examples, excellent screen shots, clear writing,
or another reason?
Are you rating it low due to poor examples, fuzzy screen shots, or unclear writing?
This feedback will help us improve the quality of white papers we release.
Send feedback.

17