Expert Oracle Exadata - Parent Directory

CHAPTER 11 UNDERSTANDING EXADATA PERFORMANCE METRICSto avoid falling back to reduce the amount of communication with thedatabase layer if it hits locked rows and not cleaned out blocks of committedtransactions. When there is no need to fall back to block I/O and databaselayerconsistent reads, then the consistent reads will be performed by the datalayer or index layer code inside the storage cell. However, if the consistent readcannot be completed within the cell, then the entire data block at hand mustbe transported back to the database layer and the consistent read will beperformed there.The point of this explanation is that if the Smart Scans work optimally, they do not have to interrupttheir work and talk to the database layer during the Smart Scan processing; ideally all the scanning workis done in the storage cell, and once enough rows are ready to be returned, they’re sent to the databasein a batch. If this is the case, then the cell blocks processed by data layer (or index layer) statistic will be ashigh as the cell blocks processed by cache layer (and txn layer), showing that all the blocks could be fullyprocessed in the cell and rows extracted from them without having to fall back to database-layer blockI/O and consistent reads.Remember that all this complexity related to consistent reads in storage cells matters only whendoing a Smart Scan. When doing regular block I/O, cells just pass the blocks read directly back to thedatabase layer, and the consistent read logic is executed in the database layer as usual. And youshouldn’t really worry about these metrics unless you see that your Smart Scan wait events tend to beinterspersed with cell single block physical reads, consuming a significant part of your query responsetime.cell commit cache queriesThis is the number of times the cell Smart Scan looked up a transaction status from the cell commitcache hash table. A lookup from commit cache is normally done once per uncommitted transactionfound per block scanned by Smart Scan— where the MinActiveSCN optimization hasn’t already kickedin and eliminated the need to check for individual transaction statuses. This is closely related to the cellblocks helped by commit cache statistic.cell flash cache read hitsThis statistic shows how many I/O requests were satisfied from the cell flash cache, so that a hard diskread was not necessary. Note that we said “hard disk read,” not just physical read. That’s because thereads from flash cards also require physical reads (system calls resulting in flash card I/O). When you seethis number, it means that the required blocks were not in the database layer buffer cache (or the accesspath chose to use a direct path read), but luckily all the blocks required by an I/O request were in cellflash cache (the official term is Exadata Smart Flash Cache). Note that this number shows the number ofI/O requests, not the number of blocks read from cell flash cache. Remember that cell flash cache isusable both by regular block reads and cell Smart Scans. Especially if you run an OLTP database onExadata, for best performance you should attempt to satisfy most single-block reads from either thedatabase buffer cache or, failing that, the cell flash cache. You can read more about the Exadata FlashCache in Chapter 5.361