Last week (during EMC world) a discussion came up on Twitter around Oracle licensing and whether Oracle would support CPU affinity as a way to license subsets of a physical server these days.
@sam_lucido @EMCOracle @CacheFlush is #VMware and accepted hypervisor for #oracle hard partitioning these days? thought they weren't
— Andre karlsson (@karlsson_andre) May 7, 2014
@karlsson_andre @sam_lucido @EMCOracle Good topic for my next blogpost maybe? 😉
— Bart Sjerps (@CacheFlush) May 7, 2014
Unfortunately, the answer is NO (that is, if you run any other hypervisor than Oracle’s own Oracle VM). Enough has been said on this being anti-competitive and obviously another way for Oracle to lock in customers to their own stack. But keeping my promise, here’s the blogpost 😉
A good writeup on that can be found here: Oracle’s reaction on the licensing discussion
And see Oracle’s own statement on this: Oracle Partitioning Policy
So let’s accept the situation and see if we can find smarter ways to run Oracle on a smaller license footprint – without having to use an inferior hypervisor from a vendor who isn’t likely to help you use it to reduce license cost savings…
The vast majority of enterprise customers run Oracle based on CPU licensing (actually, licensing is based on how many cores you have that run Oracle or have Oracle installed).
An important note here is that an ELA or ULA (Enterprise License Agreement / Unlimited License Agreement)
is also based on the number of cores in use. Don’t let people tell you that with an ELA/ULA you can deploy as much Oracle as you want without paying extra.
(more info here: Oracle ULA contract agreement risk factors)
I’ve compared ULAs to the debt crisis in Europe and USA United States debt-ceiling crisis of 2013 & Eurozone crisis
By allowing people (or governments, or companies) to spend (or deploy) without limits now (hence Unlimited License Agreement) and paying later, you may find yourself in a lot of future trouble.
Reducing license spend
So one way to reduce (current and/or future) license spend is to reduce the number of licensed cores. It’s that simple. So how do you get to that?
- Get the best CPU cores available, in other words, those cores that drive the most database transactions per core
- Get rid of idle CPU cycles (no can do with physical deployed servers, need to go virtual – so choose the best hypervisor that’s available to you)
Now there’s more ways to reduce license footprint (ordered from low risk/low impact to high risk/high impact):
- Get rid of unneeded database options (the options on Oracle Enterprise Edition may add up to being more expensive than the base EE license)
- Move away from Enterprise Edition altogether and run Standard Edition
- Move workloads away from Oracle to something else (think Hadoop i.e. EMC HAWQ/Pivotal, NoSQL, Open-Source enterprise databases i.e. PostgreSQL)
Getting the best CPU cores
The way I compare CPU cores is by using the TPC-C benchmark numbers – and actually the TpmC (Transactions per minute, type C, which is OLTP oriented) per core. The problem with that is, not all CPU types are listed, and the results may be influenced by not only the CPU but also the server platform. So I also use SPEC and other benchmarks, and I try to be creative with MHz ratings, etc. It’s not exact science and the results may not be 100% accurate – but I guess it’s close enough.
Given that Oracle uses a CPU core factor for Intel of 0.5, and 1.0 for some RISC processors (except their recent SPARC models…), you have to take that into account as well. For example, IBM Power 7 is a very fast CPU even per core, however, Oracle requires double the license cost per core as compared to Intel X86-64. So on a license cost per transaction basis, IBM Power has to outperform Intel by 2X to match up for the core factor. Again you may argue that this is anti-competitive from Oracle (and rightfully so) but that’s the way it is.
Currently among the fastest CPU cores are (disclaimer: this list is not complete and likely not 100% accurate, and some of these are based on other databases than Oracle):
CPU type TpmC/core
Intel E5-2690: 100574
Intel E5-2643: 100574 (exact same cores as the 2690)
Intel E7-8870: 63199
SPARC T5: 66816 (currently top-listed overall TPC-C benchmark
but they required lots of cores - expensive!)
IBM POWER6: 101116 (but core factor 1.0)
IBM POWER7: 150001 (core factor 1.0, this is the 4.14 GHz CPU type)
Estimates (no TPC-C results yet so these are estimated based on other benchmarks)
POWER8: ~200000+ (awesome!)
Intel E5-2697v2 ~115000 (no TPC benchmark available yet so I used other benchmarks
to make an estimate)
(Many thanks to Kevin Closson for guidance on CPU ratings)
So you can see which CPU works best for DB workload consolidation. Be cautious as some CPU types (Intel E7?) may drive more bandwidth than their TpmC rating suggests – so for data warehouse workloads you might be better off looking at other benchmark results. But for regular OLTP I guess TPC-C works fine.
So clearly the best CPU (currently) for DB consolidation is the Intel E5-2600 series (preferably the newer v2 models). IBM has (very impressive) much higher TpmC/core ratings but requires double the license cost (and the pSeries hardware ain’t cheap either). I’d consider IBM Power8 a good alternative if you want to go RISC/UNIX (better than SPARC on a price/core basis) – and don’t forget to use all the virtualization capabilities of IBM POWER to drive up your utilization. IBM supports hard partitioning, so you may want to run Oracle on a few cores licensed and use the rest of the system for other workloads.
Back to Intel/VMware. Very large environments probably will dedicate an entire VMware cluster to Oracle database (remember to not run anything else there: no middleware, no apps, no data replication overhead etc – dedicate all your CPU cycles to DB processing where possible).
Smaller server environments
Average sized organizations will likely only have one VMware farm – so they will deploy VMware sub-clusters for Oracle database (so they can license only the servers that actually run Oracle). For those organizations, the issue around CPU affinity and hard- vs soft partitioning is a non-issue as they need more than a few entire servers for their database workload anyway. The issue is around smaller organizations who only need a few CPUs to run their database load.
For those, a dual-socket server with Intel E5-2690 (16 cores) might even be too large – so it seems to be perfectly valid to look at sub-server licensing. But no can do, unless you buy from Oracle.
Now smaller organizations typically also don’t need things like partitioning (because of smaller database sizes) and other features of Enterprise Edition (EE). Going from EE + options to SE (Standard Edition) pays off:
(assuming 50% street price discount)
2-socket, 16-core server with EE, partitioning, advanced compression, diagnostics & tuning pack: $322,000
2-socket, 16-core server with SE (no options possible): $ 17,500 (assuming 50% street price discount).
That’s about 95% savings!
2-socket, 24-core server with EE, partitioning, advanced compression, diagnostics & tuning pack: $483,000
2-socket, 24-core server with SE (no options possible): $ 17,500 (assuming 50% street price discount).
That’s about 97% savings!
(remember Oracle Standard Edition is licensed by socket – so that’s a good deal considering you can have many cores per socket with today’s processors). If you can’t use SE because of EE features that you need, then the only way to reduce license cost is reducing – licensed – CPU cores. Fortunately you don’t have to buy the largest server you can get – for example, Cisco UCS has blades that run with fewer CPU cores: The UCS B200M3 has 2 sockets for Intel E5 processors. If you only install one socket with E5-2407v2, then you have only 4 cores in your machine. That requires only 25% of the licensing of a dual-socket E5-2690 or 17% of dual-socket E5-2697v2.
The extra (empty) socket allows you to quickly add more CPU power if your workload grows. Cisco UCS blades are also “stateless” which means that if you require a more powerful server than the B200, you just add the faster blade, and apply the UCS template to the new blade, and restart your system.
As you see, you can achieve cost savings as long as you’re a bit creative and ignore FUD from software vendors…
Comments are closed.