10.07.2015 Views

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 10 EXADATA WAIT EVENTS■ Kevin says: A SmartScan on an index is possible without parallelism, but the rules are strict. If you alter thesession to disable parallel query and set _serial_direct_read=TRUE in the session, and then run your test, youshould get a smart, serial, index fast full scan (IFFS). If not, then you’re looking at a bug. In short, to get a serialIFFS the object needs to be more than five times the size of the SGA.Gluing range scans to smart index scans can be done, but it’s very messy. There isn’t likely much to be gainedthere in terms of completing a query.As a result of these issues, cell smart index scans are fairly rare compared to cell smart tablescans. It is, of course, possible to encourage the feature with hints (such as parallel_index) or bydecorating specific indexes with a parallel degree setting of greater than 1. Here’s an excerpt from a10046 trace file showing the event:PARSING IN CURSOR #1 len=112 dep=1 uid=0 oct=3 lid=0 hv=123 ad='197' sqlid='dnmumhk9599p7'select /*+ parallel_index (a skew2_all 8) index_ffs (a skew2_all) */ sum(pk_col) fromkso.skew2 a where col1 > 1END OF STMTPARSE #1:c=0,e=89,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,plh=2801817111,tim=1285372448705192WAIT #1: nam='PX Deq: Execution Msg' ela= 3124 sleeptime/senderid=268 passes=1 p3=0 obj#=-1WAIT #1: nam='cell smart index scan' ela= 133 cellhash#=379339958 p2=0 p3=0 obj#=66856WAIT #1: nam='cell smart index scan' ela= 522 cellhash#=2133459483 p2=0 p3=0 obj#=66856WAIT #1: nam='cell smart index scan' ela= 277 cellhash#=3176594409 p2=0 p3=0 obj#=66856WAIT #1: nam='cell smart index scan' ela= 1910 cellhash#=379339958 p2=0 p3=0 obj#=66856WAIT #1: nam='cell smart index scan' ela= 330 cellhash#=2133459483 p2=0 p3=0 obj#=66856WAIT #1: nam='cell smart index scan' ela= 348 cellhash#=3176594409 p2=0 p3=0 obj#=66856WAIT #1: nam='cell smart index scan' ela= 45162 cellhash#=3176594409 p2=0 p3=0 obj#=66856WAIT #1: nam='cell smart index scan' ela= 13 cellhash#=3176594409 p2=0 p3=0 obj#=66856WAIT #1: nam='cell smart index scan' ela= 207 cellhash#=379339958 p2=0 p3=0 obj#=66856WAIT #1: nam='cell smart index scan' ela= 30 cellhash#=379339958 p2=0 p3=0 obj#=66856WAIT #1: nam='cell smart index scan' ela= 779 cellhash#=3176594409 p2=0 p3=0 obj#=66856WAIT #1: nam='cell smart index scan' ela= 30 cellhash#=2133459483 p2=0 p3=0 obj#=66856Note that this trace file was produced by one of the parallel slave processes and not the requestingprocess. The trace produced for the same statement when Offloading is disabled should look familiar.Here’s an excerpt:PARSING IN CURSOR #1 len=158 dep=1 uid=0 oct=3 lid=0 hv=338 ad='196' sqlid='g2966dwa2xfm8'select /*+ OPT_PARAM('cell_offload_processing' 'false') parallel_index (a skew2_all 8)index_ffs (a skew2_all) */ sum(pk_col) from kso.skew2 a where col1 > 1END OF STMTPARSE #1:c=0,e=94,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,plh=2801817111,tim=1285546990415744WAIT #1: nam='PX Deq: Execution Msg' ela= 2377 sleeptime/senderid=268566527 passes=1 p3=0WAIT #1: nam='latch: cache buffers chains' ela= 44 address=6636639304 number=150 tries=0WAIT #1: nam='kfk: async disk IO' ela= 12 count=1 intr=0 timeout=4294967295 obj#=66856WAIT #1: nam='direct path read' ela= 28957 file number=6 first dba=13 block cnt=124 obj#=66856WAIT #1: nam='kfk: async disk IO' ela= 32 count=1 intr=0 timeout=4294967295 obj#=66856WAIT #1: nam='kfk: async disk IO' ela= 24 count=1 intr=0 timeout=4294967295 obj#=66856327

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!