Seven Fundamentals Everyone Should Know About Exadata Before Attending Exadata-Related Presentations.

I speak to a lot of customers, prospects and co-workers about Exadata.  Even though Exadata has been in production for two years I still do not presume everyone has a grasp of some of the more important fundamentals of Exadata. I’ll routinely get asked about how very large SGA buffering can enhance Exadata Smart Scan or how Storage Indexes might improve OLTP workloads and other such non sequiturs.

There are a lot of sessions about Exadata being offered at Oracle OpenWorld 2010 and for good reason.  Exadata is exciting technology! It dawns on me, however, that a few words explaining some of the more fundamental aspects of Exadata might help folks absorb more of what they are hearing in the sessions they attend next week.

I consider the following seven terms and definitions utterly important for folks to know before sitting through an Exadata presentation. In fact, there may even be some sessions offered by presenters who could also benefit from the following 242 words?

  • Cell Offload Processing.
    • Work performed by the Storage Servers that would otherwise have to be executed in the database grid. Includes functionality like Smart Scan, datafile initialization, RMAN offload, Hybrid Columnar Compression (HCC) decompression.
  • Smart Scan.
    • Most relevant Cell Offload Processing for improving Data Warehouse / Business Intelligence query performance. Smart Scan is the agent for offloading filtration, projection, Storage Index exploitation and HCC decompression.
  • Full Scan or Index Fast Full Scan.
    • The required access method chosen by the query optimizer in order to trigger a Smart Scan.
  • Direct Path Reads.
    • Required buffering model for a Smart Scan. The flow of data from a Smart Scan cannot be buffered in the SGA buffer pool. Direct path reads can be performed for both serial and parallel queries. Direct path reads are buffered in process PGA (heap).
  • Result Set.
    • Data returned by the SQL processing layer. The SQL processing layer is in the Oracle Database. The data flowing from a Smart Scan is not a result set.
  • Exadata Smart Flash Cache.
    • Flash Cache in each of the Storage Servers. Not to be confused with Database Flash Cache which is Flash in the database grid and not compatible with Exadata. Smart Scan aggressively scans both HDD and Flash media concurrently. When data is present in the flash cache scan rates of 50 GB/s on Exadata Version 2 hardware are the norm for full rack configurations.
  • Storage Index.
    • Dynamic, in-memory indexes. The role of Storage Index technology is not to aid in locating data faster but instead to eliminate I/O. With Storage Indexes the Exadata Storage Server software can determine whether or not a given storage region contains rows relevant to the query and decide to not read the storage region. Storage Indexes are only examined during a Smart Scan.

I hope you’ll find this helpful.

13 Responses to “Seven Fundamentals Everyone Should Know About Exadata Before Attending Exadata-Related Presentations.”


  1. 1 Syed Jaffar Hussain September 18, 2010 at 7:26 pm

    Indeed these are very valuable points, at least to me as I am new to exadata.

  2. 2 jametong September 19, 2010 at 2:13 am

    Can you show your blog post in the rss as full text article? or can you just post a vote as Jonathan Lewis do .

    http://jonathanlewis.wordpress.com/2010/08/30/subscribers/

  3. 5 Daniel Buzatu November 10, 2010 at 4:43 pm

    Kevin, thanks for the above. Could you clarify one point, please? All 7 concepts seem to revolve around smart scan, and smart scan is defined as “the most relevant offloading process for improving *DW/BI* query performance”.

    Is there a good reason you specify “DW/BI query” or can “IO-intensive query” be substituted. Based on the descriptions of each technology, I would assume yes, but I’m just wondering if I’m missing something, especially in light of the history of Exadata as particularly relevant for DW-type processing.

    Thanks!

    • 6 kevinclosson November 10, 2010 at 5:33 pm

      Hi Daniel,

      Quite simple. At this time Offload Processing is not optimized for transactional workloads. Transactional workloads generally get rows by ROWID or do very short small table scans neither of which get a boost from offload processing.

      I do suppose I/O-intensive would be an acceptable substitution, so long as the access method is FULL and the buffering is direct (so, not scattered reads). Am I still clear as mud? :-(

      • 7 Daniel Buzatu November 11, 2010 at 4:49 pm

        Hi, Kevin, thanks – that makes sense. I’m not sure what magic I was hoping for, but I guess something like the optimizer, when realizing that lots of reads are gonna happen, starts a smart scan. I guess there is some hope with the FFS…

        • 8 kevinclosson November 11, 2010 at 5:30 pm

          Hi Daniel,

          Remember that the product of a smart scan cannot go into the SGA. People (everywhere!) routinely forget that fundamental concept. If you consider the SGA critical to your OLTP/ERP then put all that in perspective :-)

  4. 9 Deepak Gupta October 28, 2011 at 7:28 pm

    I would like to subscribe your blog.

  5. 10 oraclebhola July 1, 2013 at 4:52 am

    Hi Kevin,

    You have mentioned in above context:-
    “Smart Scan aggressively scans both HDD and Flash media concurrently”… but I think SMART SCAN is anti FLASH.:)

    Smart Scans ignores FLASH and scan only disk. But if object is created/altered with CELL_FLASH_CACHE=KEEP, than only Smart scans will use flash and disk.

    Please correct me if I am wrong here. I know I am raising question to someone who is master in this. And we all are still getting knowledge by reading your blog and your “comments” on other’s blog.:)

    I think there must be some type of “RSS” which I can use for your blog and for the comments you are raising in other’s blog.

    Regards,
    Sunil Bhola

    • 11 kevinclosson July 1, 2013 at 9:53 am

      Yes, one must KEEP the object to get max theoretical scan rates. If the scanned object doesn’t fit in the aggregate of flash cache then don’t KEEP it. When scanning only HDD (High performance drives) full-rack scan throughput drops from 100GB/s to 25GB/s as per the datasheet.


  1. 1 Exadata « Oracle Scratchpad Trackback on September 18, 2010 at 7:36 am
  2. 2 OBIEE performance – get your database sweating « RNM Trackback on May 19, 2011 at 3:02 pm

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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




EMC Employee Disclaimer

The opinions and interests expressed on EMC employee blogs are the employees' own and do not necessarily represent EMC's positions, strategies or views. EMC makes no representation or warranties about employee blogs or the accuracy or reliability of such blogs. When you access employee blogs, even though they may contain the EMC logo and content regarding EMC products and services, employee blogs are independent of EMC and EMC does not control their content or operation. In addition, a link to a blog does not mean that EMC endorses that blog or has responsibility for its content or use.

This disclaimer was put into place on March 23, 2011.

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

Join 2,146 other followers

Oracle ACE Program Status

Click It

website metrics

Fond Memories

Copyright

All content is © Kevin Closson and "Kevin Closson's Blog: Platforms, Databases, and Storage", 2006-2013. 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.

Follow

Get every new post delivered to your Inbox.

Join 2,146 other followers

%d bloggers like this: