Expert Oracle Exadata - Parent Directory

CHAPTER 11 UNDERSTANDING EXADATA PERFORMANCE METRICSPredicate Information (identified by operation id):---------------------------------------------------2 - filter("OWNER" LIKE '%S%')Unlike in plans listed earlier, there is no STORAGE option listed in the execution plan row source (line 2),and there is no storage() predicate, indicating an opportunity to push a filter predicate to the storagecells. This plan is not capable of using any Smart Scan functionality; it will do good old block I/O.Looking at additional Exadata and cell metrics isn’t really necessary, as the execution plan itself showsthat it doesn’t even use a Smart Scan-compatible row source codepath.Understanding Exadata Smart Scan Metricsand Performance CountersOnce you have made an Oracle execution plan use the storage-aware row sources, you still cannot besure about whether a Smart Scan really is attempted and works as you expect.One way to determine what’s happening is just looking at the wait events your session is waiting for:• CPU usage only: This seems to mean that a buffered data access is used (not directpath), as you won’t see I/O wait events if you read through buffer cache and all thedata happens to be cached.• cell multiblock physical read : Apparently multiblock reads are used (looks like afull segment scan), but multiblock read waits can be reported also for LOB andSecureFile read operations, where in case of LOBs, the LOB chunk size is biggerthan the block size. Otherwise, single-block reads would be reported for LOBaccess.• cell single block physical read:– Apparently single block reads are used. If theseare the only I/O wait events you see (and not together with multiblock reads) thenit appears you are not using a full segment scan at all. Of course, sometimes singleblock reads show up due to other operations in the execution plan (like someindex range scan) or due to chained rows in data blocks.If you see regular “cell multiblock physical read” wait events incremented in your session, thendirect path reads were not used. This may happen mainly for serially executed operations, as if you areusing parallel_degree_policy = MANUAL or LIMITED, Parallel Execution slaves will always do direct pathread scans, which will then be offloaded and executed as Smart Scans. Nevertheless, when you are usingthe new automatic parallel degree policy (parallel_degree_policy = AUTO), Oracle may decide to usereads through buffer cache even for parallel operations.In addition to these issues, there are more reasons and special cases where Smart Scans just silentlyaren’t used or fall back to regular block I/O mode— potentially making your queries and workloadslower than you’d expect. Luckily Oracle is very well instrumented and we can measure what is reallyhappening in the database and also the storage cells.Exadata Dynamic Performance CountersWhile the Oracle wait interface’s wait events provide us crucial information about where the databaseresponse time is spent, the Exadata dynamic performance counters do take us one step further andexplain what kind of operations or tasks the Oracle kernel is performing— and how many of them. Wait350