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.


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

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?

Oracle versus RedHat and VMware

As I wrote earlier, there are many things to consider about when deciding what distribution is best for your environment when running Oracle under VMware. Over the past couple of years there’s been a quiet battle with Oracle on one side and RedHat with VMware on the other. As a customer, your dollars fund the game. Your choices will help determine who wins this battle.

First up, Oracle

In Oracle Database 11g, Oracle introduced a new features called Database Smart Flash Cache. The feature leverages any flash storage (aka Solid State Drives (SSDs) or Enterprise Flash Drives (EFDs)) on the system to act a second level cache behind RAM, increasing the database buffer cache without adding RAM to the system. There was a recent post on this topic on Oracle’s Linux blog which links to an interesting white paper if you want more detail on the inner workings of this feature.

Sounds great right? Here’s the thing: It’s only available on Oracle Solaris or Oracle Linux. Now Oracle Solaris on SPARC processors I could see – it’s a Big-Endian Unix whereas x86/x86-64 Linux is Little-Endian OS and Solaris on SPARC is a much more mature OS that Linux.

Oracle Linux is binary compatible with RedHat Enterprise Linux – so there is no technical reason why Database Smart Flash Cache shouldn’t work. I’m not the first to point this out. Dave Welch of House of Brick Technologies wrote about this in October 2009. I suggest you read his eloquent blog post on the subject. Note that this was all before the Oracle UEK Kernel was released and nothing in Oracle’s documentation states that UEK is required for Database Smart Flash Cache.

In September of 2010 at Oracle OpenWorld 2010, Oracle announced Oracle Unbreakable Enterprise Kernel (UEK). As you can read in this datasheet on the UEK,the big selling points are that it’s a modern 2.6.32 linux kernel that shows “tremendous performance improvements” compared to a standard Enterprise Linux 5 kernel (which is a 2.6.18 kernel). Amazing right? Not really. RHEL 5 was released in March of 2007 and hits the end of Production 1 life cycle in Q4 of 2011. RHEL 6 was released in November of 2010 is also a modern 2.6.32 linux kernel. Key benefits of UEK according to Oracle’s FAQ are that it’s fast, modern, reliable and optimized for Oracle. RHEL 6 is fast modern and reliable too. Yes, the UEK does have some optimizations and bug fixes for Oracle but they or may not be relevant in your environment.

So why does Oracle beat up on RedHat? It’s about money. Oracle wants that OS support revenue.

How is Oracle beating up on VMware? It’s also about money. Virtualizing Oracle allows you to run more Oracle servers on the same hardware. That’s lost revenue to Oracle, unless you’re using their hardware (Exadata) or software (OracleVM). Oracle tries to discourage VMware use with Oracle’s infamous supported but not certified argument against VMware. There is also Oracle’s policy of having to license all the cores on a host regardless of how many cores your VM can see (unless you’re using Oracle’s virtualization solution of course). Here’s another one I came across recently: In the release notes for Oracle Linux 6 is this little nugget:

Unbreakable Enterprise Kernel doesn’t contain vmw_pvscsi driver (11697522)
As a workaround, when creating a new VM in VSphere, do not pick Red Hat Enterprise Linux 6 x86-64 as the OS type but use Oracle Linux 5 x86-64 (or Red Hat Enterprise Linux 5). ESX will then expose the LSI Logic SCSI controller in the VM and the 2.6.32-100.28.* kernel will see the devices properly.

I did a default install of RHEL 6 (which uses the RedHat Kernel instead of Oracle Kernel) and lo and behold, RHEL 6 automatically uses PVSCSI to get you better disk performance under VMware. Oracle’s Unbreakable Kernel is based off of RedHat’s Kernel. That means Oracle went out of it’s way to cripple performance by removing PVSCSI support when using their kernel under VMware. Oracle’s own virtualization product OracleVM doesn’t have any sort of PVSCSI enhancements, so what better way to erase the performance benefits you’d see virtualizing under VMware? As a customer, I find this behavior deplorable.

Next Up, RedHat

With the release of RedHat Enterprise Linux 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. It’s totally legal by the requirements of the GPL, but it makes it much more difficult for downstream vendors (such as Oracle) to figure out what optimizations RedHat has made to the vanilla kernel and to then incorporate those changes into their own customized kernel. Now why would RedHat do this? Let’s see what Brian Stevens, CTO, VP Worldwide Engineering for RedHat had to say in this press release

“When we released RHEL 6 approximately four months ago, we changed the release of the kernel package to have all our patches pre-applied. Why did we make this change? To speak bluntly, the competitive landscape has changed. Our competitors in the Enterprise Linux market have changed their commercial approach from building and competing on their own customized Linux distributions, to one where they directly approach our customers offering to support RHEL.

Frankly, our response is to compete. Essential knowledge that our customers have relied on to support their RHEL environments will increasingly only be available under subscription. The itemization of kernel patches that correlate with articles in our knowledge base is no longer available to our competitors, but rather only to our customers who have recognized the value of RHEL and have thus indirectly funded Red Hat’s contributions to open source that will advance their business now and in the future.”

Who is the number one seller of RHEL support behind RedHat? Oracle.

Finally, VMware

VMware has done a few things I can think of to fight back against Oracle:
1) Quite simply, Oracle’s UEK (Unbreakable Enterprise Kernel) is NOT supported under VMware. Yes, I’m sure it requires resources to test yet another kernel, but I don’t believe that’s the case here. Could it be because of the “optimizations” Oracle has made such as the deadline scheduler (not typically good when used under a hypervisor) or stripping PVSCSI support out of the UEK? Maybe.

2) Up until the last few weeks, Hot Memory Add wasn’t listed as supported with Oracle Enterprise Linux 5.X under VMware according to VMware’s Guest OS Compatibility List, even though RedHat Enterprise Linux (on which OEL is based) was supported. Maybe it was an innocuous typo … or maybe not.

3) In November 2010, Oracle changed their support policy to explicitly INCLUDE Oracle RAC when virtualized. Before that time, Oracle RAC was explicitly NOT supported by Oracle under VMware. Oracle’s yearly conference, Oracle OpenWorld, was held in September – before the change in the Oracle RAC on VMware support policy – and VMware had a booth there. I attended a number of sessions at that booth and at least two of them (one by Todd Muirhead of VMware, one by David Welch of House of Brick Technologies) talked about running Oracle RAC virtualized under VMware. Both presenters made it very clear that this wasn’t supported by Oracle, but one has to wonder why VMware would take the time to talk about a solution that wasn’t supported by Oracle? Maybe they knew Oracle was going to change their support policy and were just letting customers know it could be done “if only Oracle would support it”… or maybe VMware was preparing a more offensive role regarding Oracle RAC on VMware. I don’t know, but it’s interesting to think about.

So what’s a customer to do? To me the answer is simple: If you’re going to run Oracle virtualized, I’d highly recommend running it on RHEL Linux on VMware and buying my support for RHEL Linux from RedHat. If you buy support for RHEL from Oracle, assuming the support quality level is the same as RedHat’s, you’re helping Oracle to stifle true innovation that benefits everyone. If you decide to run OL, not only are you helping Oracle to stifle innovation that benefits everyone, you’re also telling Oracle you’re fine with them limiting features to customers (such as Smart Flash Cache) entirely for anti-competitive marketing reasons.

Don’t reward bad behavior.

What Linux distribution should you use for Oracle virtualized on VMware

Recently Tim Hall of Oracle-Base fame wrote an article “Which Linux do you pick for Oracle Installations?” which addresses Oracle on non-virtualized Linux. Tim’s article is excellent but doesn’t take VMware virtualization into account, so without further ado, which Linux distribution should you use for Oracle virtualized on VMware?

When virtualizing Oracle with VMware, most Oracle DBAs are going to run it on some flavor of Linux. Oracle generally supports three distributions of Linux for their enterprise products: Novell’s SuSE Linux Enterprise Server (SLES), RedHat Enterprise Linux (RHEL), and Oracle Linux (OL). Each Operating System has costs, features and support implications that make it unique. You need to determine which is best for your environment. In the United States, RHEL is most popular, whereas in Europe SLES is most prevalent. Almost all of my experience is with RHEL or on downstream distributions (such as CentOS or OL) of it, but my biases shouldn’t have an impact on this evaluation. The file system for VMware’s vSphere ESX and vMA (vSphere Management Assistant) and many of the VMware appliances from EMC and PHD Virtual are RedHat/CentOS based. This shouldn’t be a deciding factor when deciding what OS for your database system, but this does come in useful in the event of the occasional esoteric troubleshooting situation.

With some minor exceptions, RHEL and OL are the same to operate — the files are almost entirely in the same location, the commands are the same, etc.

For the purpose of this evaluation, I am limiting my comparison to the latest two versions of the 64-bit x86 platform for each distribution and how they differ when run on VMware’s latest released version of vSphere (4.1U1). Partially this is being done to save me time and effort, but also these are the platforms you would decide between if you were looking to maximize database system performance.

Note: At the time of this writing, RHEL 6 and OL 6 were NOT certified for most Oracle products. This is due to the fact these versions are relatively recently released and Oracle is still certifying their products on the new versions. Also note that the VMware / SLES promotion is limited to SLES 11.

Your main consideration here is whether you just want access to patches and updates or if you want actual support with your issues. In my nine years of running Oracle on Linux, I’ve had to open a total of two tickets on Linux support – once with RedHat, once with Oracle.

o SLES – If you’re running vSphere 4.0U2 or later and are active on qualifying VMware vSphere Software and Services SKUs, you can run an unlimited number of virtual machines and get free subscriptions to patches and updates of SLES 11 SP1. Phone and online support has varying levels and costs. You can read more about VMware’s SuSE agreement.
o OL – Oracle Linux is free to download in compiled form. If you want a subscription to patches and updates only, the cost is $119 per year per server for an unlimited number of physical CPUs. Phone and online support has varying levels and costs. You can read more about Oracle Linux in the Oracle Linux FAQ. You can also check out the Oracle Linux support pricing guide.
o RHEL – RedHat Linux can only be downloaded in compiled form with a subscription. The cheapest subscription is a Self-Support subscription which comes with a subscription to patches and updates and no other support for $349 per year per server, where each server is limited to a 2 socket configuration with 1 virtual guest. Phone and online support has varying levels and costs. You can check out the various support options and their cost on the Redhat website.

Features offered by VMware:
Do you want to use VMware features such as Paravirtualized SCSI (PVSCSI), Hot Add Memory or Hot Plug vCPUs? Do you have a specific requirement for Enhanced VMXNET Networking?

Not all the distributions and versions support all these features. For example, if your database workloads are very I/O intensive, SLES is probably not a good choice.

o SLES 10 – Networking: e1000, Enhanced VMXNET and VMXNET3 are supported. A standard install will default to e1000.
– Storage: PVSCSI is NOT supported
– Hot Add: Hot Add Memory supported, Hot Plug vCPUs NOT supported
o SLES 11 – Networking: e1000, Enhanced VMXNET and VMXNET3 are supported. A standard install will default to e1000.
– Storage: PVSCSI is NOT supported
– Hot Add: Hot Add Memory supported, Hot Plug vCPUs supported
o RHEL 5.6 – Networking: e1000, Enhanced VMXNET and VMXNET3 are supported. A standard install will default to e1000.
– Storage: PVCSCI is supported. PVSCSI is NOT supported on hard disk 1 of the virtual machines.
– Hot Add: Hot Add Memory supported, Hot Plug vCPUs NOT supported
o RHEL 6.0 – Networking: e1000, VMXNEXT3 supported. Enhanced VMXNET NOT supported. A standard install will default to VMXNET3.
– Storage: PVCSCSI is supported. A standard install will default to PVCSCI.
– Hot Add: Hot Add Memory supported, Hot Plug vCPUs supported
o OL 5.6 – Networking: e1000, Enhanced VMXNET and VMXNET3 are supported. A standard install will default to e1000.
– Storage: PVCSCI is supported. PVSCSI is NOT supported on hard disk 1 of the virtual machines.
– Hot Add: Hot Add Memory supported, Hot Plug vCPUs NOT supported
o OL 6.0 – Networking: e1000, VMXNEXT3 supported. Enhanced VMXNET NOT supported. A standard install will default to VMXNET3.
– Storage: PVCSCSI is supported. A standard install will default to PVCSCI.
– Hot Add: Hot Add Memory supported, Hot Plug vCPUs supported

Note: Previously OL 5.6 was listed in VMware’s certified list as NOT supporting Hot Add memory, but this has been changed recently.

Note: On OL, the new Unbreakable Enterprise Kernel (UEK) is NOT supported under VMware. You will have issues installing the VMware Tools if you are running this kernel.

Many companies standardize on one or two operating systems for their organization to minimize support costs. When bringing virtualization into the mix, your organization should re-evaluate your operating system choices to to get the performance and features you need.