Expert Oracle Exadata - Parent Directory

CHAPTER 2 OFFLOADING / SMART SCANsum 13,814.01 row selected.So adding the non-Exadata storage also disabled HCC. We had to decompress the table simply toaccess it. Once this was done we executed a parallel query on the table and, as you can see, the querywas not Offloaded. So all that was to show that you need Exadata storage to do Smart Scans.Smart Scan DisablersThere are situations where Smart Scans are effectively disabled. The simple case is where they have notbeen enabled in the code yet, and so Smart Scans don’t happen at all. There are other cases whereOracle starts down the Smart Scan path but the storage software either decides, or is forced, to revert toblock shipping mode. Generally this decision is made on a block-by-block basis.Simply UnavailableDuring the discussion of Smart Scan optimizations we have covered the prerequisites that must be metto enable Smart Scans. However, even when those conditions are met, there are circumstances thatprevent Smart Scans. Here are a few other situations that are not related to specific optimizations, butwhere Smart Scans simply cannot be used (at least as of cellsrv version 11.2.2.2.0).• Smart Scans cannot be used on clustered tables.• Smart Scans cannot be used on Index Organized Tables (IOTs).• Smart Scans cannot be used on tables with ROWDEPENDENCIES enabled.Reverting to Block ShippingThere are situations where Smart Scans are used, but for various reasons cellsrv reverts to blockshipping mode. This is a very complex topic, and we struggled with whether to include it in anintroductory chapter on offloading. But it is a fundamental concept and so in the end we decided todiscuss it here.We’ve described how Smart Scans avoid transferring large amounts of data to the database layer byreturning prefiltered data directly to the PGA. The key concept to understand here is that Smart Scanscan choose (or be forced) to return complete blocks to the SGA. Basically any situation that would causeOracle to have to read another block to complete a record will cause this to happen. A chained row isperhaps the simplest example. When Oracle encounters a chained row, the head piece will contain apointer to the block containing the second row piece. Since the storage cells do not communicatedirectly with each other, and it is unlikely that the chained block resides on the same storage cell,cellsrv simply ships the entire block and allows the database layer to deal with it.So in this very simple case, the Smart Scan is paused momentarily, and a single block read iseffectively performed, which motivates another single block read to get the additional row piece. Keep inmind that this is a very simple case. This same behavior comes into play when Oracle must deal withread consistency issues. For example, if Oracle notices that a block is “newer” than the current query, theprocess of finding an age-appropriate version of the block is left for the database layer to deal with. Thiseffectively pauses the Smart Scan processing while the database does its traditional read consistencyprocessing.So is this really important, and why should you care? The answer, of course, is that it depends. Inmost cases you probably won’t care. Oracle guarantees that reads will be consistent, even when doing49