A Critical Look at Oracle's Database Appliance

The Liberator hears rumours (and even sees NOIs) indicating an outbreak of vendor-lock spreading in his Province. This time, embodied in the top-to-bottom-locked Oracle Database Appliance. Recognizing that some consumers might see value in 'being looked after' or having 'one throat to choke', let's look at this offering.


The Oracle Database Appliance (ODA henceforth) is a pair of 2-socket Xeon X5675 Linux (OL5.8) servers each with 96GB of RAM, 20*600GB platters plus 4*73GB SSDs for database storage and a pair of 500GB SATA drives for OS. The storage is RAID1'd 3-ways, so presents 4TB of usable space. It lists at $50k. It does not include database software (which must be Oracle Enterprise or Real Application Clusters (RAC) licensing or support, which must be bought separately. Application of patches is done through the Appliance Manager, which will execute all Oracle software and firmware patching from a single interface using specially-tested patch sets. The appliance can be configured for Pay-As-You-Grow - meaning that you can choose to restrict the number of cores you license, letting you use less than the 24 cores physically built-in.

A Good Deal on Hardware?

So, $50k is about twice the usual Tier-1 (IBM, HP, Dell, Fujitsu, NEC) pricing for a setup like this. If you have a preferred vendor for your other x86 servers, you'd be better off going to them, and keeping your hardware managed behind their server management tool. You might also strongly consider building a whole bunch more RAM into the box than just 96GB - Oracle databases are notoriously hungry for the stuff. However, you just wouldn't build a system like this for Enterprise use. Why not? Because of all that Direct-Attached Storage.

Direct-Attached Storage?

Being naturally thrifty, I'd love to propose DAS as part of your datacentre solution - it's the cheap way to do things, after all. But it's not the Enterprise-class approach. You can't slice DAS up between servers. You can't use DAS for multiple OSs. There's no Battery-Backed Write Cache, no redundant or scalable head-ends, no multipathing. Deduplication, compression and snapshotting are features taken for granted with modern storage appliances that you don't get with DAS. And, worst of all, DAS doesn't provide you with automatic tiering. Appliances nowadays will monitor data usage and put your well-used 'hot' data into the fastest tiers and your big, 'cool' data into the bulk layers. DAS just doesn't cut it nowadays.

Patching Simplified?

This is a great point in favour of the ODA - the patch sets are specific to the machine and can be administered from a single front-end. Unfortunately, all patches are applied to all hardware simultaneously, so you don't have a Dev/Test/Prod release cycle capability. And both nodes have to be rebooted simultaneously to apply the patches, so if you've bought RAC for availability, it's a nasty hit. You also can't RAC across multiple ODAs (because of the limited external networking capability), so Prod is definitely going down. If you've got one ODA for Dev/Test and one for Prod, you could at least test the patches before you had to bring Prod down. But if Dev/Test was anything other than an ODA, you've lost that patch set coherency which is so appealling.

Pay As You Grow?

This is a very nice feature - it would be great if Oracle would allow it more generally. In particular, it'd be great if Oracle would let you use a hypervisor's core-count as a licensing-containment tool - giving you real flexibility about how much capacity you want to pay for. Unfortunately, this is a classic area of vendor-lock with Oracle, since the only hypervisor they let you restrict core count with is Oracle VM. Even though that code base is shared with Xen and KVM, you won't be permitted to do the same with Xen or KVM. Let alone VMware or Hyper-V. But I digress.

So you can Pay As You Grow with the ODA. Note that it's not Pay As You Need, since changing the core count is a one-way-only operation - you can make the core count bigger but not smaller. Still, it gives some flexibility.

Of course, that flexibility is 'wasting' your hardware. You buy all 24 cores and both servers regardless of how much you actually use. So if you do restrict the core count for any substantial duration, you might well have been better off just right-sizing your hardware in the first place. That said, since perpetual database licensing will set you back $47,500 for every 2 cores, or $570k for the whole ODA, perhaps 'wasting' the $50k hardware isn't your chief concern. Wasting licensing should be your chief concern.

Licensing Inefficiency?

And here's the hardest nail in the ODA's coffin - it's a bad choice from a licensing perspective. It is not in Oracle's best interest to tell you that, since licensing revenue is much more important than hardware revenue.

The Xeon X5675 is a pretty good chip for running Oracle. Of the 7,582 servers clocked at spec.org, Oracle's best server using the X5675 beats 6,268 of them on a core-for-core basis. But it gets beat by 1,314 of them.

And the difference between pretty good and best is costly, in licensing efficiency. The very best servers currently on the market are running 51% faster core-for-core. Which is to say, if you right-sized your custom server setup using the best CPUs, you could save $192k in initial licensing compared to using an ODA. Plus an annuity of $76k per year in software support fees you'd save.

That's heck of a price for having 'one throat to choke'. Ahh, the wages of vendor-lock.