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.
Filed under: oracle
![]()
Recent comments
17 weeks 1 day ago
26 weeks 6 days ago
28 weeks 4 days ago
31 weeks 5 days ago
34 weeks 14 hours ago
43 weeks 4 days ago
45 weeks 1 day ago
46 weeks 1 day ago
46 weeks 2 days ago
49 weeks 8 hours ago