Expert Oracle Exadata - Parent Directory

CHAPTER 11 UNDERSTANDING EXADATA PERFORMANCE METRICScell blocks helped by commit cacheDuring a Smart Scan in the storage cell, the normal data consistency rules still need to be applied,sometimes with help of undo data. Yes, consistent read guarantees must work also for Smart Scans. Butthe Smart Scan works entirely in the storage cells, where it does not have access to any undo data in thedatabase instances’ buffer caches. And remember that a cell never talks to any other cells by design, so itwould be unable to read the undo data from undo segments striped across many cells too. So, consistentread buffer cloning and rollbacks, whenever needed, would have to be done inside the database layer.Whenever the Smart Scan hits a row, which still has its lock byte set (the row/block hasn’t been cleanedout), it would temporarily have to switch into block I/O mode and send the entire data block back to thedatabase layer for normal consistent read processing— with the help of undo data available there.Note that when a block is cleaned out correctly (lock bytes cleared) and its cleanout SCN in theblock header is from an earlier SCN than the query start time SCN (snapshot SCN), then the cell knowsthat a rollback of that block would not be needed. If the latest change to that block happened earlierthan the query start, then the block image in the cell is valid, a good enough block to satisfy the querywith the given SCN. How does the cell know the starting SCN of a query executed in the database layer?That is the task of the storage-aware row sources in the execution plans, which communicate the SCN tocells over iDB when setting up Smart Scan sessions for themselves.Now, when some of the rows do have nonzero lock bytes in the block or when the cleanout SCN in ablock header happens to be higher than the query’s snapshot SCN, then the cells cannot determine thevalidity of the block/data version themselves and would need to ship the block back to the databaselayer for regular, non-Smart Scan processing. This would considerably slow down the Smart Scanprocessing, if such check had to be done for many locked rows and not cleaned-out blocks.However, there is an optimization that helps to reduce the number of fallbacks to block I/Oprocessing in the database layer. Whenever a Smart Scan finds a locked row during a segment scan, itwill check which transaction locked that row. This can easily be done by reading the transaction’s ITLentry in the current data block header, where the locked row’s lock byte points. Note that bitmap indexsegment blocks and HCC compressed blocks don’t have a lock byte for each single row in the block, butthe idea remains the same— Oracle is able to find out the transaction ID of the locked row(s) from theblock at hand itself. Now, the Smart Scan can send that transaction ID back to the database layer (to thedatabase session owning the cell Smart Scan session) and ask the database session to check whether thattransaction has already committed or not. If this locking transaction has not committed yet, the SmartScan falls back to the block I/O mode for that block and the database layer will have to go through thenormal consistent read buffer cloning/rollback mechanism and there’s no workaround for that. If thetransaction has already committed, but has left the lock bytes not cleaned out in some blocks (this doesusually happen for large DMLs), then the Smart Scan does not have to fall back to block I/O and an indatabase,consistent read mechanism. It knows that this row is not really locked anymore, as the lockingtransaction has committed already, even though the lock byte is still in place.All of that to read a single locked row! When Smart Scanning, you are probably scanning throughmillions or billions of rows, and many of these rows may still have their lock bytes set. So, you don’t wantthe Smart Scan to communicate with the database layer every single time it hits another locked row. So,Oracle cells can cache the information about transaction statuses in an in-memory structure called“commit cache.” It’s probably just an in-memory hash-table, organized by transaction ID, and it keepstrack of which transactions are committed and which are not. When the cell Smart Scan sees a lockedrow, it will extract the transaction ID (from the ITL section of the data block) and checks whether there’sany info about that transaction in the commit cache. This check will increment the statistic cell commitcache queries by one. If there is no such transaction in the commit cache, then the Smart Scan “asks” thestatus of this transaction from the database layer and stores (caches) the result in the commit cache.Ideally every transaction status is fetched into the cache only once, and all subsequent checks will besatisfied from the commit cache. So every time the Smart Scan opens a new block and realizes that there357