The document discusses applying a blockcentric approach to Oracle tuning, which focuses on blocks of data rather than individual rows and shifts tuning decisions based on the number of blocks accessed rather than traditional metrics like buffer cache hit ratios. It addresses myths around traditional tuning methods and provides guidance on identifying resource-intensive SQL, reducing I/O operations, maintaining tables and indexes, and determining true statement costs.
This is a very high level presentation. Intended to offer new ideas, a new approach. This
Use the ideas here to begin to examine your systems. Each db system will have nuances that need to be addressed.
A request for a single byte column in a single row will result in the entire block being accessed.
A request for a single byte column in a single row will result in the entire block being accessed.
Try this. Insert 1 million rows into an empty table, but rollback. Then do a select * from the table. Then truncate the table and rerun the query. Truncate resets the HWM.
65 blocks below HWM 200 rows per block 13,000 rows Query selects 100 rows or .77% of the rows Query reads 53 blocks or 82% of the blocks
65 blocks below HWM 200 rows per block 13,000 rows Query selects 100 rows or .77% of the rows Query reads 7 blocks or 11% of the blocks
65 blocks below HWM, but only 6 contain data 200 rows per block 1200 rows Query selects 1200 rows or 100% of the rows Query reads 6 blocks or 10% of the blocks
How do you determine the # of blocks containing data? Not straightforward, if rows are chained or have migrated. Using dbms_rowid only returns the ‘head’ piece for a continued row.