Are you getting the most out of your Exadata performance? Part 1

In almost all of the Exadata migration projects I’ve been part of, the client sees immediate speedup & performance increase when testing their workload on Exadata (of course, we’ve made sure that we do plan & execute the tasks right). However, my performance geek’s nature usually doesn’t allow to stop there and leave the client with just 2x or 3x performance increase. For data warehousing and reporting workloads, Exadata can do much better than just 2-3x performance increase! 

This is why I will write this article series about Getting the Most out of your Exadata Performance. I will write a bunch of random articles, based on my experience and lessons learned – and some day I may consolidate it all into a more formal paper.

So, here’s the first article (PDF format).

Enjoy! :-)

(Leave your comments & feedback here …)

This entry was posted in Oracle and tagged , , . Bookmark the permalink.

8 Responses to Are you getting the most out of your Exadata performance? Part 1

  1. Tanel Poder says:

    Just uploaded a new version of this doc, with just some typos fixed

  2. boypoo says:

    good job. waiting for your part-2. maybe still focus on smart scan? :)

  3. bitizerg says:

    i think io_cell_offload_returned_bytes should be used instead of io_interconnect_bytes when querying v$sql.
    1 SELECT
    2 child_number
    3 , ROUND(physical_read_bytes/1048576) phyrd_mb
    4 , ROUND(io_cell_offload_eligible_bytes/1048576) elig_mb
    5 , ROUND(io_interconnect_bytes/1048576) ret_mb
    6 , ROUND(io_cell_offload_returned_bytes/1048576) ret2_mb
    7 , (1-(io_interconnect_bytes/NULLIF(physical_read_bytes,0)))*100 “SAVING%”
    8 , (1-(io_cell_offload_returned_bytes/NULLIF(physical_read_bytes,0)))*100 “SAVING% 2″
    9 FROM
    10 v$sql
    11 WHERE
    12* sql_id = ’17m7a38d3n75y’
    02:30:26 SQL> /

    CHILD_NUMBER PHYRD_MB ELIG_MB RET_MB RET2_MB SAVING% SAVING% 2
    ———— ———- ———- ———- ———- ———- ———-
    0 4869 1725 7112 2932 -46.051403 39.7760205

  4. Tanel Poder says:

    @bitizerg

    Nope, it depends on what you want to see – the total IO interconnect traffic, which is the one that matters or only a subset of the traffic, ignoring the rest (the offload returned bytes metric). Thankfully the v$sql_plan_monitor allows you to monitor the io_interconnect_bytes at a row-source level, so you can break this traffic info down by row-source instead of whole SQL. My part 2 in this series is going to be about this ..

  5. Christoph says:

    Tanel,
    some questions:
    1. What does the io_cell_offload_returned_bytes metric tell us?
    2. I saw some cases where io_cell_offload_eligible_bytes = 0 and io_interconnect_bytes > 0. What happened there?
    3. When will you have part 2 of this article?

    thanks,
    Christoph

  6. George says:

    Hi Tanel

    Have a second chapter been released, only see #1 atm.

    G

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>