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.
Whether disabling x86 cores in the BIOS is a valid means of hard partitioning has been a grey area. In the UK I have had conversations with a couple of customers and Oracle, with Oracle insisting that is is not allowed. Yes, I realise that sounds crazy but that’s what they said (and one of the customers was pretty large). The only option to reduce the licence requirement was to run OVM on the host and have a single VM and limit the vCPUs on it! With any luck at least with the new database appliance Oracle might be now saying that disabling cores in the BIOS is a valid means of reducing capacity. It would be good if they could update the partitioning document to say that specifically (especially given that x86-64 is an increasingly common platform).
Jay,
I’m so sad. You didn’t believe me back in late Sept when I blogged the fact that the Oracle Database Appliance has no Exadata in it? I wrote:
“Oracle Database Appliance has no Exadata software in it.”
http://kevinclosson.wordpress.com/2011/09/22/oracle-database-appliance-bringing-exadata-to-the-masses-and-no-more-patching/
Just joking…I don’t expect folks to believe an EMC guy when he writes about Oracle 🙂
BTW, HCC is an intrinsic feature built in to 11gR2–not a separate license…the caveat, however, is that to use this feature that *all* 11gR2 licensees have paid for you have to additionally buy Oracle storage (Pillar or ZFS SA)…or, use OpenFiler (because there is no code forcing the use of Pillar/ZFS SA)…
Hahaha… Actually I did believe you when you stated the ODA didn’t have any Exadata specific things in it – this blog post started as my thoughts to some Oracle sales reps who strongly encouraged me to attend the webinar. The Exadata part was to remind them as sales people that they need to better inform the mainstream IT press.
I’m actually pretty surprised the ODA got released given the shortcomings I perceive.
Unrelated: since you are an EMC / Oracle guy, I’m surprised you haven’t been contributing on the Everything Oracle at EMC community site. Your input would be quite valuable.
Thanks for referencing my blog post.
I think referencing my earlier blog post would be more appropriate in this case – http://www.pythian.com/news/26741/oracle-database-appliance-what-does-it-mean-for-you-and-your-business/
I’ve read your post attentively and must say I disagree on most points. I’ll add some comments here:
1. It’s not Oracle’s problem that media was expecting mini-Exadata based on leaks from people who didn’t really know what was really coming. Oracle refers to it as a solution positioned below Exadata but it openly warns that there is no Exadata features. On the plus side – you don’t pay for Exadata Storage software either.
2. Upgrade? Well, we solved that problem for the customers. 🙂 There can’t be any more excuses not to upgrade – http://www.pythian.com/solutions/fixed_price_services/EasyMigrate. In fact, we migrate and upgrade for free when customers buy an ODA from us.
3. I think that Oracle needs to work on it’s OAM software still and online patching is one of them but I don’t see OAM as the key value of this platform right now except installation time. It will be valuable after it matures. In the meantime, it’s a bit more work to apply patches in rolling fashion. In my eyes, it doesn’t negate HA features while initially, it won’t be as straight forward as one-command online patching. ODA deployments will be more reliable because they are standardized and this will also make automation easier and more reliable (maybe not from day zero of OAM but it will get there).
4. Mixing production and testing on the same cluster (regardless of ODA) is a compromise that customers must be taking intentionally (or rather no) – if you can’t afford production look-alike test platform, you take the risk. However, there is much less risk with ODA because patches you apply to it are much better tested on it compare to applying patches to a unique platform customers build themselves. Again, it’s not any cheaper to build test environment on generic platform (in fact it’s much more difficult to built it exactly production look-alike).
5. Regarding flexible licensing — again, rolling fashion reboot is the way to go. Regarding first time available. I’ve been emphasizing that it’s the first time it’s available on the *commodity* platform (x86) while in the past it was only available on proprietary high-cost platforms with their partitioning/virtualization technologies (like from IBM and HP).
Disclaimer: I don’t work for Oracle, never did, and has no plans to do so at least in the foreseeable future. I’m a customer of Oracle for last 17 years and counting. I am not from mainstream media either.
I find the blog post somewhat misrepresenting. First, about being a “mini-Exadata”. I have not seen anything anywhere ODA being referred to as one. Nowhere could I find Oracle marketing documents hinting it to have Exadata storage server software. If some sales consultants dropped that sort of hints, that will not be the first time. If the media reported it as such (I haven’t seen such a report), then they didn’t check their facts well. It’s as simple as that. It’s not fair to bash ODA for something they obviously misrepresented.
The beauty of ODA comes from the concept of appliance. It’s true that Oracle license doesn’t come with it; but that’s not a secret. It’s well known from the presentations to the media stories. It may not be affordable for some folks; but in others, especially those with unlimited licenses, this will be a sweet spot.
I haven’t seen the patching process. If it requires the system to be down, then it’s too bad; but then again, there are always exceptions. It can be patched directly in a rolling manner by someone experienced in doing so. What is so wrong with that, considering the original way of managing a RAC cluster? Besides, some situations may allow a complete shutdown. That’s no worse than a single instance anyway.
About being 11gR2 database – again, there is nothing wrong with it. It’s an appliance where the components are designed to work together. There has to be some sort of standardized component. If some organization can’t afford to be on 11.2, well, then ODA is not for them. The ODA specs do some with 11.2; it’s not a surprise.
The point is, like everything else, there will be situations where ODA will be suitable, or not quite so. Anyone considering this will need to at least understand the basic specs before making the decision. The most fundamental of concepts – it’s not a mini-Exadata, it needs 11.2, Oracle license is not included, etc. – are out there glaring at you. If one assumes otherwise, it’s not fair to blame ODA for it. Perhaps those people should not evaluate and recommend systems. Many projects and organizations suffer because people assume a square pole to be round and then blame the pole when it refuses to be coaxed into a round role.
Thanks and regards.
Arup Nanda
One of the toughest obstacles that the ODA is going to face is the misconception that it’s a baby Exadata. It’s not going to give the “extreme” performance bumps that you can see with Exadata…it’s just a solid RAC-in-a-box solution for small to medium sized databases.
One of the real benefits from the ODA is the fact that you can have a RAC cluster built and ready to go in a couple of hours, rather than days or weeks. The price is pretty good as well. You can’t price a pair of Intel boxes with 12TB of shared storage for $50,000.
As far as patching goes, this is a very new product, and the patching process looks like it’s a work in progress. Patching on Exadata was quite an adventure in the early days, but as the product has matured, it’s become much more reliable. Oracle is constantly adding new wrinkles to make the patching process easier for the admins. I expect it to be the same for the ODA.
The value of quick adoption through appliances in DAYS rather than weeks will prevail. Your article doesn’t touch on the number of customers that try to build their own integrated systems and fail due to missing the fine details often documented on the first 5 pages of the install manuals. Whic i do not consider fine details when documented on the first 5 pages. The appliance is about creating repetitive success out of the box at the vendors cost, not the customer. Who else is doing this? Apple.
And no one has mentioned, customers may use existing licenses they own with ODA. Oracle is not forcing the customer to buy new licenses. Migrate existing ones if you have them.
This is a really interesting discussion and I would like to add my thoughts.
First of all, I think it is pretty clear and easy to see for techies that there is no Exa-Technology in the ODA. I don’t care if press or salespeople get this wrong, you should never rely on that information anyway.
Alex: Flexible licensing on x64 has been available for a long time with Solaris Containers, even certified with RAC. You should have seen my OOW presentation last year.
Just doing rolling patches yourself is not an option either because that will break your ODA inventory and support. So it does not matter if it can be done by someone experienced. You simply should not do it. See the docs http://download.oracle.com/docs/cd/E22693_01/doc.21/e22692/undrstd.htm#CIHEFJBA
I think it is wrong to market a machine as HA when patching means downtime. Still, I am very excited about this product and the doc on patching also sounds like they are planning to add rolling patches in the future.
And with it, it will be a great allround platform for a lot of small and midsize deployments. The hardware price is fair (you might get away with a little less cost but that can be neglected when looking at the cost of integrating another solution and both costs are still rather small compared to EE licenses). And the OAM enables customers with less experience to take advantage of features like RAC without a lot of training and implementation experiments.
For partners it is a great chance, too. Traditional software partners without a lot of HW experience can easily sell this product while everybody can point to the fact that this is and will always be a certfied platform that is supported by Oracle and avoid discussions about driver revisions and other annoying things.
@ Arup Nanda “I have not seen anything anywhere ODA being referred to as one”
Following the twitter stream for #exadata, there were many, many ill-informed people claiming ODA was a “mini-exadata” – I was utterly sick of hearing people claim this!
A *lot* were misinformed on this, I don’t know where from, but I think it is fair to say there was a lot of misinformation out there.
@ Alex Gorbachev ” ODA deployments will be more reliable because they are standardized”
Really? Exadata is standardized right? How many botched patches? how many additional one of patches need to be applied on top of the storage server software?
Do we really think the quality control of Oracle patches is great?
@ Andy colvin “Patching on Exadata was quite an adventure in the early days, but as the product has matured, it’s become much more reliable”
Really? How many issues have been found post -release of 11.2.2.4.0 ?
For partners it is a great chance, too.
Maybe that’s the most important part of this comment thread?
To me it comes down to one thing. An appliance that runs RAC isn’t an appliance. It’s implicitly complex, unless you have a friendly partner to help you out.
@ Arup Nanda “I have not seen anything anywhere ODA being referred to as one”
…Oracle has been shifty on this. I covered this in the following post:
http://kevinclosson.wordpress.com/2011/09/22/oracle-database-appliance-bringing-exadata-to-the-masses-and-no-more-patching/
Mark Hurd, quote:
… the Oracle Database Appliance brings “the benefits of Exadata to entry-level systems.”
I’d usually consider an quote such as this to be misleading, but I honestly think Hurd is just, generally, not properly briefed by his staff…on a routine basis.
Phrases like this make people think there is Exadata in the solution. Can you blame them? Oracle has done a “good job” getting people to believe that offload processing in Exadata assists in OLTP too.
And, yes, I can cite chapter and verse references for all of these assertions but it isn’t worth the time at the moment.
@jason:
There was a misconception around the time of the launch announcement that ODA was a mini-Exadata, but Oracle’s been pretty good in dispelling that myth. Unfortunately, it’s hard to calm down so many sales people with a quota to fill…and you should never trust a salesman!
Just like Exadata, this is a system to solve specific (and very different) kinds of problems. They’re not the solution for everything and everyone.
I’d have a hard time saying that Exadata isn’t a standardized environment compared to a “typical” RAC buildout. If you open an SR, Oracle will automatically know that what your hardware specs are, what revision of the OS you’re running, kernel versions, network components, etc. That’s where the benefit of working with an engineered system comes into play. You don’t waste that time with support punting off to another vendor for Exadata issues. You’ll get that same benefit out of an ODA, which is one of its prime selling points…a system that is easier to manage from top to bottom.
As for patching, I was speaking to the patching process. A year and a half ago, there were many issues around the patch application process, so much so that I wouldn’t recommend rolling patches to clients of mine that have Exadata. There have been very few occasions where a client has had to apply a oneoff for a storage server. As for issues found post 11.2.2.4.0, I wouldn’t advise anybody to be running it in a production environment, as it’s only been out for a month. No way that it should go into production without thorough testing, as these patches affect so many different pieces of the Exadata stack.
Going back to the issue at hand, the ODA is a brand new product, and there is certainly room for it to grow. As an Oracle partner, it could be a great product for us to sell to customers, even if it does take away some of the services that we would traditionally be selling (RAC build, fault testing, etc).
Bjoern, never looked at Solaris Containers at x86. Didn’t really see it have any noticeable adoption. But good point.
Jason, Exadata is actually quite complex and has had lots of completely new technology inside. ODA is architected much simpler, and has ZERO new technologies inside except maybe OAM software itself. It’s all about how it’s packaged, supported and sold as standard platform. Rate of patch failures on ODA and generic platform can’t be the same unless Oracle really screws something up badly, which I don’t believe will happen.
I am bothered by the Oracle prepared commentary on ODA including comments about Exadata in conjunction with ODA. These comments are not misleading to technical people, but they are not specific enough to avoid confusion for those that are less informed. And that creates confusion.
Even stating that ODA is a lead to migrate into Exadata is misleading when that requirement can be done with any 11gR2 database on any system. Doesn’t make ODA any specialized lead to Exadata.
Any iputs on if we can host
both oracle R12 apps and dba one one ODA box ?
You cannot (well, not in a supported by Oracle fashion) and this is one of the reasons ODA doesn’t make sense to me. You can only host Oracle databases on an ODA box.