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

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.

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.