« VMware Partner Exchange 2011Recap and Content | Main | A watershed benchmark moment »

February 23, 2011


Feed You can follow this conversation by subscribing to the comment feed for this post.


Hi Chad

Interesting document. The first table on page 12 decribes the Cisco UCS blades as having 18*8GB DIMMS for a total of 96GB RAM, which is incorrect as 18*8 is 144.

Also it would have been interesting to see some detail on the EMC vSphere setup for the solution, even at a high level.


Andrew Fidel

They could be using online sparing so 12*8GB online and 6*8GB as spares.

Don Sullivan

The WP Link appears to be broken, can you send it to me directly?

Erik H.

How did you go with Oracle licensing in this environment? Was that factored into the cost savings (inc or ex)? I have seen people license by cluster and then run multiple VMs of Oracle DB and Apps side by side, which saves a ton of money but is not Oracle best practice. VMware doesn't appear to have any hard guidance here. Seems the balance here is license as many ESX hosts as you can afford to be able to use the most features. (DRS, HA, SRM, FT etc..) The less you spend the more you need to turn off to comply with Oracle. SRM is first to go, then DRS, then FT and HA. Until you end up with a small cluster. At which point you've got feature parity with OVM. (sort of - it doesn't offer much). Curious how EMC dealt with this one. Is there a magic cost/benefit crossover point? - Erik.



That is a typo. The memory config on our B200's is 12 x 8 and not 18 x 8.

- Ken


interesting to see this in large scale. I had similar running on smaller scale a few years ago. 3 RAC nodes (2 stand alone & 1 virtual) + 9 virtual JDE servers (logic, development & web)

we ran into performance issues on the DB side. Our primary DB was about 4TB & the development/test were about 2TB each. The problem with the virtual RAC server was shared CPU with other VM guests. Thus the VM was only used a failover, & not as primary node.

Each of our physical RAC nodes had 16GB & 1 CPU (2 cores) (to keep the per CPU licensing cost down)

I'd be interested to know how the RAC nodes there actually are. (document only says 2 are shown)

(everything was connected up to a cx4-240 w/ FC disks using ASM)


I'd be curious to learn how you got on with Orcale licenses also.

I find it rather appalling that Oracle will allow limited license purchases when you carve up a Sun system with Containers (zones), which by all accounts are a very fluid and dynamicly resizable object; And yet they don't view a VM under ESX which in most cases is fixed cpu/memory count (without a reboot) object in the same way.

MS was for a long time the same when it came to SQL server, but at least they've got with the times and adjusted thier model to meet virtualised environemnts. As Erik mentioned it seems the only way to lisence Oracle on ESX/VM's is to fully license the hosts and it just gets messy when you want DRS,SRM,FT and HA in the picture.

Jay Weinshenker

Erik H, needcaffeine, Andrew: In my Oracle vSphere environments, we tend to license a couple of vSphere hosts (yes, the entire host) for Oracle and then host all the Oracle DBs on those hosts. Same with other products like Oracle Weblogic or Internet Application Server that is processor based. This can either be a dedicated "cluster" of hosts inside your overall vSphere cluster (pre vSphere 4.1 affinity / DRS rules) or just dedicated hosts (using DRS affinity / anti-affinity rules). We then use DRS, HA, FT, in that cluster to ensure best performance. Using things like resource shares and SIOC, we're able to ensure our Production VMs on those hosts get the resources they need while still allowing non critical systems to get resources.

Yes, you do fully license at least two vSphere hosts to get the best of both worlds. One thing I've done before is to turn off half the sockets in each host via the BIOS so I can still use just 1 physical host's worth of Oracle CPU licenses but can still get the advantages of DRS,HA,FT on two physical hosts. CPUs are *way* cheaper than Oracle licenses. Of course this means none of the VMs need more than that halved amount of sockets, but that isn't a true limitation in many of the environments I've seen.

Many of the high CPU utilization Oracle systems I've seen greatly benefited from using Oracle tuning features like SQL Profiles to reduce the CPU (and Disk I/O) utilization. This in turn eliminated the need to buy more processor licenses.

Steve Lewis


Hate to tell you that turning off CPUs in the BIOS does not relieve you of your contractual obligation to license them.

I'm not defending Oracle's licensing policy here, just describing it: their license policy states clearly that you must license a product for all the processors physically installed in the server on which that product runs, unless some of those processors are explicitly made unavailable to the product via an approved "hard partitioning" method.

As of today, disabling CPUs in the BIOS is not an approved hard partitioning method. Physically removing a processor from the server is.


The comments to this entry are closed.

  • BlogWithIntegrity.com


  • The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Dell Technologies and does not necessarily reflect the views and opinions of Dell Technologies or any part of Dell Technologies. This is my blog, it is not an Dell Technologies blog.