Two days ago Oracle published a video about the world’s “fastest database machine.” This, of course, refers to Exadata. Although the video has been online for two days its view rate is very low (less than 1,000). So, I thought I’d refer to it and give it a boost.
This is actually an interesting video. The folks in the video—namely Juan, Kodi, Amit and Ron—are some of the class acts in the Exadata organization within Oracle Server Technologies. I have respect for these folks and I’ve known some of them for many, many years and the remainder at least dating back to the commencement of my tenure in Juan Loaiza’s organization back in 2007. They mean well and I mean it when I say they are a collective class act. Having respect for these gentlemen doesn’t mean I have to agree with everything they say. To that end I aim to respectfully offer some differing views on some of what has been said in the video.
I’d like to first offer my commentary regarding the messaging in the video after which I’ll provide a link.
- The World’s Fastest Database Machine. The first point I’ll make is about the title of the video. Exadata is very good at a lot of things–obviously. Readers of this blog know my position on the matter quite well. That aside, I have a problem with the notion of referring to Exadata as “the world’s fastest database machine” without any data to back up the claim. That was a point of contention I had when I was still with Oracle. Exadata is not the established fastest machine in any database category as per the standard in the matter—which at this time is Transaction Processing Council (TPC) workloads. For that matter even the lower-level Storage Performance Council workloads would be a starting point for validation of these claims (particularly the unstructured data claims made by Exadata marketing) but to-date there are no audited industry-standard benchmark results with Exadata. Please don’t get me wrong. I’m not harping on the lack of published benchmarks for the many reasons I point out here. I’m only making the point that claims of world dominance should be backed up with industry-standard proof points. As for industry-standard benchmarks, the world’s fastest database machine for OLTP is the SPARC SuperCluster. The world’s fastest database machine for DW/BI/DSS is Dell kit with Exasol at every scale except 30 TB where Oracle Database 10g on HP Superdome (Itanium) remains the top-dog. I’ll point out that the only independently validated proof point of Exadata, to date, was the Winter Corporation proof point I did back in 2009. With that memory in mind, I’m led to the next point of contention with the video.
- Setting Out To Build The World’s Fastest Database Machine. The stage for the video is set right at the beginning when Juan speaks of the motive behind building the “world’s fastest database machine” when referring to Exadata. The problem is that the product name Exadata came long after what was actually being built. When Exadata was first released, the term only applied to the storage cells. The first embodiment of a Database Machine was the HP Oracle Database Machine which included Exadata Storage Servers. When Sun Microsystems was acquired by Oracle the Exadata brand was sort of promoted to mean everything in the rack and, of course, current work for ports of Exadata storage connectivity (iDB) to such platforms as HP-UX were dropped. So what’s my point? There was, in fact, a port of iDB that allowed the HP-UX port of Oracle Database 11g instances to connect to Exadata Storage Servers but the effort was killed and the mutual respect between long-time partners Oracle and HP crumbled. Personalities sometimes get in the way it seems, but I digress. The very fact that such porting was in progress sort of suggests that what ended up being the only embodiment of Exadata technology was clearly not always the plan for the technology and thus the notion of “setting out to build the world’s first” seems more like hind-sight. In the “olden days” we looked at Exadata as optimal storage for Oracle Database—nothing more grandiose than that. But those were exciting and rewarding times nonetheless!
- Ideal System For Running The Oracle Database. Juan points out that one of the goals in Exadata development was to create the ideal system for running the Oracle database. I think that is a good design center, but I stand fast in my position that the ideal system for Oracle database depends on the workload. There is no one-size fits all. The one-size fits all positioning is pervasive though. Another member of Juan’s team, Tim Shetler, garners the same level of esteem I have for those I’ve previously mentioned but I don’t always have to agree with him either. In this article in Database Trends and Applications, Tim puts it this way (emphasis added by me):
Our mission around Exadata is to create absolutely the best platform for running the Oracle Database. Those words are carefully chosen because it is very focused. It is not the best platform for running databases. It is not the best platform for running data warehouses on Oracle. It is: Any application that uses the Oracle Database will run best if it uses the Exadata platform to host the Oracle Database.
Do As I Say, Not As I Do
The problem I have with this idea that Exadata is the best platform for Oracle database full-stop is in spite of being “the best platform for running databases”, and best for “any application”, Oracle IT doesn’t even use Exadata for ERP. We know from reading Oracle Corporation’s Mission Critical Systems Update (Google Docs View) that years after the production release of Exadata, Oracle IT migrated from older SPARC gear to an M9000. This is Oracle’s central ERP system. Nothing is more critical than that. This may sound like FUD, but the migration started last September (2010)—years after Oracle approached customers to adopt Exadata technology—and the configuration is still being expanded. I quote :
The additional M9000 SPARC system installation began at midnight March 3rd, 2011, and was completed, in full, at 11:31am the next day, March 4th, 2011. There was no down time of the live GSI database/ERP systems during installation by the Oracle PDIT staff.
— Chris Armes, Sr. Director, Oracle Systems
Let me paraphrase that. The core ERP systems at Oracle (they are not Exadata) were still being built-out as I was finishing my two-weeks notice of resignation from my position in the Exadata development organization! That hardware is going nowhere soon. Do As I Say, Not As I Do.
I’ll watch the view count on that YouTube video while I consider Part II in this series.
I was just joking about giving the video viewership a boost.
Here is the link: http://www.youtube.com/watch?v=ZHlFDgci9Fc
Hi Kevin,
Thank you pointing to the link to Oracle’s GSI ERP implementation. It raises a very valid question that while Oracle’s sales people are out there trying to sell Exadata to its large enterprise ERP custmers, why did Oracle decide to go a different route and implemented it on M9000 servers instead. Was it due to one or more of the following reasons:
– Oracle does not consider Exadata as a suitable platform for an OLTP to a hybrid type workload which is what a large implementation of ERP typically is.
– It was easier to port their ERP application to a like platform (from Solaris to Solaris) as opposed to a cross-paltform migration (from Solaris to Linux, I am assuming that Exadata is not yet available on SPARC?).
Hello Amir,
Exadata storage is Linux only. Connectivity to Exadata Storage is only Linux or Solaris Express (x64).
I cannot speak as to the reasons they don’t use Exadata in critical systems. Doing so would only sound like FUD.
Do you happen to know if Oracle Corp. does use Exadata internally for anything else (if not primary ERP)? Some other DW or may be OLTP? Something big?
Hi Craig,
Yes, I do know. The Oracle IT systems with Exadata are 1) a low-end data warehouse and 2) a very large email system. In the warehouse case Exadata displaced an old 4-node cluster of 4 socket, Dual-core Opteron (4s2c Opteron 8000 Socket-F) servers attached to Netapp filers via multiple 1GbE paths (NFS). For more on the email (“Beehive”) implementation see: http://goo.gl/8goiW
Would not a very large email system (according to the slides though it’s much more bigger than just email) be a good example of the Exadata, RAC, Oracle RDBMS options i.e. the entire stack usage? Isn’t it an example of a system being ‘critical’-enough for a company of 100K employees? And be quite a show case to customers? I believe a number of transactions there is quite significant, as well as user’s data access patterns has a variety and since it’s centralized DBA/IT personnel has some reporting there too for analysis, etc. i.e. (speculation!) it exercises the DW related aspects of the Exadata? So can not that be a valid OLTP show case + a bit of DW aspects? I tend to think that migration of the in-house ERP onto Exadata stack is not a technical problem but rather a management decision. For instance, to have yet another show case for the Sun/Oracle hardware? If so can you elaborate a bit more on “I cannot speak as to the reasons they don’t use Exadata in critical systems.” statement? What would you call a critical system, because the term critical is not defined here at all. In my opinion “critical” is anything that makes any company business up and running w/o interruption so the company does not lose money. I believe if any company’s email or any other kind of communication system would choke during the end of year or quarter closing there going to be some implication, so it should be running 24×7 i.e. it falls into a category of missing critical systems. Thanks.
Hi Craig,
Yes, the beehive system is a showcase for how large an Exadata configuration can get.. However, having endured countless email outages as an Oracle employee it is my opinion that email is not absolutely critical in that culture. ERP is critical. Period. There are tens of thousands of silent majority (current Oracle employees) who know full well how unreliable that email system has always been. I’m absolutely not fingering Exadata for those many outages by the way. I sort of don’t care why email was down so often. That’s just a memory now. But those outages spelled out to me how non-critical email was in that environment.
Oracle is urging customers to run ERP on Exadata not email. Is Oracle email software (Collaboration Suite) very popular software?
I’m not here to split hairs or chew the FUD. It is my opinion that ERP is critical. Email is much further down the pecking order. An important application, but it isn’t ERP.
Let me ask a question: If you were on the line to choose Exadata for your ERP, would someone pointing at an email system really seem like an apples comparison? Would your mind be at ease?
Email does not stress Smart Scan. That is not to say, however, that Exadata has not been a great block server for that particular application because it has. There are over a hundred cells attached to a very large RAC cluster after all. The balance is out of whack for iDB data flow, but the cells are really just good block servers any way so no matter.
As for “yet another show case for the Sun/Oracle hardware”, that’s plausible but then again I wasn’t blogging about a video where Oracle is stating the M9000 is the best platform for Oracle Database either. I was using the case in point about Oracle staying with SPARC for the company jewels as a counterpoint to that assertion. They are both great platforms for Oracle so Oracle made a reasonable choice to put the most critical business system on M9000.
Aren’t you going to ask what storage the M9000 is connected to for the Oracle GSI? If it was Sun storage (nee OEMed Engenio) don’t you think there would be specific mention of that in the PDF? Is that just FUD? I’d like to know.
Putting aside outages, because as you said that you being a user over there did not really care why things aren’t up and running. Although there could be a numerous reasons of an outage, starting from a user’s client, network, application, bugs in application, bugs in RDBMS, up to an Exadata cell. However as a performance architect over there you should know the details of one of the biggest internal Exadata deployment and be aware of why things aren’t working as they suppose to be i.e. the actual reasons of any outage. It as well could be outside of the scope of your responsibilities but then a natural curiosity typically starts playing its role
I know that you probably cannot talk about it here due to NDA reasons. So, we have to put the outages aside because nobody here neither you nor me know the actual *technical* reasons of those.
Your question “If you were on the line to choose Exadata for your ERP, would someone pointing at an email system really seem like an apples comparison? Would your mind be at ease?”
Why do you think I would ask this question? Our company uses some other vendor to do all ERP stuff. We use Oracle RDBMS for some other internal system. So, whatever Oracle uses internally as an ERP may practically be irrelevant for me/us. It would be yet another reference about a system using Exadata. However, if you happen to know which of those two application would really exercise the Exadata and RDBMS stack, that Oracle internal ERP or that very large collaboration system, that would be indeed interesting.
So for me as a potential customer it would become clear what they (Oracle) really saying? In terms of number of users (I don’t believe that you, being Oracle employee used ERP on daily basis i.e. even there could be an outage it probably won’t be noticed by all Oracle employees, but of course if they cannot send emails or use other communication facilities of that particular application – everybody starts screaming. When google email stopped working for a couple of hours the entire world noticed that), transactions per second, data volume, changes in the system, what internal deployment caught most of the bugs in the stack, so me as a customer would not be worrying about those aspects? What of those two would really put the Exadata hardware and software under the stress?
Therefore, I need numbers to compare and make it apples to apples comparison.
I guess to answer your question we have to put aside what exact application is using the Exadata but how it’s using it and under what conditions it can all break and to have my mind at ease I have to understand how reliable that stack is.
To make it all stated simply I don’t care what runs there ERP or anything else, but anything that puts the Oracle products under daily heavy stress testing and being widely used internally and externally would help me to make a decision, at the end it’s all applications they do DML and have the data stored/retrieved.
> what storage the M9000 is connected to for the Oracle GSI?
Sorry, I could have overlooked that information. Do you know what storage is used?
> Is that just FUD? I’d like to know.
Me too. But what *exactly* (at technical level) would make you thinking that Oracle IT/management is afraid of migrating their ERP on Exadata?
Thanks.
Hi Craig,
The purpose of this blog entry is to use case-in-point about how realistic the claims of Exadata being the best platform for Oracle Database bar none. If those claims are real but Oracle is not using Exadata for the systems that book revenue it makes me scratch my head and perhaps others who read this blog. I don’t want to go into any more detail about that huge email system and its uptime characteristics. I said I don’t care why about the cause of those outages. I didn’t say I’m not aware of why the outages occurred. The point is just not germane to this post. Bugs are bugs. Believe me when I say this, “All software has bugs.”I don’t blog about bugs because that is just slinging mud. I don’t aim to sling mud. I aim to closely analyze the claims that are being made about Exadata though.
I also know what storage is connected to that M9000 (Global Single Instance) but I’m not going to talk about that. I will say, however, that it is certainly not Exadata which takes us full circle back to the topic of this blog entry.
“However as a performance architect over there you should know the details of one of the biggest internal Exadata deployment and be aware of why things aren’t working as they suppose to be i.e. the actual reasons of any outage.”
Craig, you do know that I resigned from my position of Performance Architect at Oracle, right? The way this is worded it seems as though you might think I’m still at Oracle.
“It is my opinion that ERP is critical”…
Reminds of a DR analysis we did once at a mining company. Mining ran 24x7x365, with vast array of systems that controlled various components on the mining operation (truck movements, digging locations etc etc).
Everyone was rating all these low level systems in terms of DR recovery, but at the end of the meeting on: “After catastropic disaster, which system must be available first”…the answer was: Payroll !
No payroll = no employees = no mining operations….
Hi Connor,
Thanks for stopping by. Payroll is critical. Booking revenue is more critical. Much more.
> If those claims are real but Oracle is not using Exadata for the systems that book revenue it makes me scratch my head and perhaps others who read this blog.
I am sorry, but you have not provided any single idea or even a reasonable guess, based on any single *technical* fact or *figure* or *tests* of why they could not be using it. I would say that you can scratch your head doing guessing of why they are not using Exadata is making your readers thinking that something is wrong there. I guess nothing is wrong you just left the company and your point of view is changed. Wondering why you could not use your power and influence any internal implementation working as an architect at Oracle and even lead GSI ERP migration project from anything they used before to Exadata if you thought that would be a perfect show case.
Also, it looks that a tone of your posts about the “success” of Exadata is changed after you left the company. To me it just an indication of some other things rather than any technical merit.
Thanks for your time explaining your point of view.
Craig wrote: “I am sorry, but you have not provided any single idea or even a reasonable guess, based on any single *technical* fact or *figure* or *tests* of why they could not be using it. ”
There is a difference between “can’t” and “don’t.”
Craig, you’re missing the point. Since I have not said they “could not be using it” (Exadata) I don’t need to give ideas or guesses, reasonable or otherwise as to why they aren’t using it. The only point being made is that they don’t use Exadata for the bread-and-butter system (ERP) and proof for that requires no musings from me. They wrote a paper discussing the whole thing (staying with SPARC and adding to the config as late as 3/2011).
Let me rephrase that: Kevin Closson has not written any words to the effect that Oracle has chosen to stay with a non-Exadata platform because Exadata is not a capable platform. Kevin Closson has not said Oracle can’t use Exadata for ERP. Oracle has said they don’t use Exadata for ERP in an Oracle-branded paper.
My point of view did not change after I left Oracle. My point of view was in fact why I left Oracle. My point of view was, and is, that Exadata is being over-positioned and I wasn’t about to change the marketing approach for the product. In short, I couldn’t simply “read the memo” and “get on board.” As soon as Oracle referred to Exadata as the “World’s first OLTP Database Machine” I knew I was going to have a problem. Why? well, the only thing that was added to the solution to get this label was a flash read cache and viola it’s now optimized for OLTP? What are common read:write ratios for OLTP? Do I have to cite chapter and verse to make the point that OLTP doesn’t favor a read-optimized platform?
I have pointed out reasons Exadata is not fit for certain workloads in other blog posts and in my contributions to the Expert Oracle Exadata book (Apress). If you’ve read much of my writing on the matter you would be able to quickly rattle off some of the imbalances that can affect Exadata performance (such as the gross imbalance in random RIOPS versus random WIOPS capacity). Other imbalances such as storage CPU capacity versus database grid CPU capacity and the division of work for DW/BI (also known as Asymmetrical MPP architecture) etc, etc. I know Exadata. No system can be optimized for all workloads.
One question that has yet to be asked of me is whether I think Exadata could handle the Oracle GSI ERP system that is currently stuck on SPARC. If someone were to ask me I’d say yes. I do think it could handle the workload. Would it be a smooth ride? No. It would entail risk. It would also most likely require the provisioning of Exadata flash as flash griddisks for write-intensive relations/indexes. While that is a supported usage of the flash assets it doesn’t follow the auto-magical story being told about Exadata Smart Flash Cache. Would I personally recommend such a migration? Not until SPARC is dead (not near-death like it is now, but dead). Migrating from SPARC to x64, from low node-count to high node-count and other such risks is just not worth doing when it is simple to throw a more powerful SPARC system at the problem. Fujitsu is still kindly helping out Sun with the heavy lifting of making large SPARC servers so if you are a SPARC/Solaris shop and don’t want to migrate you have a choice. Oracle still gets your $$$$ because software is where the money is, Fujitsu makes some money and Kevin doesn’t sound like a renegade.
Oracle customers should be allowed to enjoy the same level of choice enjoyed by Oracle IT instead of having a sales guy constantly breathing down their necks about the greatness of packaged apps on Exadata. Oracle should be happy to pocket the software license and support monies they deserve and let the customer pick the best of breed platform he/she chooses. Until the day Oracle is only supported on Oracle Linux, Solaris and Windows (can you see the future?), customers should be free to choose their platform. That freedom of choice is why Oracle database became the best and dominant database in the market in the first place. Remember the term Open Systems? I do.
I’ve said before many times, namely in the Oracle-L list and CDOS Usenet: the only reason Oracle became a success story was the portability of its code and implementations.
The day that ends, Oracle is finished.
With the loads of people in Oracle nowadays from multiple aquisitions of companies who hated the product anyway, I am not surprised of a move to close down the product: best way to kill a company id from the inside, we all know that…
Value proposition? None whatsoever. But let’s not stop the clowns, it’s always fun to watch.
Hi Noons,
Well, that’s pretty harsh. I just want well-behaved fair competition (well, co-opetition really). I don’t understand the mood out there. I’ve received a significant email tongue-lashing of the “how dare you” tone from readers in response to my calling out some of these storyline breaches. It’s been weird.
I ought to know better than to disagree with Noons, but portability is not the only reason for Oracle’s success, though it has allowed for continued success by being able to both anticipate and follow the market as needed. Aggressive marketing was and is a big part of the success. Some consequences of this aggression offend all of us who want a fair comparison. There is a top-down corporate culture at work here, and that is what determines the relative importance of technical versus business practices.
Those of us who are on platforms being marginalized feel Oracle is being heavy handed (or outright DEC-stupid), but that doesn’t mean going forward it is a bad business decision for Oracle. Perhaps Larry has looked at the auto industry or negative utopia fiction and decided a small number of large players is a natural economic force, and any others are just unimportant in the medium term. Or maybe all the top players are egocentric and make emotional decisions, who knows? Outside forces such as intellectual property law changes or general political and economic collapse may distort the outcome anyways. Though I note Oracle Europe is hiring bigtime.
Nevertheless, we do not know whether Oracle “management” considered migrating ERP to The Oracle Database Machine and what Cost/Benefit analysis they undertook.
Yes, that they don’t use the Oracle Database Machine for their own ERP system counts against them. It also reflects the fact that a decision and implementation to the Oracle Database Machine isn’t easy.
I am yet to be convinced that the Oracle Database Machine is good for ERP. In my opinion, FWIW, it is the FlashCache that is the differentiator for ERP.
Exadata Storage, itself is the differentiator for DWH/DSS.
Hemant,
That “we” doesn’t include me. I know. But, again, none of that matters. The only point that matters is that the claim remains: Exadata is the best platform for Oracle database. That claim leaves no room for continued usage of SPARC gear for critical systems within Oracle. You can’t have it both ways, neither can they.
Your comment about ERP on Exadata may be too harsh. I know of customers that run E-Biz on < 4 processor cores! I'd think that any Exadata configuration would be a good step up in such situation. But please, don't confuse what I just said as an insinuation Exadata can only replace 4c servers for E-Biz. That’s not what I’m saying.
I have some thoughts to share about canned applications on Exadata set for future blog entries. That is unless I loose all my blog readership due to all my seemingly vacuous, unsubstantiated claims. That's not the voice of paranoia speaking. I'm getting email with words to that effect. Bizarre.
> Craig, you’re missing the point.
Yes, I probably missed you original point and it took you several iterations to elaborate on what you actually tried to say while answering my questions. Yes, I did as well as some other readers of your blog or may be even your former Oracle colleagues or whoever else, who contacted you and expressed their thoughts in some form, defining them as “vacuous, unsubstantiated claims”. I asked a simple question and you answered it. And we got two basic ideas here: they do not use Exadata for ERP (“Do As I Say, Not As I Do!” original claim); they use it for running their collaboration platform, but users complain and there were outages (nothing technical can be presented by you at this point). So what your readers can “guess” after reading what you have written? I can tell you now, if that all is being read or quoted anywhere as is w/o careful consideration of the context or what’s being said how and *why* (I still think that your original point is far away of being anyhow technical but a way to express something you could not have said or changed being Oracle employee) and w/o any technical facts presented and it’s being said by a former Oracle employee who was in the Exadata team it all can and would be ***misinterpreted***. And that is what going to happen one way or another. Be prepared for that.
I got all your technical points, you don’t have to re-elaborate them [just] for me again and we are on the same page regarding those. The fact that the Exadata platform is not used for Oracle internal deployments has nothing to do with anything technical because most of the applications would just benefit of it. The decision of deploying the Exadata platform in production cannot be just a technical one and that does not anyhow makes the Exadata platform exceptional. Would any customer including Oracle decide to deploy ***anything*** new a full thorough testing must be performed. That obviously would require resources, budget, etc. And that’s obvious for anybody who is doing *serious* IT and considering the price, licensing, support it would be anybody who plans to deploy Oracle SW/HW.
As for ERP of Oracle. They may decide not to deploy just because it was not a priority after Sun acquisition but rather a requirement was to merge ERPs of two companies into one system as soon as possible and make sure that are able to work efficiently i.e. the migration to Sun HW was a capacity planning decision and possible, as I mentioned above a show case for Sun HW. Also, such change won’t introduce any extra variables into equation. I guess if they decide to migrate (ever) they would rather do it having Fusion stuff (if that is in a good shape at that point) running on Exalogic and have the Exadata as the DB platform. I.e. it would be entirely new stack which they anyway have to test to make a show case for customers. Also that would make the entire road map clear including data migration, patching, etc.
As of the FUD… I am sorry but the content of your original post is a source of FUD, not Oracle marketing information, internal deployments or published video.
I believe I got all the information I wanted to know. Thanks for your time answering my questions.
Hi Craig,
After over 500 blog posts and over 2,000,000 page views I guess even I’m allowed to miss the mark sometimes