Expert Oracle Exadata - Parent Directory

CHAPTER 11 UNDERSTANDING EXADATA PERFORMANCE METRICSare some rows locked but manages to avoid having to talk to the database layer thanks to the commitcache, our statistic at hand, cell blocks helped by commit cache, would be updated by one.Seeing this statistic growing, when your sessions are doing a Smart Scan, indicates that the cellshave some overhead due to checking whether locked rows are really still locked, but thankfully thecommit cache eliminates the need for communicating with the database layer repeatedly. Without thisoptimization, the whole Smart Scan would get slower as it must repeatedly interact with the databaselayer. You would also see more logical I/O being done at the database layer (see the statistics startingwith consistent gets from cache), as opposed to only a single LIO per segment for reading the extentlocations and number of blocks under the High Water Mark out from the segment header. Note: A similar optimization actually exists also in the database layer, and in non-Exadata databases. Oraclecan cache the committed transaction info in the database session’s private memory, so it won’t have to performbuffer gets on the undo segment header when hitting many locked rows. Whenever a session caches a committedtransaction’s state in memory, it increments the Commit SCN cached statistic in its V$SESSTAT array. Whenever itdoes a lookup from that cache, it increments the Cached Commit SCN referenced statistic.If you are not familiar with the delayed block cleanout mechanism in Oracle, you might bewondering how there can be rows with their lock bytes still set, when the transaction has alreadycommitted. This is how Oracle is different from most other mainstream commercial RDBMS products.Oracle doesn’t have to keep the blocks with noncommitted rows cached in memory; DBWR is free towrite them out to disk and release the memory for other data blocks. Now, when committing thetransaction, it wouldn’t be good to read all the transactions back from the disk just to clean up the lockbytes. If there are many such blocks, then your commit might take ages. Instead, Oracle just marks thetransaction complete in its undo segment header slot. Any future block readers can just check whetherthe transaction in that undo segment header slot is still alive or not. If you perform block I/O to read thedata blocks to the database layer later on, then the reading session would clean up the block (clear thelock bytes of rows modified by committed transactions), so no further transaction status checks wouldbe needed in future reads. However, storage cells do not perform block cleanouts, as cells don’t changedata blocks. This is because database block modifications require writing of redo operations, but howwould a cell write to a redo log file that is managed and striped over many cells at the database layeralready?Note that for small transactions, which haven’t modified too many blocks and where the blocks arestill in buffer cache, Oracle can perform block cleanout right during the commit time. Also, the issuesjust discussed do not apply to such databases (data warehouses usually) where tables are loaded withdirect path load inserts (and index partitions are built after the table partitions are loaded), because inthe case of direct loads, the table rows are not locked in the newly formatted table blocks (the sameapplies to index entries in leaf blocks if an index is created after the data load).cell blocks helped by minscn optimizationExadata cell server has another optimization designed to improve consistent read efficiency even more.It’s called the Minimum Active SCN optimization and it keeps track of the lowest SCN of any still active(uncommitted) transaction in the database. This allows us to easily compare the SCN in the ITL entriesof the locking transactions with the lowest SCN of the “oldest” active transaction in the database. As the358