« Thin Provisioning Part II: Why TP Works Well for Oracle (Sometimes) | Main | Direct NFS on EMC NAS »

September 18, 2007


Kevin Closson

"Given the price difference, a single instance solution which works even a third as well for a third the price is a fairly good deal. That would assume that RAC did not cost you more in terms of CPU, memory and such. Which it does."

...What is "a third the price?" Are you comparing a single instance of SE to EE+RAC? That would be 25% the cost. Why not compare SE to SE RAC?

...I also don't get why you are comparing a 4-node RAC cluster of 4-socket servers to a single node with 8-cores? Why not compare the same number of cores with the same software across the board?

The Oracle Storage Guy's response:

There are three questions here. First, why 1/3 the price? Because:

10g RAC EE = $60,000 per CPU
10g SE single instance = $15,000 per CPU

So you are right, that's actually 1/4 of the price. OK, I was using artistic license. What can I say? Seriously, your point is well taken. The correct price would be 25%. Thanks for pointing this out.

Second question: Why not compare RAC to single instance using a similar number of cores?

Because our default testbed (what we call OraPod2) is a 4-node RAC. But I suppose I could include that test as well. So this point is well taken also.

Third question: Why not compare SE RAC? Because it is too restrictive in terms of CPU and nodes for any equipment I have access to. SE RAC has a limit of 2 CPUs per node and 2 nodes. In other words, a total of 4 processors per cluster. I don't have a testbed that looks anything like that. Nor do I regard this as a terribly interesting configuration for running Oracle.

Thanks for your comments, Kevin! Keep them coming!

Kevin Closson

I didn't phrase the one of my questions the way I should have. Let me try again. When you make the price comparison you use Std Edition on one side of the equation and EE+RAC on the other. I would argue that if dollars are in the equation, you should limit the mathematics to EE.

Although you dismissed SE just because it can't support the 4-node (32 core) cluster. You stated that SE is limited to "2 CPUs per node and 2 nodes" which is incorrect. Std Edition (as of Feb 2007) is limited to a total of 4 **sockets** so you could compare the 6950 running SE to a 2 node cluster of 2900s running SE RAC. Doing so would be an apples to apples dollars comparison since RAC is built in to the cost of SE.

In the end, I shouldn't expect to see any actual numbers since you know Oracle's license terms.

Also, you state:

"High availability. This is the heart and soul of RAC. You can encounter a failure of any component, and the overall database will stay up and accessible to users."

This is not true. RAC is multiple instances of one database. You can't suffer losing the system tablespace. You need DataGuard for that.

Travis Roberts

If you're oracle, the RAC tax seems like a really good thing, I kind of printing press for printing money.

Comment by The Oracle Storage Guy:

LOL. Of course, the RAC tax is a CPU cost, not a money cost. Just to clarify for other readers. I am sure you already knew that. :-)


I'm a bit surprised by the "500 transactions/second" comment above. I have a customer who is clicking at 17000 transactions/second (online gaming/gambling in Europe). They are not using RAC, not even Oracle.


That does not surprise me. You have to remember the purpose of our program. We are targeting what EMC calls the "Mid-Sized Enterprise" market. These are customers with smaller configurations.

This is actually a much more challenging market than the Large Enterprise market, basically Fortune 1000 companies. With smaller customers, the margins are smaller and each deal must be much tighter. That is why we create validated configurations. That way the configuration can be deployed less expensively.

Anyway, if you look at our configurations, you will notice they are quite modest in size. This is because that is the sweet spot in the market for customers of this size.

I should also point out that these are TPC-C style transactions, not simply Oracle transactions. TPC-C style transactions include lots of reads and think time. They are not comparable to normal database transactions.



Hi Jeff,

Most shops have enterprise agreements with Oracle which results in huge discounts. Also Oracle is aggressive when it comes to RAC and licensing. So licensing is not really indicative of the real cost.

RAC is low on initial hardware cost when compared to Big-Iron, but a lot more expensive in terms of people and maintenance.

RAC by nature is complex to manage and support when compared to a single instance. You can afford to get sloppy with a single instance not with RAC.

RAC requires good data modelers, DBA's and SA's not DBO's/SO's. This is the real challenge in today's cost challenged environment.

You also mention Dell 2900 with 48GB Memory. I would have assumed a modest config is a Dell 2950 with 16GB of RAM. When you factor in Dev/QA/UAT/Prod, then the cost of RAC really starts adding up.

RAC makes a lot of sense when you have a big warehouse or an ERP application wherein scaling vertically is limited.




I was personally present recently in which Oracle priced the reference architecture produced by our program, consisting of a four way RAC using Dell PowerEdge 2900s (each having two quad-core Intel Pentium Xeon processors). The list price of this configuration was $960,000. The price quoted by Oracle for this configuration was $740,000. While it may be true that the Fortune 1000 companies have enterprise level pricing agreements with Oracle that result in significant discounts, remember that I do not work with such companies. I work with the commercial market, consisting of companies with revenues of less than $1 billion. These companies do not have such agreements, from what I can tell. At least, none of the ones that I have been involved with have. Admittedly, not a scientific sample, but still a fairly large number of companies of this size.

It is also true that about 80% of the business activity, and a similar percentage of IT spending, are in companies of this size. So this represents the majority of companies which are out there buying software and hardware in our environment.


Neil Greene

Your comments on "To RAC or Not to RAC" have a number of technical accuracies. Unfortunately, that is it, it is measuring technology and does not include the non-technical aspects of application deployments and architecture design. Lets look at the full life cycle of an application solution.

What happens today is the following:

1) The customer contacts a hardware vendor to SIZE their application. This is usually done PRIOR to knowing the actual architecture. The customer has a budget and it is the "size of the box" that is outlined as the measurement of risk. So, what the customer does, is they purchase FAR MORE hardware then needed. However, the problem is worse. This is done for each solution, for every project. So, for every project that acquires budget, you have an over purchase of hardware.

This is an industry accepted practice however. Not until critical mass data center expansion, and the rising cost of power have CIOs needed to start looking at how to make their data center green(er), or at least align the roll out of hardware with the growth of the business.

In my opinion, selling RAC as "cheap small boxes" is too big of a leap of faith for an IT director. Oracle should have hammered the fact of "aligning" IT cost with the growth of the business. This is a goal and objective of CFOs, CIOs, management and stock owners.

2) The purchase of these island systems allow for vertical growth only. No horizontal scalability. Again, this does not resonate with customers. They now know and agree they have pockets of utilization. And they know and agree that these pockets of utilization are uneven and result in critical systems being over-utilized and supporting systems under utilized. The point being, with regards to database architecture their business has purchased hardware and licenses to run their business on 300 cpus, but realistically during peak operations they run their business on island pockets of cpus. Meaning, the business is over-invested now in hardware, license costs, support cost and maintenance. Some describe the resolution of this as "consolidation" but we need to be careful what terms we use because they come with a perception. It is true, with RAC we can consolidate our cpu power consumption needs, but if we can this something else....it takes on a more accurate perception and not one of simply deploying VMware.

3) So, our customer has a legacy ERP system which is now on a piece of old hardware and no room for vertical growth. So, what do they do? They spend another $250k in FTE time/effort away from being innovative in their core business just to move to a bigger box. Great! Another $250k in time, effort and resolution just to move the same application to a bigger server. So, we give the hardware vendor more money and go buy a new $750k box. Well, not zero...they are getting to new cpu. But, this could have easily been done by running on CPU already invested in the compute farm that are not in use. A cost that has ZERO business benefit. All we do is move it to a newer box. In some cases, the customer makes a binary move by selecting a new hardware vendor and operating system....this introduces risk because now we need to validate our application. This has a higher cost with higher risk.

Keep in mind, some of these "boxes" we are now moving are not just running a single application. I have been in large F100 customer where they may have consolidated 2, 3 or 12 core applications. So now we need to validate and verify the move of several critical applications. Five years ago, I was on a project of this magnitude and the internal cost was over $1m to move network ip assignments and test core applications. JUST TO GET TO MORE CPUS and RESOURCES. THIS IS THE TRUE COST OF INFORMATION SYSTEMS!!! These hidden cost, and lack of internal process controls like ITIL are what we really should be taking into consideration.

4) In this architecture design, it has also been acceptable to run active/passive hardware clusters. Yes, still today customers have active/passive hardware clusters where the second machine that they power, and pay annualized maintenance on is NOT RUNNING ONE TRANSACTION FOR THE BUSINESS. Now, here is another accepted IT cost, that has ZERO benefit to the business. Factor this cost into your equation as well.

4) This moves to larger hardware frames change the application architecture. Changing the architecture is the most EXPENSIVE move an IT group can do and the most risky. And often with no benefit. The optimal solution is to have an architecture that supports the business change of growth, mergers and acquisitions, and dynamic changing need for compute resources.

I am not saying everything needs to be RACed. But I would. I would layout a single architecture that allows me to easily scale and get to compute resources without having to change my architecture or forklift my systems. And I would do so by looking at my database compute requirements and not a single application. This is where the problem starts by isolating single environments. With RAC, I can deploy a database architecture that grows and shrinks with my business and keeps my IT cost in alignment with the business. Have you ever seen an E12k that is not running. Its awful, I have and that is a HUGE cost.

Dan Norris

This is a great thread and I'm more excited than ever that I'm putting together a debate at Collaborate 08 (April in Denver, http://www.ioug.org/collaborate08/) this year on this very topic. I would love to talk with those interested in participating in the debate panel as I'm still forming the list of panelists. The debate is titled "To RAC or Not To RAC: What's Best For HA?" Please contact me (dannorris|at|dannorris|dot|com) if you're interested in participating.

Neil Greene

Assuming I would be an interested participate, my response is I would love to be on the panel. It is a topic I see and hear a lot from customers just now starting in Oracle technology to existing customers.


why not talk about the soon to be approved Oracle VM and how you can improve the cost performance equation by building a 2 node physical cluster with 16 virtual CPU cores.

just a thought.


Oracle Support

Just a quick thought. I just wanted to comment quickly. Reading through some of the RAC problems and costs it seems as their is no 'one source' answer. I just wanted to let you guys know, that our company specialises in Oracle technology providing all kinds of support for all oracle applications.

John Moffett

In reference to your RAC or not RAC article, there are many reasons for not implementing a traditional federated database design as proposed by Microsoft. Most of the problems are associated with how to access shared data. The classical workarounds for a federated approach involve creating local versus remote schemas and data, union all views over DB*Links, data replication, and so on. Does your approach with an n-node 11g Oracle SE design running on VMware get around most of the data sharing problems inherient in the federated design?



No, it does not. A federated scheme is required. However, many customers find this fine. For example, I describe in the blog a customer who is a fortune 100 company with many 1 and 2 U high single-instance database servers. Obviously, each of these servers is already an island of data. Consolidating them on RAC is a much more daunting challenge than simply doing a P2V into a VMware context.

Compare Prices

"High availability. This is the heart and soul of RAC. You can encounter a failure of any component, and the overall database will stay up and accessible to users." - This is also the main reason why we are using RAC for years now.

The comments to this entry are closed.

Powered by TypePad
View Jeff Browning's profile on LinkedIn

disclaimer: The opinions expressed here are my personal opinions. I am a blogger who works at EMC, not an EMC blogger. This is my blog, and not EMC's. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.