This blog is by a long-time Oracle storage professional who has history with both NetApp and EMC.

September 05, 2012

Given the incredible number of comments I received on my last blog post, and the content of those comments, it is very obvious that folks are extremely confused by what I meant by that post, as well as the comments by Mr. Garsthagen (Oracle Director Level Employee), referenced in that post.

The confusion is typified by the following comment, the most recent I have received:

Oracle does not recognize either (Vmware/DRS Affinity) as a hard partition

First, to be completely clear, I have never stated, nor do I believe, that VMware (or any other software hypervisor for that matter) constitutes hard partitioning as that is defined in Oracle's own documentation. Hard partition has to do with licensing a subset of the cores on a database server. I have always maintained that all cores on a physical server where Oracle is installed and/or running must be licensed to run Oracle.

The issue has to do with licensing of a subset of servers in a VMware DRS / HA cluster. Prior to VMware's white paper on Oracle licensing and support, I maintained that the most conservative position was to create a dedicated Oracle DRS / HA cluster, and thus limit VMs running Oracle to only that set of servers. This illustrated as follows:

First of all, the issue with the above approach is simple: Not all customers have the necessary scale of Oracle servers in order to dedicate an entire VMware DRS / HA cluster to just running Oracle. For these customers, it is important to have Oracle VMs limited to a subset of the servers in the cluster. The following would illustrate this:

The essence of this approach is that the configuration must limit Oracle VMs to a subset of the physical servers in the cluster. This complies with Oracle's License and Service Agreement (OLSA), the only relevant document covering Oracle licensing, which states that Oracle software licensing attaches to the CPU cores on physical servers on which Oracle is "installed and/or running". Thus, if you provide a mechanism to limit the physical servers where Oracle VMs are allowed to run, and also provide a methodology to track this over time, then that method satisfies the OLSA.

Fortunately, VMware vSphere provides such a mechanism: It is called Mandatory Host Affinity, and means that a VM is only allowed to either boot or migrate (via vMotion either manually or through a DRS Cluster load balancing process) onto a defined set of servers only. VMware vCenter also provides VM logging which provides a detailed record of the physical servers on which each VM has run. Finally, license compliance software vendors such as iQuate provide tools to track each Oracle VM's location on physical servers within the cluster, and this tracking data has been certified and accepted by Oracle for licensing purposes.

The net-net is that the issue of Oracle licensing of a sub-cluster within VMware vSphere has been resolved, as indicated by Mr. Garsthagen in his online video. He simply restates the obvious. VMware vSphere provides tools which allow you, the Oracle customer, to license a subset of a VMware DRS / HA cluster, provided that you:

Enforce strict rules regarding where the Oracle VMs are allowed to run

Track compliance with those rules over time

Are prepared to provide this tracking data to Oracle LMS on demand

At this point, numerous Oracle customers have provided this data to Oracle LMS and have been allowed to run Oracle on a VMware sub-cluster with no problems in terms of licensing.

Again, to reiterate my clarification, it was never my intent to imply that VMware vSphere (or any other software hypervisor) provides hard partitioning. Hopefully, this is now cleared up. Please let me know your thoughts via comments to this post.

August 30, 2012

As all of my readers know, I have been a strong proponent of VMware virtualization of Oracle Database servers for license cost savings purposes. Predictably, Oracle has pushed back on this issue in the past. Well, they have now thrown in the towel.

In an online video, Richard Garsthagen, Director of Cloud Business Development EMEA for Oracle, has stated publicly that VMware host affinity rules (when combined with vMotion logging) work just fine, thank you very much, for purposes of establishing where Oracle software is "installed and/or running" for purposes of the Oracle Software License Agreement (OSLA).

Previously, Oracle has maintained that all servers in a cluster must be licensed if even a single VM on any server in the cluster is running Oracle software. VMware has officially disagreed with this statement in their white paper on Oracle Licensing and Support. But the opposing view by Oracle has been a serious deterrent to adoption of VMware virtualization of Oracle servers. No longer.

I think we can consider this issue closed. Customers can now virtualize Oracle database servers without any concern about Oracle hitting them with unreasonable license cost demands. This is undoubtedly great news, and a great watershed event in this area.

July 24, 2012

As many of you have heard by now, Paul Mauritz is out as CEO of VMware, and Pat Gelsinger (formerly COO of EMC, reporting directly to Joe Tucci) is replacing him.

The relevant question for those of us who care passionately about Oracle virtualization using VMware vSphere is:

What does this mean for VMware's BCA (Business Critical Applications: stuff like Oracle) strategy (which under Maritz was somewhat lacking)?

In my view, this is very, very good news indeed. The reason is simple: Paul Maritz was former Microsoft, and thus very Microsoft-centric. Under Maritz, VMware very successfully penetrated the Microsoft space (especially Exchange). BCA, and especially Oracle were not that well supported by VMware's high level leadership in my view.

There is no question in my mind that Pat Gelinger gets it with respect to the importance of Oracle for VMware's future. (As I have said before, I believe that Oracle is the most interesting virtualization target environment for VMware, period.)

July 23, 2012

As my comment on Michael Webster's recent blog post entitled Fight the FUD – Oracle Licensing and Support on VMware vSphere states, I am in violent agreement with everything he says regarding Oracle licensing and support for VMware virtualization of Oracle database servers. I heartily recommend this blog post to everyone concerned with Oracle's recent behavior regarding VMware virtualization of their products.

The reason I believe this session is so important is simple: Every Oracle customer and his dog is desperately trying to get off of expensive, slow, proprietary RISC-based UNIX and onto the x86 environment. The reason for this desperation is simple: Cost. These environments are becoming hideously expensive platforms on which to run Oracle. Huge core counts. And performance is frequently terrible.

For example, EMC IT just replatformed off of their E25K and onto x86 / VBLOCK, in the process improving performance by 2 - 10 X and saving over $7 million per year. Yeah, that's real money.

Trouble is, EMC IT did their migration cold, and it took 16 hours to do so. Many, many Oracle customers have mission critical databases on RISC UNIX which have little or no downtime window. These customers need a migration path off of RISC UNIX which involves minimal downtime.

Another source of trouble: Oracle has such a process, which they refer to as O2O. They offer a service to get the customer off of RISC UNIX and onto x86. But where does the customer end up? Onto ExaData. Not good considering that EMC is the majority incumbent storage company for storing Oracle on RISC-based UNIX. We stand to lose all of these customers to Oracle in other words, if we simply ignore this problem.

The one clear differentiator we have against ExaData: VMware. By migrating the customer off of RISC-based UNIX directly onto VMware vSphere, we innoculate them against ExaData forever. That's because, as we all know, the value proposition for running Oracle under vSphere is very compelling, and quickly becomes addictive once the customer adopts it. vSphere has a high rate of stickiness in other words, especially in Oracle shops.

Bottom line: I think this is the most important subject that we can be talking about right now to Oracle customers.

If you would like to vote for my session, please go to this site (requires a login, but registration is free), and select:

Let me start by bringing all of you into the courtroom. There are three issues that you will observe me as counsel provide to the jury as part of my allowed instruction (I am not an attorney in real life).

I offer the definitions in this paragraph only to make this post as self-sufficient as possible and not with intent to talk down to anyone. Case law refers to precedents established in other court cases. Case law can supplement statutory law enacted by legislative bodies and can stand in lieu of statutory law when applicable statutory law does not exist.

Back to the courtroom:

You cannot prove a negative.

Just about every contract that any of our organizations enters into or sees contains a clause that essentially states that the only terms that are binding have been reduced to the fully-executed instrument itself as well as other explicitly-referenced written material, and all verbal agreements and/or representations are null and void. The language usually allows for the obvious possibility of written, fully executed amendment.

As often as original documents are unavailable, courts in all fifty states recognize case law called "best available image.” This refers to copies which become recognized as legally binding as if they were the original. “Best available image” case law has been universally recognized since 1989 when as the Medical Records Systems Analyst for 23 hospitals and 7 clinics in 3 states, I had responsibility to begin architecture for imaging of medical records.

I offer the following as the exclusive binding source documentation for this post:

The OLSA is bi-laterally executed between Oracle and the customer. I have seen many of them as you can imagine in my role as the lead of House of Brick’s Oracle Enterprise License Assessment business line. The OLSA always contains:

A reference to other unnamed published documentation, which given the nature of the reference, refers to the Licensing Data Recovery Environments extract of the Software Investment Guide as well as the current Oracle Support policy. Because of the nature of these external OLSA references, I make it my business to occasionally archive current versions of the Software Investment Guide and Licensing Data Recovery Environments document such that any given OLSA can be clearly tied to the external terms in effect as of the OLSA’s execution.

A Non-Disclosure Agreement as to the OLSA’s terms. As Oracle publishes template OLSA copies, a reasonable and customary interpretation of the NDA’s coverage is pricing (discounts) as well as any other non-standard qualitative terms that the customer may have negotiated with Oracle. We have initiated for customers and seen Oracle approve non-standard qualitative OLSA terms. However, we have never bothered to initiate sub-cluster licensing terms as there is no need to do so.

The sum and detail of the stock published OLSA and its external Software Investment Guide for at least the last decade and to-date with respect to processor-based licensing is two-fold:

Customers must license all physical cores or sockets on a host where Oracle executables are “installed and/or running” (with physical cores factored per Oracle’s published Core Factor Table, and potentially subject to the so-called 10-day rule [whose terms became more restrictive sometime during 2007]). Notice the tense. Oracle customers are contractually obligated for licensing the physical servers where the Oracle executables are and have been, not where they might go. To imply otherwise without explicit contractual inducement would not be unlike concluding that I am legally obligated to purchase transportation to or obtain a visa for destinations that I clearly have the capability of visiting but where I have neither ever been nor yet made a determination to even visit.

Furthermore, customers must pay a license to cover the use of remote mirroring at the storage unit or shared disk array layer to transmit Oracle executables to a SAN whether or not that set of Oracle executables is “installed and/or running” on any physical host connected to the SAN.

When discussing Oracle licensing, there are two common areas of confusion.

Oracle itself defines both of the terms “Hard Partitioning” and “Soft Partitioning” in its Partitioning document, published since 2002. The document makes clear that both “Hard Partitioning” and “Soft Partitioning” have to do with carving up physical cores/CPUs within a single physical server. It is Oracle’s right to define the terms as they relate to the OLSA. I frequently see Oracle reps (knowingly?), customers and others confuse these terms over into a discussion of licensing physical servers within a sub-cluster. As often as unintentional term confusion occurs, I believe it important for authors to make corrective edits after the confusion has been pointed out, especially on a topic with such scaled financial ramifications.

To say that Oracle has not made a statement supporting vSphere DRS Host Affinity Rules (as has been asserted in this thread) is beside the point. That is clearly in the realm of proving a negative. That DRS Host Affinity Rules may or may not be used as a mechanism to assure that Oracle executables are not “installed and/or running” on unlicensed physical hosts is customer-discretionary and irrelevant to the OLSA’s binding terms. I might add that methods existed to restrict VM movement to a sub-cluster of physical hosts long before the vSphere 4.1 advent of DRS Host Affinity Rules.

I tried to force both clarifications into Gartner Group’s Chris Wolf’s November 10, 2010 blog thread via comment posting. I feel that I failed to get Mr. Wolf to directly address my point before he elected to close the thread. I feel that I failed both verbally and in writing during the pre-publication interview process to preventively insert the clarifications into TechTarget’s Beth Pariseau’s May 4, 2011 article titled “Oracle licensing for vSphere 4.1 irks VMware pros.” Furthermore, the TechTarget article’s title unfortunately implies that Oracle may have licensing terms specific to vSphere version 4.1, which it does not, or licensing terms specific to VMware technologies in any way, which it does not. Thankfully the November 2011 VMware Corp. whitepaper (to which I contributed) “Understanding Oracle Certification, Support and Licensing for VMware Environments” got it right. I can confirm that the entire white paper received all the multi-disciplinary pre-publication review that you would imagine appropriate for a piece of its importance and ramifications.

House of Brick is occasionally invited by customers and/or partners to get on the phone with Oracle to deal with Oracle licensing concerns that Oracle has verbally conveyed to the customer. We always welcome these opportunities. The most recent call was a couple months ago. An Oracle Corp. licensing specialists was on the call. The impetus for the call was that Oracle had previously told the customer that all nodes in a physical cluster must be licensed, not just those where Oracle executables are “installed and/or running.” We asked the Oracle licensing specialist about the statement. He informed us that it was Oracle’s policy. We asked where the policy was written. He replied that it is an unwritten policy. At this point, we reminded him of the binding OLSA language whereby all verbal conveyances and understandings were voided at the execution of the document leaving only the printed OLSA terms in effect. That was the end of the discussion. The customer left the call entirely and appropriately satisfied as to their full legal compliance with their proposed sub-cluster licensing scenario. This vignette is by no means an isolated incident. The outcome is always predictable and consistent.

A previous post on this thread states ‘I've heard Dave at HOB contend the same thing you've heard, which is essentially: "DRS/Host Affinity SHOULD be fine"...’ The quote could be interpreted inappropriately out of context of my consistent, persistent statements. What I have always said is that any method (manual or automatic) to restrict movement of Oracle executables to a licensed sub-cluster of physical hosts is fully OLSA-compliant and legally defensible. At the release of vSphere 4.1, I added the statement that DRS Host Affinity Rules happens to be one, the newest, and the easiest of multiple available methods of restricting Oracle executables’ movement.

There are comments on this thread that I believe fall under the umbrella of attempting to prove negatives. Oracle has no legal obligation to go on paper with sub-cluster licensing clarifications specific to vSphere. In my view, Oracle has no financial incentive to do so. Stop looking for that to happen.

Occasionally people actually insist that I produce an Oracle-authored document that says Oracle will not ding them for not licensing all nodes in a physical cluster. That strikes me like asking me to provide an Oracle-authored document that says Oracle will not make a claim against me for choosing to drive a Ford as opposed to a GM. Not only is it asking me to prove a negative which I cannot do, but it delves into an area that is none of Oracle’s business since it is not listed in my OLSA obligations.

I see no need for Oracle to comment on their recognition of the validity of vSphere logs to prove vSphere VM movement. vSphere logs may well be the best available mechanism to document Oracle executables’ travels. Although vSphere logs may not be identical to “best available image” case law, “best available image” is instructive to the audit log/verification concept under discussion. As of November, 2010, the majority of the world’s servers are virtual. ~85% of those virtual machines are VMware. That is tenured technology and no one is questioning the de facto authority of those logs. Oracle has the OLSA-granted right to present themselves at any time without notice for the compliance inspection of their customers’ physical hardware. Oracle has options to audit the current and historical location of where their executables are “installed and/or running.” That those options may rely on mechanisms not provided by Oracle is beside the point.

As for the question on the thread as to whether vSphere logs could be maliciously manipulated, security industry experts have said that eighty percent of security breaches come from within the firewall. I see a corollary to that statistic. Oracle has plenty of financially incented prospective friends inside its customer organizations. It is sad that human integrity is such that posting of large rewards has become necessary to incent individuals to turn in their employers for knowing theft of software. To me, OLSA obligations are like the U.S. tax code. I believe in paying every penny I owe. However, beyond that, it is my discretion to who or what I donate and in what amount. I have no patience with individuals or entities that premeditate the creation of OLSA compliance issues. I similarly have no patience with the knowing spreading of FUD by some professionals in what could be construed as extortion of funds beyond customers’ executed contractual obligations. I will continue to vigorously promote and defend the legal rights of both software vendors and their customers even if that means I induce accelerated hair loss through rapid, frequent hat swapping.

What Oracle verbally represents on this or any other contractual topic for that matter is of absolutely no relevance whatsoever. Look to the OLSA and extant external referenced documentation as of the OLSA’s execution date. Should you still be dissatisfied, look to court history of judgments against customers attempting to exercise their sub-cluster licensing rights. Let me save you some time. Relevant court history does not exist. There is a simple reason: the terms of your executed OLSA are clear, sufficient, binding. The terms explicitly invalidate any and all verbal representations.

Given what I have presented here, I see no legal, risk management, or moral need for and am not inclined to encourage and/or endorse air gap clusters strictly for Oracle licensing purposes. I am concerned that such talk may scare parties away from investigating, understanding, and asserting their legal rights. Furthermore, in my observation, such talk gets quickly quoted out of context of the original motive. I believe such talk has a similar long-term effect on the market as paying ransom for hostages has on future hostage taking. The SMB market has every contractual right to leverage sub-cluster licensing to facilitate crossing the chasm over to Business Critical Application virtualization. That larger enterprises may find it convenient to use air-gap cluster separation of their Oracle workloads is great, but to do so has absolutely no bearing whatsoever on their legally binding contractual obligations to Oracle Corporation.

Some on the thread have suggested this or that course of action to minimize risk with Oracle. Occasionally people express concern to me that Oracle has far deeper legal pockets than they do. I believe those that make these points do not understand the power of their position. I cannot think of one reason that Oracle could possibly want this thing to go to court and indeed I believe Oracle has everything to lose minimally moving forward if and when it does. Once such a judgment was out, it would cause an immediate slow-down on non-contractual cash donations that some of Oracle’s customers have felt induced to make.

March 26, 2012

VMware has put a stake in the ground with respect to Oracle licensing of VMware VMs running Oracle. The gist of this statement regarding certification, support, and licensing is that DRS host affinity rules, combined with vCenter audit trails showing where VMs have actually run, are sufficient for Oracle licensing purposes. The summary of the document states:

DRS Host Affinity rules can be used to run Oracle on a subset of the hosts within a cluster. In many cases, customers can use vSphere to achieve substantial licensing savings.

vCenter VMotion Logging

Concerning vCenter VMotion logging, the document states:

With VMware vMotion and DRS technologies you can migrate a live virtual machine running Oracle software from Host A to Host B for server maintenance or load-balancing purposes. In such instances you should ensure that the migration occurs between fully licensed hosts by using vSphere capabilities such as DRS Host Affinity—that is, both Host A and Host B must be fully licensed hosts from an Oracle licensing perspective (as described in section 2.1). VMware vCenter™ Server generates several migration log files maintained at /var/log/vmware/hostd.log and /vmfs/volumes/datastore/vm/vmware.log that can be leveraged to track and record such virtual machine movements across hosts for compliance purposes. Additionally, VMware provides an extensive open API that allows compliance tools to generate user-friendly reports using this data. In particular, VMware vCenter Configuration Manager provides host-level change-tracking mechanisms that enable you to record virtual machine movements across hosts. Since this hostlevel change tracking leverages an open API, third-party configuration-management solutions may also provide some of this functionality for VMware environments.

VMware enables you to pin a virtual machine to certain CPUs inside the host (using CPU pinning or CPU affinity). We believe this technology is every bit as robust and reliable as the “hard partitioned” technologies to which Oracle accords preferential subsystem pricing, and should enable customers to license only a subset of the host capacity. Unfortunately Oracle does not recognize this approach as a valid hard partitioning for its licensing mechanism. So today customers must license all the CPUs in the host and follow the “fully licensed host” approach for VMware environments.

Net-Net

The net-net is that VMware is endorsing the view that fully-licensed servers are required, but that Oracle servers can be part of a larger DRS / HA cluster environment, so long as VMs running Oracle are strictly limited to licensed servers, and this can be proven using audit trail documentation.

I cannot overstate the importance of this in terms of Oracle licensing. This is a sea change, folks.

March 21, 2012

I have received a fair number of responses to my previous post on this subject (some via comments and some via email). I thought the discussion worthwhile enough to punch it up a bit more here.

Backup

As I pointed out in the previous post, EMC can easily match NetApp's play to back up ExaData with the following:

As Geoff Rosser so correctly pointed out, this answer is incomplete. Yes, Data Domain is an awesome Oracle backup solution. Yes, it provides incredible deduplication rates for Oracle database environments. (Thanks, dynamox.) However, it is not the only viable solution from EMC for backing up ExaData. For example, the following would also work:

March 18, 2012

There has been lots of material on the web recently concerning NetApp being able to backup ExaData. The purpose of this blog is to respond to that content, and state why NetApp's offering is rather lame, and actually offers nothing new.

The items on the web produced by NetApp are easy to find. I will not increase their Google hit rate by linking to them here. Suffice it to say, Neil Gerren's blog contains the principle content to which I will respond here. There is also NetApp technical report TR 4022, a 34 page tome, which I have read thoroughly. I think I completely understand what NetApp has produced (which they thought so much of to produce a press release on the subject), and, believe me, there is nothing new or unique in NetApp's offering.

I will summarize the solution here. To avoid any issues with NetApp copyrights, I have recreated the graphics describing the solution. However, the gist is identical to that contained in TR 4022. The solution consists of two parts:

Backup

Disaster recovery / remote replication

Backup

Let's start with the backup component. What NetApp proposes is the following:

The fundamental gist of the solution is:

Connect ExaData to a NetApp filer using 10 GbE.

Backup the Oracle database on the ExaData to the NetApp filer using RMAN.

I ask you: Is there anything interesting or unique here? In fact, I would state for the record that it would be manifestly better to do the following:

In other words, an EMC Data Domain deduplication array is capable of connecting to an ExaData box and backing it up using RMAN in exactly the same manner as a NetApp filer. I find this statement so obvious that it seems self-evident. But, again, NetApp's material on the subject makes it necessary to point this out.

Data Domain has many advantages over NetApp in the area of Oracle backup. But I will not belabor that point. Suffice it to say, we can do the same thing that NetApp can in the area of backing up Oracle ExaData via 10 GbE. And we certainly have a product which is very suited to backing up Oracle database data, and commonly used for this purpose.

Replicate the production Oracle databse on ExaData using Oracle Data Guard with physical standby. The target platform consists of generic Intel x86 servers running Linux. (Remember that the RAC compute nodes in the ExaData are nothing more than relatively typical x86 / Linux servers. Thus, Oracle Data Guard with physical standby to a similar non-Oracle server will work just fine, it being an identical platform from an Oracle point of view.)

The target database server is connected to a NetApp filer using standard protocols (e.g. FC or NFS).

Once the database copy is on the NetApp filer, normal NetApp tools can be used to snap, clone, etc. the target database.

Again. it seems rather patently obvious that the following is also possible:

And in terms of the ability to perform snaps, clones, and so forth of the Oracle database once it is on our array, EMC's arrays contain features that easily meet those offered by NetApp.

So, again, NetApp's highly touted offering concerning storing ExaData offers nothing new or unique. Each and every feature offered by NetApp is available from EMC, and many features offered by EMC are superior to those provided by NetApp.

November 11, 2011

Appliances such as microwave ovens, refrigerators, iPods, iPads and TVs are excellent examples of the ease-of-use approach. Bringing the inherently complex world of Oracle databases together with the ease-of-use approach of appliances is challenging. By definition if Oracle Exadata is an appliance then its use should be simple, require relatively little maintenance and like a refrigerator do its job which in this case is run databases at extreme performance levels. If Oracle Exadata isn’t an appliance than what is it?

I found this question quite compelling. Remember that I really grew up in a truly appliance-oriented environment (NetApp). See my first blog posts for more information on my background at NetApp. For this reason, I think I understand what an appliance is pretty well.

At NetApp (and during my early days at NetApp, filers were true appliances by any measure), the appliance concept meant that the device was a toaster: One lever to push down, and one knob to turn. That's it. Plug it in. It works. No step 2.

Cisco really originated the term appliance. The Cisco router replaced the previous form of router, which was typically a UNIX box running routed. As such, the Cisco router pretty much defined the concept of what it means to be a true appliance.

The folks at Cisco made the following argument: We don't need all of the infrastructure of UNIX to do routing. A UNIX box has to do a lot of things. A router really only has to do one thing: Networking. We could make a dramatically simplified device which would be able to do routing really well, at a much lower cost than a UNIX box.

Based upon this concept, an appliance has the following characteristics:

Extremely simple interface. Should be vastly simpler than doing it the non-appliance way. I.e. a Cisco router is vastly simpler than running routed on a UNIX box.

A single purpose. The device must be dedicated to doing one thing, but doing it extremely well. Like the way a Cisco router is much better at doing routing than a UNIX box running routed. Or like the way a NetApp filer is much better at doing NFS file serving than a UNIX box running nfsd. You get the idea. By dramatically reducing the number of functions the device performs, you also dramatically reduce the amount of code that must be run on the device. (The original NetApp ONTAP OS was a single-threaded 16 bit OS with only a few 100K of lines of code.) This leads to the next feature of an appliance which is:

Vastly reduced cost. The original NetApp filer was about a $5,000 device. An equivalent UNIX box used as an NFS file server ran around $50,000. Similar cost differences existed for Cisco routers vs. UNIX boxes as routers.

Transformative technology. An appliance, if it is truly an appliance, becomes the obvious and natural way to do things. Within a very short period of time after introducing the router, Cisco controlled the router market. They completely displaced the previous way of doing routing. The same thing occurred in file serving with NetApp.

By any reasonable measure, Oracle ExaData fails all of these tests:

It has as complex an interface as any Oracle database server (which is to say it runs the most complex and expensive piece of software ever written for general purpose use). Certainly not appliance-like.

An Oracle ExaData rack contains general purpose compute servers, which can be used to run basically anything you want. You can load any Oracle application on it certainly, and no-one would claim that an Oracle database server is an appliance!

Oracle ExaData is manifestly more expensive than a normal, open-systems database server, and vastly more expensive (assuming intelligent management) than using VMware vSphere for virtualizing Oracle database servers.

Oracle ExaData is possibly addictive in the Big Blue sense, but it is certainly not a transformative technology in the same way that a Cisco router, iPad, iPhone, or such is.

In terms of an analogy that works, I like to use cars. The two companies in the car business that manufacture appliance cars are Honda and Toyota. The Honda Civic is an appliance car, as is the Toyota Camry. Either one of these cars provides all of the appliance advantages:

They have a radically simplified interface. Everything about these cars is designed to make them effortless to operate. Because they are so simple, they are also very reliable and efficient.

They are single purpose vehicles. They get you from point a to point b. That's it. Nothing fancy.

They are sold at a very reasonable cost, relative to non-appliance vehicles (such as BMW, or Mercedes for example).

Once you have driven a Honda Civic or Toyota Camry, assuming you are an appliance driver (and there are a lot folks who are appliance drivers), these cars are completely addictive. You simply trade one in for the new model once the old one wears out (and they take a long, long time to wear out). I have known folks who have been driving these cars (in various model years) their entire lives.

Using the car analogy, ExaData is definitely not a Honda or a Toyota. It is not even a BMW or a Mercedes. It is a Ferrari. It is a tricked out, high performance machine. It is very fast, no question. It is *&^% expensive though. And it is very, very complex and demanding to drive.

disclaimer: The opinions expressed here are my personal opinions. I am a blogger who works at EMC, not an EMC blogger. This is my blog, and not EMC's. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.