Oracle Exadata Storage Server: 485x Faster Than…Oracle Exadata Storage Server. Part II.

In my blog entry entitled Exadata Storage Server: 485x Faster than…Exadata Storage Server. Part I., I took issue with the ridiculous multiple orders of magnitude performance improvement claims routinely made by the DW Appliance vendors. These claims are usually touted as comparisons to “Oracle” (without any substantive accounting for what sort of Oracle configuration they are comparing to) and never seem to include any accounting for where the performance improvement comes from. After learning a bit about marketing from a breakfast cereal commercial, I decided to share with my readers how easy it is to do what these guys generally do-compare apples to bicycles. To make it more interesting I decided to show a 485-fold performance increase of Oracle Exadata versus Oracle Exadata. A long comment thread ensued and ultimately ended with a reader posting the following:

Block density perhaps?

You didn’t mention that the number of records per block
was a constant. So it would be possible that in the first scenario you created a table with a low amount of records per block, resulting in a large segment, needing a lot of io’s. (you could have used 1 row/block for example)

While in the second scenario you could have used a high number of blocks per record, resulting in a smaller segment, and thus needing a lower amount of io’s to fulfill the query.


Here’s the deal. I chose my words carefully and took a huge dose of Semantic-a-sol(tm). I set the stage as a follows:

  • I said, “There are no … partitioning or any sort of data elimination.” True, there were no forms of data elimination. I didn’t say anything about eliminating unused space.
  • I said the data in the table was the same; I never said it was the same table.
  • I said there was the same storage bandwidth and the same number of CPUs and that was true.

The 485x was a product of querying a table with PCTFREE 0 versus PCTFREE 99. When I queried the vacuous blocks I also did so with a normal scan instead of a Smart Scan. So it is true that storage bandwidth remained constant but I created an artificial bottleneck upwind by forcing the single database host (used in both cases) to ingest the full 1.6 TB which is how much round-brown spinning stuff needed to store the vacuous blocks (PCTFREE 99). That took 970 seconds.

With ~107 million rows, and a query that cited only the PURCHASE_AMT column, the amount of data actually needed by the SQL layer is a measly 86 MB. So, when I “magically” switched the card_trans synonym to point to the PCTFREE 0 table (which is only 8.4 GB) and scanned it with the full power of 14 Exadata Storage Servers, the data was off disk and the PURCHASE_AMT column plucked from the middle of each row and DMAed into the address space of the Parallel Query Processes on the database host in 1.96 seconds….485x speed up.

So, does anyone else hate it when these DW Appliance guys go around spewing ridiculous multiple orders of magnitude performance increases over who-knows-what without any accounting? It truly is an insult on your intelligence.

There is no reason to be mystified. If DW Appliance vendor XYZ is spouting off about a query processing speed-up of, say, X, just plug the values into the following magic decoder ring. Quote me on this, performance increase X is the product of:

  1. Executing on a platform with X-fold storage bandwidth, or
  2. Executing on a platform with X-fold processor bandwidth, or
  3. The query being measured manipulated 1/Xth the amount of data, or
  4. Some combination of items 1 through 3

Any reasonable vendor will gladly itemize for you where they get their magical performance gains. Just ask them, you might learn more about them than you thought.

Part II in these series can be found here.

21 Responses to “Oracle Exadata Storage Server: 485x Faster Than…Oracle Exadata Storage Server. Part II.”

  1. 1 kurtvm December 11, 2008 at 9:41 pm

    Did I win my own Exadata storage system now ? 😉

  2. 3 Dan Norris December 11, 2008 at 10:18 pm

    I usually prefer something like: “There’s a raffle where you’re guaranteed to win your own Exadata Cell, tickets are $14,000 per TB and you can purchase multiple tickets to get multiple TBs. Enter now!”

    Thanks for not only pointing out the ways that data and statistics can (and are) manipulated, but also for posting the solution to the puzzle you created!

  3. 4 kevinclosson December 11, 2008 at 10:35 pm


    Thanks for stopping by. It was my pleasure. Like I said, I’m willing to itemize where performance gains come from…even in synthetic cases such as this. Exadata is not magic. We don’t need smoke, or mirrors even!

  4. 5 Dave Menninger December 11, 2008 at 11:00 pm


    As one of the vendors making some of what you refer to as “ridiculous multiple orders of magnitude performance improvement claims” I thought I’d stop by to point you to a post that helps break down the orders of magnitude to its constituent parts at least with respect to column oriented databases v. row oriented databases.

    Hope you find that helpful.

    Dave Menninger

  5. 7 Ofir December 12, 2008 at 12:03 am

    Hi Kevin,
    another way you could have fabricated these results was playing with the CPU.
    let’s say your database machine had a single, slow CPU core (maybe it is a VM), and your SQL was running in parallel 16.
    If you run with smart scan off, the parallelism doesn’t help you, and the database host has to digest 8.4 GB of raw data, which will take a while. Once you turn on smart scan, you have many many fast cores to process the data (for example – 16 cells X 8 cores), which can deliver that improvement, and fit all claims (same number of rows scanned – same table, same full table scan).
    Another option is having a relevant materialized view ready and just playing with query_rewrite_enabled… although 2 seconds is way too slow for that 🙂
    thanks for brain exercise….

    • 8 kevinclosson December 12, 2008 at 12:18 am


      What makes you think parallelism is no hlep when smart scan is not kicking in?

      There is an infinite number of ways to come up with a bologna “performance gain” scenario. That is exactly the
      point of the blog entry…

  6. 9 Jeff Darcy December 12, 2008 at 12:45 am

    So, according to your formula, there’s no possibility that *any* of a vendor’s gains vs. Oracle could have come from implementing something better. You’ve done a good job showing how vacuous competitors’ claims can be, but it doesn’t really help to make similar counterclaims of your own.

  7. 10 a December 12, 2008 at 1:24 am


    So if Oracle formats a block, and most of it is not your data, who’s data is it?

    Perhaps your semantic problem is defining the data as what would be in an export or flat-file extract, rather than what is in the table, however Oracle decides to store it.

    In the context of storage, you don’t allocate based on how big the export file is, but on how big the data is when it is stored. Is the data the same when Oracle stores it different ways? Obviously not, think characterset for the most obvious example. But even pure sparseness would make a difference with, say, unix diff. So “I said the data in the table was the same;” is the smoke.

    But a great game, nevertheless, and always great to see technical marketing overcome smoke and mirrors. Bravo!

  8. 11 kevinclosson December 12, 2008 at 1:47 am


    Actually, in Part I I never said the data in the table was the same so it looks like I incorrectly paraphrased myself from Part I. Nonetheless, the exercise was what it was. The point is, when anyone uses figures like 100x push for an itemization.

  9. 12 kevinclosson December 12, 2008 at 1:53 am

    Jeff wrote:

    “So, according to your formula, there’s no possibility that *any* of a vendor’s gains vs. Oracle could have come from implementing something better.”

    Jeff, I’m not saying that at all. I think the release of Exadata proves there is leap-frogging in this space.

    Jeff continued with:

    “You’ve done a good job showing how vacuous competitors’ claims can be, but it doesn’t really help to make similar counterclaims of your own.”

    I stand by what I said. If I spew an multiple order of magnitude performance claim, I’ll account for where it came from. That is the point. Sound like you have found fault with counterclaims of mine? Do tell.

  10. 13 Ofir December 12, 2008 at 10:45 am

    Hi Kevin,
    sorry for not being clear…
    when smart scan is off, the exadata cells will try send (very very fast, granted) the full blocks to the database server (in parallel 16 etc).
    HOWEVER, since the database server in my example has a single core, it can typically digest about 200MB/s of db blocks – that’s the common rule of thumb for processing rows of a full scan, right? Since I said it would be a slow, virtualized core, that will probably be 100MB/s or less, so the scan will take about 100 sec. (just take a slow, old pc as a db machine).
    So, this setup creates an artificial bottleneck around the db CPU, and adding parallelism (parallel 16) doesn’t help if the db server is 100% cpu, as it can’t keep up with the storage… Now, without adding CPUs to the database machine, offloading the CPU processing to exadata will give 99% run time improvement…

  11. 14 Donald K. Burleson December 12, 2008 at 3:40 pm

    Interesting note on block density and benchmarks!

    I know nothing much about Exadata, but your block density revelation relates to the number of rows fetched in a single I/O.

    Without starting a war, we say that a larger blocksize also increased block density, i.e. more space equals more rows per block?

    And how about 11g compression? That creates greater block density, but I imagine that the higher overhead would negate the benefit?

    • 15 kevinclosson December 12, 2008 at 4:13 pm


      There really is no there, there. Yes, there is header and trailer data in blocks that remain constant regardless of block size, but honestly, the fraction of difference between PCTFREE 0 32K versus PCTFREE 0 16K blocks is not worthy of discussion.

      Yes, compressed blocks can hold more rows per block than uncompressed. That’s not surprising. The compression ratio depends on the data being compressed though. It is unfair to say that the additional processor overhead associated with manipulating compressed data in-place cancels out the benefit of reduced physical I/O. There are simply too many variables involved to make such assumptions.

      I haven’t been discussing compression in my Exadata-related posts because in my opinion compression is used by the new guys on the block as snake oil. For example, stating scan rates that are greater than the I/O plumbing physically supports because they are scanning compressed data. Physical I/O is physical I/O regardless of the form of what’s being accessed on disk. If someone touts N GB/s scan throughput, that needs to be how much round brown spinning stuff that is touched…not the product of the compression ratio…

  12. 16 Donald K. Burleson December 15, 2008 at 2:03 am

    Hi Kevin,

    Thanks for the reply.

    >> the fraction of difference between PCTFREE 0 32K versus PCTFREE 0 16K blocks is not worthy of discussion.

    Fair enough, but when expressed as row/block, a 32k block has much mugher “block density” than 2k. I know that’s a nit, but it might confuse someone . . .

    >> It is unfair to say that the additional processor overhead associated with manipulating compressed data in-place cancels out the benefit of reduced physical I/O.

    I was only postulatuing that as a push-pull cost-benefit of compression! Check out this benchmarl on TDE that someone sent me:

  13. 17 somsikdar December 19, 2008 at 2:44 am

    Hi Kevin:

    I thoroughly enjoy your blog and have been tracking the discussion about the Exadata with interest.

    How will the Exadata compare against an Oracle RAC node with internal disks.

    Configuration A: 4 node Oracle RAC + 4 Exadata
    Configuration B: 8 node Oracle RAC with the equal amount of storage as disks inside the Oracle nodes themselves. RAC interconnect is IB for both.

    I understand that Oracle pricing is not identical – but are these configurations comparable (for example the kind of DWH setup Larry Ellison talked about in the Openworld keynote)?

    Thanks – and I hope to hear you speak (perhaps) in a IOUG in future.



  14. 18 Marco Gralike January 11, 2009 at 12:37 am

    Ah, Kurt is the Man. Way to go Kurt 😉

    It gets time though to test that cool Exadata stuff on a serious unstructured / semi-structured XMLDB (USA?) customer, to checkout how much (positive) damage it can do on functionality like path_tables


  15. 19 David Sansom January 17, 2009 at 12:36 pm

    Kevin, I’d love to hear your thoughts on these 4 points:
    1. Netezza’s “Data Liberation movement”
    2. The latest Gartner magic quadrant for Data Warehouse DBMS
    3. Are the Exadata 1TB drives SATA or midline SAS?
    4. Would 1 Oracle Database machine with 1TB 7200rpm drives still be able to scan >10GB/sec of data if there were say 50 concurrent users table scanning 50 different tables? Or would the concurrency mean the I/O pattern started to look more random and seek time start to become an issue?
    (By the way, we currently struggle to get >3GB/sec of Disk I/O from a large expensive SAN despite 28 Fibre channel connections and 660 x 15k spindles being dedicated to the Data Warehouse.)

  1. 1 Database Customer Benchmarketing Reports | Structured Data Trackback on December 12, 2008 at 5:47 pm
  2. 2 Oracle Exadata Storage Server and Oracle Database Machine Related Posts « Everything Exadata Trackback on February 23, 2009 at 9:02 pm

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


I work for Amazon Web Services but all of the words on this blog are purely my own. Not a single word on this blog is to be mistaken as originating from any Amazon spokesperson. You are reading my words this webpage and, while I work at Amazon, all of the words on this webpage reflect my own opinions and findings. To put it another way, "I work at Amazon, but this is my own opinion." To conclude, this is not an official Amazon information outlet. There are no words on this blog that should be mistaken as official Amazon messaging. Every single character of text on this blog originates in my head and I am not an Amazon spokesperson.

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 2,894 other followers

Oracle ACE Program Status

Click It

website metrics

Fond Memories


All content is © Kevin Closson and "Kevin Closson's Blog: Platforms, Databases, and Storage", 2006-2015. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Kevin Closson and Kevin Closson's Blog: Platforms, Databases, and Storage with appropriate and specific direction to the original content.

%d bloggers like this: