« Why Oracle is the most interesting technology space for EMC | Main | To RAC or not to RAC (reprise part 2) »

October 15, 2008


Alexander 'sure' Podkopaev

Hmm... Looks not quite fair comparision to me...
You should explain how did You scale-out virtualized Oracle SE without using RAC?

Where're lots of consequences as I see in "scaling out with ESXi":
1) No RAC - no FAN (Failure App Notification)
2) No RAC - no load balansing
3) Single ESXi host - SPOF


In terms of 1 and 2, I would regard those as fair statements. That is part of the downside of ESX at present. Version 4 of ESX, coming out early next year will mitigate point 2, as the VMs will then be able to run over multiple ESX servers simultaneously, and thus will have true HA.

On the third point, that is incorrect. VMWare HA Cluster provides clustering and thus a single ESX server is not a single point of failure. My hardware diagram was a bit misleading though, and I can see where you got that impression. I will correct this.


Nik Simpson

I'm not 100% clear on the hardware configurations here, the two network diagrams are not clear (at least to me). Here's where my question lies, the the RAC configuration looks pretty straight forward, i.e. 4 x PE 2900 running RAC. But the virtualization solution isn't so clear, it mentions a VMware cluster, but in the rack diagram above only one machine is shown running VMWare ESX (the PE 6950), so what machines were in the cluster the PE6950 + the 4x PE 2900s?

Also, is it really an apples-to-apples comparison from the DB perspective, i.e. with RAC you have a single DB image, do you still have that with the VMWare cluster, or was the DB chunked up to put small pieces on each VM?



Sorry, but you are absolutely correct that the hardware diagram is misleading. I will correct this. Thanks very much for pointing this out.

The ESX cluster consisted of the same Dell PE 2900s as the RAC cluster. Thus, the same exact hardware was used for both. The Dell PE 6950 was used only for hosting client VMs which ran the load generators.


Matthew Watson

So how does this work, does Oracle SE see the 4 machine VM cluster as a single machine with lots of CPU's?



As shown in the network diagram on the post, eight different Oracle Database SE instances are running on the cluster, two on each ESX host. Thus, this is a scale-out, otherwise known as a "federated" database solution. I am putting up a new post which will make this more clear.



I am a bit unclear how the licensing under VM is less expensive than RAC. You have used SE on VM whilst EE on the RAC. Also, Oracle licensing would count all of the physical CPUs of the machine under VM.



Correct, but the effect of VMware will be to provide HA clustering which requires RAC on the Oracle side. This requires EE. Data Guard and RAC are the two components of the Oracle stack that typically require the use of EE. The remaining components are far less common.

Further, as you say, the licensing of Oracle products occurs on the physical CPU, not the virtual CPU, making VMware more efficient. The effect of VMware virtualization will be to make the CPU utilization higher, by efficiently utilizing the CPU for multiple database servers. In addition, VMware HA Cluster uses less CPU as overhead than RAC does (the so-called RAC tax).

The combined effect is to reduce the Oracle license cost on a per-transaction basis.

Rob Bergih

Wouldn't it be better to compare Standard Edition with RAC and Standard Edition with VMware HA (or maybe now with VMware FT) vs. doing it with Enterprise Edition?





Not sure what you mean here. RAC required EE, at least for more than 2 CPUs in the entire cluster.

Vladimir grigorian

I agree with Jeff above. There are a lot of RAC features Virtualization cannot even touch. As a pure HA solution it may may offer some value (especially considering cost difference), but HA is not all businesses care about.
BTW, I built a few 11gR2 RAC simulators myself at http://vgrigorian.com .
Vladimir Grigorian.

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.