Expert Oracle Exadata - Parent Directory

CHAPTER 16 UNLEARNING SOME THINGS WE THOUGHT WE KNEWCOUNT(*)----------9Elapsed: 00:00:13.29SYS@SANDBOX1> select name, value from v$mystat s, v$statname n2 where n.statistic# = s.statistic#3 and name like '%storage%';NAMEVALUE--------------------------------------------------------------------------------cell physical IO bytes saved by storage index 0Elapsed: 00:00:00.01SYS@SANDBOX1> select count(*) from kso.skew3 where col2='KSO';COUNT(*)----------9Elapsed: 00:00:00.10SYS@SANDBOX1> select name, value from v$mystat s, v$statname n2 where n.statistic# = s.statistic#3 and name like '%storage%';NAMEVALUE--------------------------------------------------------------------------------cell physical IO bytes saved by storage index 15998312448Elapsed: 00:00:00.01Storage indexes are disabled by functions, just like regular indexes. This is not too surprising, butagain, when we’re already doing a full scan, we’ve trained ourselves to not worry about functions in theWHERE clause that could disable indexes. Exadata is different.Chained RowsThis is a very broad generalization, but basically any Oracle processing that requires reading an extrablock to complete a row causes the Exadata storage software to revert to block shipping, or pass-throughmode. We have discussed this in several places in the previous chapters. A simple example is a chainedrow, but there are other situations that can cause Oracle to revert to pass-through mode. What thismeans in practice is that some operations that cause slight delays on non-Exadata platforms canseverely impact performance on Exadata. The primary diagnostic symptom of this issue is the presenceof many single-block-read wait events in combination with cell Smart Scan wait events. In suchsituations, you may find that you are better off not using offloading for the statements in question. Hereis an example showing where Oracle spends its time when selecting from a table with chained rows:518