I recently took a peek at this online, interactive history of Oracle Corporation. When I got to the year 2008, I was surprised to see no mention of the production release of Exadata–the HP Oracle Database Machine. The first release of Exadata occurred in September 2008.
Once I advanced to 2009, however, I found mention of Exadata but I also found a couple of errors:
- The text says “Sun Oracle Database Machine” yet the photograph is that of an HP Oracle Database Machine (minor, if not comical, error)
- The text says Exadata “wins benchmarks against key competitors” (major error, unbelievably so)
What’s First, Bad News or Good News?
Bad News
The only benchmark Exadata has ever been used in was this 1TB scale TPC-H in 2009 with HP Blades. Be aware, as I pointed out in this blog post, that particular TPC-H was an in-memory Parallel Query benchmark. Exadata features were not used. Exadata was a simple block storage device. The table and index scans were conducted against cached blocks in the Oracle SGAs configured in the 64 nodes of the cluster. Exadata served as nothing more than persistent storage for the benchmark. Don’t get me wrong. I’m not saying there was no physical I/O. The database was loaded as a timed test (per TPC-H spec) which took 142 minutes and the first few moments of query processing required physical I/O so the data could be pulled up into the aggregate SGAs. The benchmark also requires updates. However, these ancillary I/O operations did not lean on Exadata feature nor are they comparable to a TPC-H that centers on physical I/O. So could using Exadata in an in-memory Parallel Query benchmark be classified as winning “benchmarks against key competitors?” Surely not but I’m willing to hear from dissenters on that. Now that the bad news is out of the way I’ll get to what I’m actually blogging about. I’m blogging about the good news.
Good News
The good news I’d like to point out from screenshot (below) of Oracle’s interactive history is that it spares us the torment of referring to the Sun Oracle Exadata Machine as the First Database Machine for OLTP as touted in this press release from that time frame. A system that offers 60-fold more capacity for random reads than random writes cannot possibly be mistaken as a special-built OLTP machine. I’m delighted that the screen shot below honestly represents the design center for Exadata which is DW/BI. For that reason, Exadata features have nothing at all to do with OLTP. That’s a good readon the term OLTP is not seen in that screen shot. That is good news.
OLTP does not trigger Smart Scans thus no offload processing (filtration,projection, storage index, etc). Moreover, Hybrid Columnar Compression has nothing to do with OLTP, except perhaps, in an information life cycle management hierarchy. So, there’s the good news. Exadata wasn’t an OLTP machine in Oracle’s timeline and it still is not an OLTP machine. No, Oracle was quite right for not putting the “First OLTP Machine” lark into that timeline. After all, 2009 is quite close to 40 years after the true first OLTP Machine which was CICS/IMS. I don’t understand the compulsion to make outlandish claims.
Bad News
Yes, more bad news. Oracle has never published an Exadata benchmark result even with their own benchmarks. That’s right. Oracle has a long history of publishing Oracle Application Standard benchmarks–but no Exadata results.
I’ve gone on the record as siding with Oracle for not publishing TPC benchmarks with Exadata for many reasons. However, I cannot think of any acceptable excuse for why Oracle would pitch Exadata to you as best for Oracle Applications when a) there are no OLTP features in Exadata*, b) Oracle Corporation does not use Exadata for their ERP and c) there is no benchmark proof for Exadata OLTP/ERP capabilities.
Closing Thoughts
Given all I’ve just said, why is it that (common knowledge) the majority of Exadata units shipping to customers are quarter-rack for non-DW/BI use cases? Has Exadata just become the modern replacement for “[...] nobody ever got fired for buying [...]?” Is that how platforms are chosen these days? How did we get to that point of lowered-expectations?
Enjoy the screen shot of memory lane, wrong photo, bad, good and all:
* I am aware of the Exadata Smart Flash Log feature.
Welcome to history re-writing, comrade…
@Noons : Hey, great to hear from you! Any fun with SLOB lately
Flat out upgrading the dev and test dbs to Aix 7.1/Ora 11.2.0.3 at the moment, Then I’m gonna do another round of SLOB.
@Noons : Sounds like fun!
At the moment I’m finding 7.1/11.2.0.3 around 25% faster on Power6 hardware than the previous Aix5.3/10.2.0.3. This is most noticeable on ops involving large scans, like backups and such. “Low hanging fruit”, and most welcome. IBM must have done some pretty fancy aio tuning on 7.1. Dying to get my hands on a P7 – soon, if things go according to plan. Then SLOB is gonna be invaluable to give us baseline comparisons.
@Noons: Thanks… would love to hear more about P7… Keep us posted…
You give reference to a TPHC that used Exadata and then say no Exadata features were used. How can you say such crazy things? You obviously don’t know what you are talking about
So you want me to prove there were no Exadata features being used in the TPC-H I referred to, is that correct? Also, am I tasked as such because you know for a fact that said TPC-H did use/benefit from Exadata features? If yes, which features do you think were most beneficial to an in-memory Parallel Query result?
BTW, I already have your answer. I just need to make sure you know what question you are asking.
Yes, that is what I am saying
Dear Mr. “Oracle/Exadata Expert”, don’t you think you need to have some generalized database expertise as a prerequsite to claiming to be an Oracle expert? Let me share some with you.
When you keep all of your database in DRAM, then there’s no need to do disk IOPS (except for checkpointing DRAM contents). Remember Gene Amdahl said “the best IO is the one you don’t have to do”?
This is what IMDB is all about. Go ask Larry, he’ll tell you it’s all the rage now.
What Kevin said should have been easily comprehensible to you. Since it wasn’t, allow me to paraphrase.
When you have a 1TB dataset, and you have 2TB of DRAM, even SQL Server is smart enough to load the ENTIRE DATASET into DRAM. When the entire dataset is in DRAM, you are not running queries against data on disk, you are running queries on data in DRAM. Hence, no disk IO, hence no need (nor even any opportunity) to “accelerate” the disk querying process. Hence, no Exadata features were used.
Got it now?
Since I’ve done you the courtesy of educating you, would you mind now commenting on why Oracle refuses to benchmark Exadata?
Hi,
We have very heavy batch processing on our system. Would that change your opinion about whether Exadata is a good choice on which to implement our EBS?
Hi John,
That is an excellent question.
As we know, there is no such thing as a pure OLTP system. These system generally have batch work and reporting–as is the case with EBS. This aspect of the topic deserves attention. I’m aware that Oracle sales are calling out the non-OLTP aspects of ERP systems in their Exadata sales motions. It’s probably good for folks to hear both sides of that story.
I actually have the material to address your question prepared but will need to make it a follow-on blog post. To that end, I just renamed this “Part I.” I will post Part II, and (hopefully) address your question at that time. After reading Part II, please feel free to drill in for more clarification if needed.
Thanks for visiting my blog.
Kevin,
I am very interested to see your take on John McCann’s question above.
Thanks
Amir
Hi Amir,
Thanks for stopping by, as always. John’s is a very good question which deserves treatment in a dedicated post. I’ll handle it in Part II and will hustle as much as possible to get it done. I won’t treat it with any such brainless quasi-FUD such as, “Well, Oracle IT doesn’t use Exadata for their own ERP (Global Single Instance E-Biz)” So, please watch for the post.
Hi Kevin,
It is my understanding that Exadata is more suited for DW/BI types of activities which are read intensive. However, these data warehouses get loaded with tons of data in their fact tables on daily basis with write intensive operations. So, if Exadata is susceptible to IO saturation with writes then wouldn’t it have this issue during data loads?
Thanks
Amir
Hi Amir,
DW/BI I/O patterns are not patently “read intensive.” They are large operations in general and not latency-sensitive. That is the opposite of OLTP/ERP. But, on to your question.
Bulk data loading operations generate large streaming writes. A single 6Gb SAS drive can sustain about 1.4TB/hour with such an I/O profile.
Remember, terabytes per hour is megabytes per second. Even with normal redundancy ASM mirroring the write payload is just under 600MB/s at 1TB/h. Since the highest majority of Exadata sales are quarter-rack, I’ll put 1TB/h into perspective from that viewpoint. A quart-rack X2 Exadata Database Machine is sustains only 16MBPS/disk while ingesting bulk-loaded data at a rate of 1TB/h.
That’s noise.