Caveat Emptor of Oracle Standard Edition 2

On September 1st, Oracle discontinued Oracle Standard Edition (Oracle SE) and Oracle Standard Edition One (Oracle SE1) and replaced them with Oracle Standard Edition Two (Oracle SE2).

Oracle SE and Oracle SE1 were licensed per socket, regardless of the number of cores (physical threads) or hyperthreads (logical threads) in the socket. This meant it was in the customer’s best interest to buy processors (sockets) with the most physical cores and with hyperthreading to get the best performance for the Oracle licensing cost.

With Oracle SE2, Oracle changed the game entirely. Oracle SE1 was $5,800 per socket. Oracle SE2 is $17,500 per socket. If you were running the smallest license possible, your licensing cost just went up 3x or 300%.

There’s more.

o Oracle SE1 had a limit of 2 sockets and no limits on the cores per socket.
o Oracle SE had a limit of 4 sockets and no limits on the cores per socket.
o Oracle SE2 has a limit of 2 sockets and a 16 CPU thread limit per socket.

Intel’s current server CPUs scale up to 18 physical cores (+ 18 logical cores) per processor, so you could have been running Oracle SE1 for $6k with 18 physical (36 logical) threads, only to now pay TRIPLE to run Oracle SE2 and be limited to 16 total threads instead of 18 or 36 before your upgrade.

The bad news doesn’t end there.

What if you weren’t at the low end of the configuration but instead at the high end? Running Oracle SE with Oracle RAC on 2 servers, each with two sockets, each with 18 physical (36 logical) threads? That would have cost you 4 sockets of Oracle SE for $72k (4 sockets at 18k each) and gotten you 72 physical (144 logical) threads of CPU.

You can’t license that on Oracle SE2. It’s limited to single socket RAC, and again, 16 total threads. You get to go buy new hardware AND upgrade to Oracle Enterprise Edition AND buy Oracle RAC on top of that. Let’s be generous and say replacing the hardware was free. 72 physical cores of Oracle Enterprise Edition (with 0.5 core factor) would cost $1,710,000 (47.5k * 0.5 * 72) and then RAC on top is an additional $828,000 (23k * 0.5 * 72) for a total price of $2,538,000.

Yes, to upgrade to SE2, your Oracle licensing cost could go from $72,000 to $2,538,000 – only a 35.2x or 3520% price hike.

In honor of Star Wars Force Friday, this quote from Darth Vader seemed especially appropriate:

“I am altering the deal. Pray I don’t alter it any further”

References
http://www.oracle.com/us/corporate/pricing/databaselicensing-070584.pdf
http://ark.intel.com/products/85766/Intel-Xeon-Processor-E5-4669-v3-45M-Cache-2_10-GHz
http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf

Why I am anti host storage

So a friend of mine (@vaughanjt) tweeted that out to me today:

and I responded

At my employer, we’ve got around 500 VMs in one location, around 300 of which are various builds of the software we produce (vs back office stuff like Exchange, Oracle, etc). These 300 VMs are usually 10-30 copies of the same master with some small networking changes. At present time on our existing storage (EMC VNX 5500), doing those 10+ copies of the master are my bottleneck.

Yes, going to some sort of AFA (All Flash Array) could make this operation take alot less time. Yes, implementing something like vCAC / vRA (vCloud Automation Center / vRealize Automation) could definitely help with that bottleneck – linked clones off the master and all that, but simply, with my recent promotion and my need to backfill three personnel in the Infrastructure and Operations group, I simply don’t have the time to get that implemented in a robust and redundant way right now.

Couple that with other business challenges we face (the lease / maintenance on the VNX is due end of year, replication, etc among many other factors), and the best solution for my employer, based on our current constraints, was new shared storage that can provide the IOPS I need, yet greatly simply / speed up the management operations that are a bottleneck in our build cycle.

Host based storage (and IOPS in general) is a great thing, if it solves the problem you’re really facing. If, after solving the existing bottlenecks, I need more IOPs, I’m all for using host based storage (RAM, NVMe, SSD, etc) for caching to get me the IOPs.

Flash can be the proverbial hammer to solve a problem, but sometimes re-architecting your process is a better solution than throwing more IOPS at a problem.

I am back

Wow, it’s been 2+ years since I last posted a blog entry. Well, I’m back.

Blog has been cleaned of it’s malware and un-blacklisted.

I’m still working with Oracle, managing the Oracle and Linux team and working with those technologies along with VMware on a day to day basis.

So many things to write about, and as always, so little time.

Right now my big to-do item is to finish my second submission for the VMware VCDX-DCV certification, due May 5th.

Follow me on twitter ( @aus_effendi ) and look forward to more good content.

J

Caveat Emptor of the Oracle Database Appliance

From Wikipedia:
Caveat emptor ( /ˌkæviːɑːt ˈɛmptɔr/) is Latin for “Let the buyer beware”

This year I skipped Oracle OpenWorld but I have been following the announcements with much interest. One of these announcements was the Oracle Database Appliance. What I found out initially was interesting. I managed to attend an online seminar on September 28th. After that seminar, I had serious concerns about the feasibility of the Oracle Database Appliance product and reached out to an Oracle national account manager in hardware sales to allow Oracle to respond to my concerns before I posted this blog entry. I heard back from one of his team and verified my concerns below are in fact valid.

First of all, contrary to what has been mentioned in mainstream IT media such as here and here) this appliance is in no way a mini-Exadata – it contains absolutely none of the technology that makes Exadata special – no Infiniband, no hybrid columnar compression, no smartscan. This wouldn’t be the first time that mainstream IT media has misunderstood a technology before (FCoTR (http://fcotr.org/) anyone?), but Oracle needs to get their marketing message out there correctly. The Oracle sales consultant I’ve fact checked this with agrees, stating “no Exadata features are used on the appliance.”

Second, the Oracle Database Appliance must use Oracle 11gR2 Enterprise Edition – so right there this appliance is of no interest for many existing Oracle customers that have applications that require older versions of Oracle database – for example, Oracle’s own products like Oracle Email Center for Oracle E-Business Suite 11i which requires a 9i Oracle database. It also means you’re limited to Oracle Enterprise Edition (at a list price of $47,500 for every two x86 cores) and not Standard Edition ($17,000 for every socket, regardless of cores per socket) which might be more appropriate for the SMB customers this product is aimed at.

Oracle touts three major selling points for this product – Simple, Reliable and Affordable.

One of the selling points for the Oracle Database Appliance is its simplicity and ease of use – particularly the one button patching for the entire appliance, from the hardware thru the Oracle database software itself. If that works as described, it is a very nice feature. The appliance has 2 “servers” (nodes) in it – and has a built in wizard to quickly configure the appliance for high availability using Oracle RAC (don’t forget that RAC is an additional $23,000 for every two x86 cores on top of Enterprise Edition licensing). That single button patching for the entire appliance comes at a very high uptime cost. To apply patches, BOTH NODES must come down at the same time and patched simultaneously. Not only have you now greatly negated the high availability feature of RAC, but this restricts the suitability of this product for environments that require a change control procedure….Because you can’t have each node patched independently, if you’re running your production and test systems on the same oracle database appliance, you are now essentially applying untested (by the customer – Oracle “always” tests their patches) patches to both production and test simultaneously. I asked the moderator of the chat for the seminar I attended if I had this correct and his response:

“Yes, all patches applied at once, would probably be a good idea to have one appliance for PROD and another for Staging so that the patch bundles can be tested before applied to PROD”

The Oracle sales consultant verified my observations are correct as well.

So now I’ve negated the much of the high availability feature of RAC and eliminated the ability to test patches to my production environment unless I buy two of these units. Although the list price of the units wasn’t mentioned (I’ve since read the list price is $50,000 US, and that is without any Oracle licenses), I’m guessing two of them might be a bit pricey for the typical SMB. Of course, this hypothetical SMB is already buying Enterprise Edition (and possibly RAC) licenses, so buying two Oracle database appliances may not be a huge additional cost.

In case you’re wondering, you cannot cluster a RAC instance across multiple Oracle database appliances.. so you WILL have downtown to apply patches to this system, something you wouldn’t have with RAC on any other vendor’s off the shelf two node system.

The appliance ships with 24 cores – to license additional cores and have them available to the databases, you must reboot the entire system and again experience downtime – something you wouldn’t have with RAC on any other vendor’s off the shelf two node system.

If I’m going to buy Oracle RAC, one of the main reasons I’m buying it is to avoid downtime. Downtime that is avoidable with off the shelf systems is unavoidable with the Oracle Database Appliance. Why would I buy this appliance? Perhaps because of the third selling point of being affordable…

One of the cost savings advantages of this system is, and I’m quoting here, the “Pay-as-you-Grow” licensing model. According to the seminar, one of the unique features and selling points of the “Pay-as-you-Grow” model is that you only license the cores that you’re using. The Oracle database appliance has hooks into the BIOS and will turn off the unlicensed cores at the BIOS level. Contrary to what was said during this seminar, this Pay-as-you-Grow licensing model is NOT unique to the Oracle Database Appliance. Believe it or not, it is already supported by Oracle licensing when using hard partitioning technologies. Please check out Oracle’s partitioning document and search on the words “Pay as You Grow”. That partitioning document has been on the Oracle website since 2002 and was last revised April 1st, 2011. I’d quote the relevant section of the document here, but the small type at the bottom forbids it. Please also check out the first partitioning example.

So my thoughts on the Oracle Database Appliance? A product that sacrifices flexibility and reliability for too much simplicity and isn’t more affordable than other vendor systems.

Caveat Emptor.

If these concerns aren’t deal breakers for your organization, you may want to check out this excellent post by Alex Gorbachev where he benchmarked the system’s I/O performance.

Yet another way VMware saves a company money on Oracle licenses

I want you to take a step back and think about a hypothetical company not running any virtualization. The company has an Oracle Enterprise Edition database running on a 4 core server that’s has very heavy (95%) CPU utilization. The company has to decide between buying a new 8 core server to handle the additional computing as their data volume and business grows, or they need to find a way to reduce their CPU utilization.

If the company goes with the new server, they’ve got the cost of the new hardware itself (irrelevant to my point so let’s call it $0) PLUS 4 more cores (2 processor licenses) of Oracle Enterprise Database – $95,000 (According to the latest Oracle pricing list).

The DBA takes a DEV copy of the system and run OEM Diagnostics and Tuning Packs against it and finds he can cut their CPU utilization in half. Cost to implement in production? 4 cores worth (2 processor licenses) of Diagnostics and Tuning Packs – $20,000.

The company saves $75,000, the DBA is regarded as a hero and is about to be given a Porsche Boxster by the company for all the savings.. until accounting rightfully points out that with everything tuned up, the company has an extra Oracle Enterprise Edition processor license of processing power that the company isn’t getting ANY benefit out of and can’t use for another database server, plus the company isn’t getting much additional benefit from the $20,000 of Diagnostics and Tuning licenses.

If only there was a better way!

Imagine the company decided to first virtualize that database server – I’m talking the most basic sort of vSphere virtualization – just one stand alone vSphere ESXi host. Cost from VMware? Zero Dollars. Now, they still have the whole server licensed for Oracle databases. They spend their $20000 and buy OEM Diagnostics and Tuning Packs and now, just like before, they’re left with a database server running on 2 cores, they have two cores unused but licensed for Oracle Enterprise Edition. Because they’re virtualized, they can add another database server virtual machine on the server (getting use out of that wasted license) AND they can leverage the OEM Diagnostics and Tuning Packs to tune that additional database.

So now the company is getting double it’s value out of those Database and OEM licenses – all just by virtualizing under VMware. This is the most rudimentary example, assuming you had a database that was actually utilizing 95% of the CPUs before and that OEM helped you cut that load in half. Imagine the benefit a company that has 5 or 10 physical Oracle database servers each at 25% utilization could benefit by virtualizing under VMware to a couple of hosts and licensing those hosts with those OEM packs.

As a company grows and adds systems, the benefits of virtualizing Oracle really start to add up.

Don’t be shocked when the DBA starts showing up in a Porsche Cayenne Turbo.

Oracle Exadata Database Exalogic Elastic Cloud and why I am not interested

In the last few months, there’s been a big push by Oracle to talk to customers like me about the Exadata Database machine and the Exalogic Elastic Cloud machine. From talking with other DBAs and reading the blog posts, the systems seem to have amazing performance. Unfortunately, I don’t think I’m going to be playing with one any time soon because the systems don’t fit with my company’s requirements (or budget).

Price tag aside, one big “Do Not Pass Go” for us is the lack of data replication technology available at the hardware level. If my business requires the power of an Exadata or Exalogic, I think it’s a reasonable assumption that such programs are mission-critical and something I want to protect in case of a Disaster Recovery (DR) situation like an earthquake or fire that takes out my primary data center. Instead I’m forced to rely on database specific replication technologies like Data Guard. Acceptable if I’m running just databases, but what about Exalogic? Exalogic is “cloud in a box” – designed for application servers.

I’ve been looking around trying to find data on Exadata and Exalogic in DR situations and the data has been sparse, but I did come across a presentation by Rene Kundersma who works as a Database Technical Architect and Software Engineer for Oracle Consulting. If you recall, I took exception to something Rene to wrote in another blog entry, but the fact is Rene is an Oracle Certified Master (OCM) in 9i, 10g and 11g and Oracle RAC and Linux certified. I think we can safely say that Rene is an expert on these technologies and would know how best to ensure uptime.

In the presentation Oracle Database Machine at TUI: Business Case, Setup, Migration, and Experiences you can see that the entire Exadata DR/backup strategy involves another SAN and tape drives with a RTO to restore from tape of 2 hours. Of course, they also use Oracle Data Guard (a database specific technology) to replicate the databases to another Exadata, and that’s great if you want your databases to stay in sync (and can afford the licensing costs of all the database licenses on another Exadata), but what if you want the ability to bring up your DB at any point in time in the last X hours? You can, but you greatly increase the ability to quickly bring up the DR version with the latest system changes.
SAN Replication Technologies such as EMC’s Recoverpoint have had features like this for years along with others not in Data Guard and these technologies aren’t limited to just databases.

Oracle Java 7 supported platforms updated but still no VMware or Microsoft support

As I’ve blogged about initially Oracle releases Java 7 with odd restrictions and then followed up with Oracle to update Java 7 planned supported system configurations, Henrik Stahl of Oracle said the supported platforms page would be updated and it has – but not with the updates he listed.

As of 11.40am, the Planned Supported System Configurations for Java now re-directs to here where the virtualization section has been modified from the previous revision with

1) Oracle VM 2.2 is now supported (previously just Oracle VM 3.X which is not released yet)
2) VMware (capitalization corrected) and Microsoft Hypervisors are still listed as not supported.

I understand Oracle is a large organization and things take time to update, but the page has now been updated and is still reading that VMware and Microsoft Hypervisors are not supported.

Oracle to update Java 7 planned supported system configurations

[Please see my latest blog update on this issue]

A few hours after my last post regarding Oracle explicitly not supporting Java 7 if run on an Oracle VM 2.X, VMware or Microsoft Hypervisor, I received the following comment in my blog from an IP address at oracle.com:

Submitted on 2011/07/28 at 3:39 pm

Hi – The supported platforms page was mistakenly created using a standard Oracle template which is not applicable to Java. It will be updated to clarify that we support Java explicitly on certified platforms (eg those called out in the page) and on other platforms as long as we don’t run in to platform specific issues. In that case (eg, if VMware is broken) you will have to go to the platform vendor for troubleshooting and a fix.

Henrik Stahl
Sr. Director, Product Management
Java Platform Group
Oracle

As of the time of me writing this post, the Planned Supported System Configurations for Java page has not been updated but that’s understandable – things take time, and hey, it is launch day so some celebration is warranted!

As I wrote back to Henrik in my comments, I look forward to the webpage being updated and have one follow up question – Given Oracle’s support stance regarding VMware as specified in MOS Note 249212.1, I’m curious what standard Oracle template would say that VMware (and Microsoft Hypervisor) are NOT supported – certified, sure, but not supported?

I’ll let you know what, if anything, I hear back.
[Please see my latest blog update on this issue]

Oracle releases Java 7 with odd restrictions

Oracle releases Java 7 today, but with restrictions that could greatly inhibit it’s adoption.

[update: Since this blog post being published, I’ve received a comment from Henrik Stahl who is the Sr. Director, Product Management, Java Platform Group at Oracle who stated “Hi – The supported platforms page was mistakenly created using a standard Oracle template which is not applicable to Java. It will be updated to clarify that we support Java explicitly on certified platforms (eg those called out in the page) and on other platforms as long as we don’t run in to platform specific issues. In that case (eg, if VMware is broken) you will have to go to the platform vendor for troubleshooting and a fix.”]

So as I’ve written in the past here and here, Oracle appears to have a bad habit of not playing nice with others.

In today’s installment, we have Java.

When Oracle acquired Sun, Oracle acquired control of Java. With Java came many political battles involving Google, Apache and even Starbucks. The last one is an April Fool’s article, but honestly, would you be surprised?

Now it seems Oracle is planning to leverage Java to restrict customer’s choice of hypervisors.

Java 7 is being released today.

If you check out the Planned Supported System Configurations for Java, you’ll see that Java 7 will be supported on
Windows: XP, Vista, Server 2008, and Windows 7
Oracle Linux: 5.5+, 6.X
Solaris: 10u9+, 11.X
SuSE Enterprise Linux: 10 SP2+, 11.X
RedHat Linux: 5.5+, 6.X
Ubuntu: 10.04, 11.04

To make things clearer, the document also mentions a couple of interesting notes:
SuSE Enterprise Linux (with Java 7): Not Supported on Oracle VM
Ubuntu (with Java 7): Not Supported on Oracle VM

and then this bombshell:
System Virtualization Support

All supported platforms are supported when virtualized in a supported hypervisor
Supported hypervisors are: Oracle VM 3.x, VirtualBox 3.x, 4.x, Solaris Containers and Solaris LDOMs. Except where noted.
VMWare and Microsoft Hypervisor NOT supported

[emphasis added by me]

A couple of things to note here:

1) Oracle still hasn’t gotten the message regarding capitalization – it’s VMware, not VMWare (really surprising when you consider Java uses CamelCase aka HumpBack notation for file names)

2) Oracle VM 3.0 still is not released, which means that Java 7 isn’t supported on Oracle’s own current Type 1 Hypervisor. Although I expect Oracle will eventually release Oracle VM 3.x, Gartner expects more than 50% of all server workloads to be virtualized by end of 2012. Is Oracle chopping off the nose to spite the face?

3) Java 7 is explicitly NOT supported on VMware and Microsoft Hypervisors

Java is owned by Oracle. The same Oracle who has My Oracle Support note 249212.1 which says that Oracle will provide support for issues that occur on the guest OS or that can be demonstrated not to be caused by running the guest OS on VMware. So Oracle in the case of Java is going from a de-facto “it’s supported” type document to now an explicit VMware (sorry, VMWare) is not supported.

So what does this mean for companies running products on VMware that they want to use with Java 7? Probably nothing – people will try their products with Java 7 under VMware and I’m guessing it’ll work just fine.

But what about the more interesting case – those Oracle customers running Oracle products like Oracle E-Business Suite or Oracle Agile that rely heavily on Java? Will Oracle support deny support because Java 7 isn’t supported on VMware, even though My Oracle Support note 249212.1 says Oracle will support Oracle products on VMware?

Where does OpenJDK fit into this?

What are the support implications when running Windows XP or Windows 7 Desktops in a VMware View environment? VMware View environments run on a VMware Hypervisor.

I honestly don’t know those answers, but this sort of FUD will probably retard the adoption of Java 7, something I don’t think Oracle really desires.

Oracle responds to RedHat obfuscation of kernel patches in RHEL 6

As I wrote earlier, starting with RHEL 6, RedHat stopped providing the source of a vanilla kernel and all their patches in different packages and now provides this all in one large tarball. According to RedHat’s VP of Worldwide Engineering, this was done to make it harder for downstream vendors like Oracle to incorporate RHEL’s changes into their own kernels. I came across this exchange between Wim Coekaerts (Oracle’s VP of Linux Engineering and manager of Oracle Linux, among other things) and open source enthusiast Matt Asay on twitter:
——
Matt Asay (@mjasay)
2/28/11 2:28 PM
Red Hat obfuscates its source j.mp/ikzjMT Red Hat just made life harder for RHEL clones CentOS & OEL.Smart biz,but backlash coming?

Wim Coekaerts (@wimcoekaerts)
2/28/11 3:04 PM
@mjasay we like git bit.ly/eNG5SM it helps us and others. either way not sure the rht change actually matters, we help our customers

Matt Asay (@mjasay)
2/28/11 3:09 PM
@wimcoekaerts It seems that it would make it harder to grok where to apply patches

Wim Coekaerts (@wimcoekaerts)
2/28/11 3:26 PM
@mjasay sure but with a good team it doesn’t matter. I guess it means our bugfixes will be harder for them to apply 😉 not our problem tho.
——

It doesn’t sound like Oracle is too concerned with the change, though I wonder how much of that is false bravado.

I especially like Wim’s “not sure the rht change actually matters, we help our customers”. If Wim is serious about helping Oracle’s customers, why is Database Smart Flash Cache and ksplice (just to name a few) limited to Oracle Linux?