There Is No Such Thing As “Pure OLTP”
There is no such thing as “pure OLTP.” How true! And that’s why you are supposed to buy Exadata for your Oracle OLTP/ERP deployment—at least that’s what I’ve heard.
Part I of this series on the topic of Oracle OLTP/ERP on Exadata Database Machine has brought quite a bit of feedback my way. Most of the feedback came from independent consultants who have built a practice around Exadata. I did, however, hear from an Oracle customer that has chosen to migrate their Oracle Database 10g ERP system from a cluster of old AMD 2300 “Barcelona” Opteron-based servers (attached to a circa 2007 technology SAN) to Exadata. This customer also cited the fact that there is no such thing as “pure OLTP” and since it is a fact I don’t refute it.
No Such Thing As “Pure OLTP” – What Does That Mean
Oracle-based OLTP/ERP systems generally have an amount of batch processing and reporting that takes place in support of the application. That’s true. Batch processing and reporting must surely require massive I/O bandwidth and, indeed, massive I/O would naturally benefit from Exadata offload processing. That is how the sales pitch goes.
I won’t argue for a moment that Exadata offers significant I/O bandwidth. There is 3.2 GB/s of realizable storage bandwidth (Infiniband) for data flow to/from each server in an Exadata configuration. That’s roughly equivalent to 2 active 16GFC HBA ports. It’s a lot. However, since I’ve just spelled out the conventional storage connectivity required to match the 3.2 GB/s, the question boils down to whether or not the Exadata storage offload processing feature (Smart Scan) adds value to the type of reporting and batch activity common in Oracle OLTP/ERP environments. I can’t prove a negative in this regard but I can say this:
Batch / reporting queries are not candidates for improvement by Smart Scan technology unless the plans are access method full (table or index fast full scan)
Most batch processing I’ve seen is quite compute-intensive as well as index-based (and not full scan). But, as I said, I cannot prove a negative. So, (pun intended) I’ll stop being negative. I’d like to defer to the positive proof Oracle offers on this topic. Oracle’s own designed benchmarks for proving platform suitability for Oracle E-Business Suite. The benchmark I have in mind is the Oracle E-Business Suite 12.1.3 Standard Extra-Large Payroll (Batch) Benchmark.
Oracle’s own description of the workload speaks volumes:
“Extra-Large”, “Batch”, Extremely Useful In Sizing And Capacity Planning
On April 10 2012, Oracle put out a press release highlighting the Sun Fire X4270 M3 payroll batch benchmark result. The press release made the following point about the result and the workload (emphasis added by me):
The Oracle E-Business Suite R12.1.3: Oracle’s Sun Fire X4270 M3 server posted the fastest results on the Payroll batch component of the Oracle E-Business Suite R12 X-large benchmark, completing the workload in less than 20 minutes. This result demonstrates that Oracle’s x86-based servers, running Oracle Linux, can deliver excellent throughput and are well suited for customers running batch applications in conjunction with Oracle Database 11g R2 (5).
I need to quickly point out two things. First, Oracle has an entire suite of their own benchmarks yet never has there been a published result for Exadata. I know, that is old news and seemingly uninteresting to Oracle customers considering Exadata. Second, I highlighted “fastest results” because it just turns out that this result is in fact the first posted result with this version of the benchmark :
I know, I’m being petty, right? Why would anyone insist on OLTP/ERP benchmarks when considering a platform (Exadata) optimized for DW/BI workloads? I know, I’m sorry, petty again.
So What Is The Point?
If a single Sun Fire X4270 M3 can achieve excellent results with an Oracle-defined E-Business Suite batch benchmark attached to non-Exadata storage, don’t we have proof that Exadata isn’t required to allay the fears of batch processing on x86 without Exadata? If Exadata added significant value (the sort that helps one absorb the sticker shock) to batch processing, wouldn’t there be published results?
Has Oracle simply not had enough time to publish Exadata benchmark results? Not even enough time given the fact that the benchmarks I speak of are their own benchmark specifications? I can answer those questions—but I won’t. Instead, I’ll focus on some of the particulars of the 4270 M3 result that would actually make it a very difficult workload for even a half-rack Exadata Database Machine X2-2!
The following table comes from Oracle’s full report on the batch benchmark result :
This table shows us a difficult profile–a batch processing profile. A batch profile that warrants the term “Extra-Large” in the name of the benchmark. Please notice that the peak write IOPS is 14,772. A half-rack Exadata Database Machine (X2) has the (datasheet) capacity for 12,500 random mirrored writes per second (WIOPS) thus 14,772 is more WIOPS than a half-rack Exadata can sustain. But what about all those extra processors an Exadata half-rack would offer over this server? Indeed, this was a 2s16c32t Xeon E5-2600 (Sandy Bridge) single server result. A half-rack Exadata (X2-2) has 48 Xeon 5600 cores. Surely the Sandy Bridge 2S server was totally out of gas, right? No. The full report for the benchmark includes processor utilization:
Summary
There is no such thing as “pure OLTP.” Oracle has proven that fact with the Payroll Batch benchmark. Oracle has further proven that a single 2s16c32t E5-2600 server is capable of achieving a world record result on their own benchmark (“Extra Large”) and that particular achievement was possible without Exadata. In fact, it was possible without even saturating the single server E5-2600 CPUs–but, hey, at least the WIOPS demand was higher than a half-rack Exadata Database Machine X2 can sustain!
You need Exadata to handle the batch requirements for modern E-Business Suite?
You spend a lot on Oracle Database, Applications and support. Spend wisely on the platform.
Kevin Closson's Blog: Platforms, Databases and Storage 
“A half-rack Exadata Database Machine (X2) has the (datasheet) capacity for 12,500 random mirrored writes per second”
You are generously quoting the value for a half rack with high performance disks using ASM normal redundancy. But an Exadata system built with normal redundancy does not allow for zero-downtime patching (unless you are willing be without resilience during the numerous patching cycles), so for anyone with HA requirements it would need to be ASM high redundancy, i.e. triple mirroring. Now the capacity is only 8,333 WIOPS!
And if the high capacity disks were used instead it would be around a further 50% reduction… taking it below 5,000 WIOPS for a half rack.
I don’t get it Kevin, how does this make it the “World’s Fastest Machine for OLTP” ? My two-socket Supermicro can achieve better write performance than that – for considerably less license cost!
@flashdba : Oracle would do well to stop exaggerating to cover their shortcomings in those areas they are not good at and improve what they are good at. This blog series has constant high-margin RDBMS license monies to Oracle. It is a series about Oracle OLTP (Oracle’s money) on different platforms. Maybe some day Oracle will miss partaking a partner ecosystem (because they’ve alienated the highest-majority of the ecosystem). In the meantime what we see is an egosystem and it’s all I can do to help people see the truth and be informed. If people make decisions based on fact, rather than faith, then fine.
Hi Kevin,
Excellent post! I don’t know much about Exadata’s Smart Scan technology but the following quote got my attention:
“Batch / reporting queries are not candidates for improvement by Smart Scan technology unless the plans are access method full (table or index fast full scan)”
So, it seems that Exadata Server’s Smart Scan technology primarily helps with full scans, be it FTS or FFIS and not much with random scans.
Generally speaking, for packaged applications (Oracle’s EBS, SAP, etc.), the code delivered by the vendors as well as the customizations added by the customers are optimized and tuned for response time, which largely means index scans. But if Exadata can not help with random index scans then that alone is a reason to rethink spending money on this very expensive piece of technology.
I am not sure if Oracle realized it but the R12 benchmark WP also implies that you don’t need to spend a fortune to achieve high performance.
Thanks
Amir
“Batch / reporting queries are not candidates for improvement by Smart Scan technology unless the plans are access method full (table or index fast full scan)”
..I want to point out that I was quoting myself (tongue in cheek) in that statment. No matter, it’s true. Index range scans do not involve Exadata offload processing technology (Smart Scan). I have a hunch that a lot of Exadata customers buy the World’s First OLTP Machine with blind faith in the notion that Smart Scan (a DW/BI feature) will help them out. Again, that is a hunch. Maybe someone closer to the field end of things has a better feel for that. In the end, my motive in this series is to save folks from deploying Oracle Database on an improper configuration for OLTP. Basically, “treat for RAC right” by getting appropriate hardware for the use case. The argument is so absurd. There is such a thing as an improper configuration. Did anyone run OLTP on Pyramid MPP, nCUBE or IBM SP2 MPP? Those all ran Oracle so if it runs Oracle it must be correct for all use cases, right?
Hello Kevin,
You mentioned “Most of the feedback came from independent consultants who have built a practice around Exadata” . At least I cannot see that feedback in the thread . Do you mind sharing what the feedback is ? Thanks
Regards,
Alex
@Alex : Actually I can’t because they are my friends. I have friends who disagree with me on matters and I think that is healthy. If they wanted their arguments public they’d certainly hop on the blog and post a comment–or post their own blog. For example, Tim Hall who is a co-member of the Oaktable Network and, in my reckoning, a friend posted a blog regarding my Exadata Critical Thinking video presentation (https://kevinclosson.wordpress.com/2012/04/16/critical-analysis-meets-exadata/) and you can see his counterpoints here:
http://www.oracle-base.com/blog/2012/04/17/critical-analysis-of-critical-analysis-meets-exadata/
I suppose I can provide a synopsis of their arguments but that would be best for another installment. I’ll see about doing that in Part III. In the meantime they can certainly chime in here.
Kevin, excellent blog as usual and always look forward to the next one. This is one of the few places I can come to where I can read facts rather than marketing hype. Additionally, the book, ‘Expert Oracle Exadata’ that you contributed to, is a very good source of reference material.
I thought I would become visible rather than being one of the suspected, ‘silent majority’ 🙂
When I was first introduced to Exadata, the marketing blew me away, as it probably does most people, but then I started peeling back the layers and with the help of your blogs and a few other guys, it became clear that all wasn’t what it seemed.
For me, Exadata in terms of hardware is a bunch of very capable, independent, Oracle/Sun x86 commodity servers, some storage cells with some offloading intelligence, which are only invoked in limited circumstances and a high bandwidth network, Infiniband, connecting it together. In terms of software, it is standard Oracle 11gR2 which is an excellent database in its own right.
In terms of the Oracle use cases:
– Data Warehouse – the offloading is where Exadata is supposed to score but there are only limited situations where this is likely to occur so I suspect more DW focused appliances are likely to be better options such as Netezza and Greenplum
– OLTP – the only feature to assist OLTP is the Smart Flash Cache but there are similar features in modern storage arrays, so it isn’t unique
– Consolidation – I believe that the more databases that go onto the ‘machine’ then the harder it is to do resource and patch management. Resource management consists of features such as DBRM, IORM and Instance Caging and they just seem to confirm that we are dealing with a bunch of independent database servers (DBRM and Instance Caging work within servers) which don’t automatically manage load across the ‘database grid’ and IORM which manages I/O load within storage cells and not across the storage grid
Its seems to me that it would be more cost effective, from a lot of angles – including licensing, resource management, patch management – to utilise the highly performant x86 servers in a much smaller and therefore more manageable configuration, accessing storage from one of the major players such as NetApp, EMC, Hitachi.