Expert Oracle Exadata - Parent Directory

CHAPTER 2 OFFLOADING / SMART SCAN2 - storage("COL1">0)filter("COL1">0)Notice that the optimizer chose a TABLE ACCESS STORAGE FULL operation and that the predicatesection shows a storage() predicate associated with step 2 of the plan. Both of these characteristicsindicate that a Smart Scan was possible, but neither provides a definitive verification. In fact, thestatement in this listing was not executed with a Smart Scan.■ Note: An interesting feature of the plan output is worth mentioning. Notice that in the predicate section there is astorage() clause and there is a matching filter() clause that both perform the same comparison. Wescratched our heads about this for a while, wondering whether these clauses represented separate parts of theplan or whether it was just a quirk of the XPLAN output. There is actually a very simple explanation for thisbehavior. The cells have to fall back to regular block I/O in a number of cases. When a Smart Scan hits a chainedrow, for example, that block must be returned in its entirety to the DB layer. Since there is no such thing as aguaranteed “pure” Smart Scan, a filter operation must be included in the plan in addition to the filtering providedby the storage cells (represented by the storage() clause). So the two predicates actually represent two distinctoperations. Keep in mind, though, that they will not overlap. The filter() operation will be done on rows returnedvia the block shipping mode, while the storage() operation will be performed on the storage cells for the rowsthat can be returned directly to the PGA via the normal Smart Scan mechanism.The fact that execution plans do not show whether a Smart Scan was performed is a bit frustrating.However, there are several techniques that we can use to work around this issue. We’ll cover a fewoptions in the next several sections.10046 TraceOne of the most straightforward ways to determine whether a Smart Scan was used is to enable a 10046trace on the statement in question. Unfortunately, this is a bit cumbersome and doesn’t allow you to doany investigation into what has happened with past executions. Nevertheless, tracing is a fairly foolproofway to verify whether a Smart Scan was used or not. If Smart Scan was used, there will be CELL SMARTTABLE SCAN or CELL SMART INDEX SCAN events in the trace file. Here is an excerpt from the trace filecollected for the previous statement:PARSING IN CURSOR #47387827351064 len=49 dep=0 uid=0 oct=3 lid=0 tim=1297219338278533hv=3279003447 ad='2c8743808' sqlid='05cq2hb1r37tr'select avg(pk_col) from kso.skew a where col1 > 0END OF STMTPARSE #47387827351064:c=57991,e=78256,p=25,cr=199,cu=0,mis=1,r=0,dep=0,og=1,plh=568322376,tim=12EXEC #47387827351064:c=0,e=14,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=568322376,tim=1297WAIT #47387827351064: nam='SQL*Net message to client' ela= 2 . . .WAIT #47387827351064: nam='cell single block physical read' ela= 487 . . .WAIT #47387827351064: nam='cell multiblock physical read' ela= 25262 . . .51