Applying a  Blockcentric Approach to Oracle Tuning Daniel W. Fink www.optimaldba.com
Overview <ul><li>What is Blockcentric Approach? </li></ul><ul><ul><li>Shifting Focus for Architectural and Tuning Decision...
Trust, But Verify <ul><li>Information presented is general </li></ul><ul><li>It will not cover all scenarios all databases...
<ul><li>“ Scientists are by definition highly rational beings who pursue truths supported by hard data.” </li></ul><ul><li...
What is the Blockcentric Approach? <ul><li>Closely tied to Oracle I/O subsystem </li></ul><ul><ul><li>Protecting memory st...
Oracle’s I/O Subsytem <ul><li>Blocks not Rows </li></ul><ul><li>Logical v. Physical I/O </li></ul><ul><li>Full Scans </li>...
Blocks not Rows <ul><li>Blocks are read, not rows </li></ul><ul><li>Larger block sizes means more rows per block </li></ul>
Logical I/O <ul><li>Not just memory access </li></ul><ul><li>Accessing Block in memory </li></ul><ul><li>Requires locking ...
Physical I/O <ul><li>Not always disk access </li></ul><ul><li>Block not found in memory </li></ul><ul><li>Could be found i...
Full Scans <ul><li>Able to read multiple blocks at one time </li></ul><ul><li>Full Table Scan </li></ul><ul><ul><li>Read a...
High Water Mark <ul><li>The High Water Mark is the last block ever formatted to contain data. </li></ul><ul><li>If the tab...
High Water Mark H D D D D HWM
Myths and Fallacies <ul><li>99.999% Buffer Cache Hit Ratio is GOOD </li></ul><ul><li>% of Rows Returned determines index u...
Buffer Cache Hit Ratio <ul><li>Higher is not always better </li></ul><ul><li>What happens when 99% is not good enough? </l...
Higher Is Not Always Better <ul><li>It is an indication of hard work, not necessarily smart work </li></ul><ul><ul><li>99....
BCHR Method <ul><li>Statement #1 – 98% BCHR </li></ul><ul><ul><li>5000 Logical I/Os </li></ul></ul><ul><ul><li>100 Physica...
What Happens When 99% Is Not Good Enough? <ul><li>Everything is tuned, but the system is still slow… </li></ul><ul><li>Add...
Memory Speed Fallacy <ul><li>Disk access is 10,000 times more expensive than Memory Access </li></ul><ul><ul><li>Measured ...
Determining True Cost of Statements <ul><li>Compute total cost in terms of I/O </li></ul><ul><li>Logical I/O costs 1 </li>...
Blockcentric Method <ul><li>Statement #1 – 98% BCHR </li></ul><ul><ul><li>5100 Logical I/Os </li></ul></ul><ul><ul><li>100...
% Of Rows Returned <ul><li>Index usage </li></ul><ul><li>Number of Blocks Returned </li></ul><ul><li>Data Considerations <...
Index Usage <ul><li>Use index if % of rows returns is less than </li></ul><ul><ul><li>15% for nonparallel </li></ul></ul><...
Number Of Blocks Returned <ul><li>Focus on number of blocks to be read </li></ul><ul><ul><li>Data scattered – many blocks ...
Scattered Data <ul><li>Data of interest is scattered among many blocks </li></ul>H
Pop Quiz  1 <ul><li>A query returns 0.6% of the rows. Match the method with the # of consistent gets (logical I/Os) </li><...
Clustered Data <ul><li>Data of interest is present in a few blocks </li></ul>H
Fragmented Data <ul><li>Blocks containing data are interspersed with empty blocks </li></ul>H D D D D D D
Pop Quiz  2 <ul><li>A query returns 100% of the rows. Match the method with the # of consistent gets (logical I/Os) </li><...
High Water Mark H D D D D HWM
Pop Quiz  3 <ul><li>A query returns 100% of the rows. Match the method with the # of consistent gets (logical I/Os) </li><...
Continued Data <ul><li>Rows are migrated or chained </li></ul><ul><li>Multiple I/O operations  </li></ul>
Index all WHERE Columns <ul><li>Indexes may speed queries </li></ul><ul><ul><li>But will always slow other operations </li...
Full Table Scans are BAD <ul><li>It depends </li></ul><ul><li>Focus on # of I/O operations </li></ul><ul><ul><li>Multibloc...
Determining Block Selectivity <ul><li>Identify the data to be returned by focusing on the WHERE clause </li></ul><ul><li>C...
DUAL <ul><li>Table often used for non-SELECT operations </li></ul><ul><li>Very expensive, </li></ul><ul><ul><li>Very few I...
Miscellaneous Tuning Tips <ul><li>Focus on overall length of operations </li></ul><ul><li>Reduce the I/Os </li></ul><ul><l...
Focus on overall length of operations <ul><li>Record ‘Bad’ time </li></ul><ul><li>Decide on ‘Good’ time </li></ul><ul><li>...
Reduce the I/Os <ul><li>Avoid the BCHR Myth </li></ul><ul><ul><li>BCHR is not useless, it may indicate problems </li></ul>...
Identify resource intensive SQL –  tune it first <ul><li>Look for statements consuming most I/O </li></ul><ul><ul><li>Logi...
Table and Index Maintenance <ul><li>‘Sort tables according to primary key value’ – Fallacy </li></ul><ul><li>Sort tables t...
Extent Sizing <ul><li>Extent sizes should be multiples of multi block read configuration </li></ul><ul><ul><li>Multiblock ...
Sources <ul><li>“ Oracle Performance Tuning 101” Vaidyanatha, Deshpande, Kostelac, Jr. </li></ul><ul><li>“ Oracle SQL Tuni...
Training Days 2003 <ul><li>Rocky Mountain Oracle User Group Training Days 2003 </li></ul><ul><ul><li>Wednesday, March 5 & ...
<ul><li>It is not important to  find  the  right   answers . </li></ul><ul><li>It is important to  ask  the  right   quest...
Upcoming SlideShare
Loading in …5
×

Applyinga blockcentricapproachtotuning

503 views

Published on

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
503
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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.
  • Statement 1 - Cost = 5100 + (100 * 10000) = 1,005,100 Statement 2 - Cost = 400 + (200 * 10000) = 2,000,400
  • 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.
  • Applyinga blockcentricapproachtotuning

    1. 1. Applying a Blockcentric Approach to Oracle Tuning Daniel W. Fink www.optimaldba.com
    2. 2. Overview <ul><li>What is Blockcentric Approach? </li></ul><ul><ul><li>Shifting Focus for Architectural and Tuning Decisions </li></ul></ul><ul><li>Myths and Fallacies </li></ul><ul><ul><li>“Burn him at the stake!” </li></ul></ul><ul><li>Applying the Method </li></ul><ul><ul><li>Will be addressed throughout the presentation </li></ul></ul>
    3. 3. Trust, But Verify <ul><li>Information presented is general </li></ul><ul><li>It will not cover all scenarios all databases </li></ul><ul><li>Only covers 1 aspect of tuning and architecture </li></ul>
    4. 4. <ul><li>“ Scientists are by definition highly rational beings who pursue truths supported by hard data.” </li></ul><ul><li>- Alisa Smith </li></ul>
    5. 5. What is the Blockcentric Approach? <ul><li>Closely tied to Oracle I/O subsystem </li></ul><ul><ul><li>Protecting memory structures </li></ul></ul><ul><ul><li>Single and Multiple Read operations </li></ul></ul><ul><li>Shifts focus from Rows to Blocks </li></ul><ul><ul><li>Many traditional methods focus on rows </li></ul></ul><ul><ul><li>I/O system understands blocks </li></ul></ul>
    6. 6. Oracle’s I/O Subsytem <ul><li>Blocks not Rows </li></ul><ul><li>Logical v. Physical I/O </li></ul><ul><li>Full Scans </li></ul>
    7. 7. Blocks not Rows <ul><li>Blocks are read, not rows </li></ul><ul><li>Larger block sizes means more rows per block </li></ul>
    8. 8. Logical I/O <ul><li>Not just memory access </li></ul><ul><li>Accessing Block in memory </li></ul><ul><li>Requires locking of various memory structures </li></ul>
    9. 9. Physical I/O <ul><li>Not always disk access </li></ul><ul><li>Block not found in memory </li></ul><ul><li>Could be found in os buffer cache or prefetched from disk </li></ul>
    10. 10. Full Scans <ul><li>Able to read multiple blocks at one time </li></ul><ul><li>Full Table Scan </li></ul><ul><ul><li>Read all blocks up to the High Water Mark </li></ul></ul><ul><li>Fast Full Index Scan </li></ul><ul><ul><li>Can access non-leading columns in concatenated indexes </li></ul></ul>
    11. 11. High Water Mark <ul><li>The High Water Mark is the last block ever formatted to contain data. </li></ul><ul><li>If the table has experienced high delete activity, the HWM may be set artificially high </li></ul><ul><li>If indicated, the only solution is to reorganize the table </li></ul>
    12. 12. High Water Mark H D D D D HWM
    13. 13. Myths and Fallacies <ul><li>99.999% Buffer Cache Hit Ratio is GOOD </li></ul><ul><li>% of Rows Returned determines index usage </li></ul><ul><li>Index all WHERE columns </li></ul><ul><li>Full Table Scans are BAD </li></ul><ul><li>DUAL is a low cost, useful table </li></ul>
    14. 14. Buffer Cache Hit Ratio <ul><li>Higher is not always better </li></ul><ul><li>What happens when 99% is not good enough? </li></ul><ul><li>Memory Speed Fallacy </li></ul><ul><li>Determining Statement Cost </li></ul>
    15. 15. Higher Is Not Always Better <ul><li>It is an indication of hard work, not necessarily smart work </li></ul><ul><ul><li>99.999% BCHR requires 100,000 I/Os </li></ul></ul><ul><li>Not a good response to user performance problems </li></ul>
    16. 16. BCHR Method <ul><li>Statement #1 – 98% BCHR </li></ul><ul><ul><li>5000 Logical I/Os </li></ul></ul><ul><ul><li>100 Physical I/Os </li></ul></ul><ul><li>Statement #2 – 50% BCHR </li></ul><ul><ul><li>400 Logical I/Os </li></ul></ul><ul><ul><li>200 Physical I/Os </li></ul></ul>
    17. 17. What Happens When 99% Is Not Good Enough? <ul><li>Everything is tuned, but the system is still slow… </li></ul><ul><li>Add </li></ul><ul><ul><li>More Memory </li></ul></ul><ul><ul><li>Faster CPU </li></ul></ul><ul><ul><li>Faster Disk </li></ul></ul><ul><ul><li>Faster Network </li></ul></ul><ul><li>Makes hardware sales reps happy… </li></ul>
    18. 18. Memory Speed Fallacy <ul><li>Disk access is 10,000 times more expensive than Memory Access </li></ul><ul><ul><li>Measured in a ‘pure’ environment </li></ul></ul><ul><li>In practice, the ratio is closer to 40 </li></ul><ul><ul><li>Request does not go directly to block in cache </li></ul></ul><ul><ul><li>The requested block must be located </li></ul></ul><ul><ul><li>Memory structures must be accessed and manipulated </li></ul></ul><ul><ul><li>Disk access may not be actual disk access </li></ul></ul>
    19. 19. Determining True Cost of Statements <ul><li>Compute total cost in terms of I/O </li></ul><ul><li>Logical I/O costs 1 </li></ul><ul><li>Physical I/O costs 40 </li></ul><ul><li>Cost = LIOs + (PIOs * 40) </li></ul>
    20. 20. Blockcentric Method <ul><li>Statement #1 – 98% BCHR </li></ul><ul><ul><li>5100 Logical I/Os </li></ul></ul><ul><ul><li>100 Physical I/Os </li></ul></ul><ul><ul><li>Cost = 5100 + (100 * 40) = 9100 </li></ul></ul><ul><li>Statement #2 – 50% BCHR </li></ul><ul><ul><li>400 Logical I/Os </li></ul></ul><ul><ul><li>200 Physical I/Os </li></ul></ul><ul><ul><li>Cost = 400 + (200 * 40) = 8400 </li></ul></ul>
    21. 21. % Of Rows Returned <ul><li>Index usage </li></ul><ul><li>Number of Blocks Returned </li></ul><ul><li>Data Considerations </li></ul>
    22. 22. Index Usage <ul><li>Use index if % of rows returns is less than </li></ul><ul><ul><li>15% for nonparallel </li></ul></ul><ul><ul><li>5% for parallel </li></ul></ul><ul><li>Assumes </li></ul><ul><ul><li>rows are clustered </li></ul></ul><ul><ul><li>rows are read </li></ul></ul>
    23. 23. Number Of Blocks Returned <ul><li>Focus on number of blocks to be read </li></ul><ul><ul><li>Data scattered – many blocks to be read </li></ul></ul><ul><ul><li>Data clustered – fewer blocks to be read </li></ul></ul><ul><ul><li>Data fragmented – many/fewer blocks to be read </li></ul></ul><ul><li>Bottom Line – Reduce the Number of Blocks read </li></ul>
    24. 24. Scattered Data <ul><li>Data of interest is scattered among many blocks </li></ul>H
    25. 25. Pop Quiz 1 <ul><li>A query returns 0.6% of the rows. Match the method with the # of consistent gets (logical I/Os) </li></ul><ul><li>Full Table Scan 1. 6800 </li></ul><ul><li>Index Scan 2. 7200 </li></ul>
    26. 26. Clustered Data <ul><li>Data of interest is present in a few blocks </li></ul>H
    27. 27. Fragmented Data <ul><li>Blocks containing data are interspersed with empty blocks </li></ul>H D D D D D D
    28. 28. Pop Quiz 2 <ul><li>A query returns 100% of the rows. Match the method with the # of consistent gets (logical I/Os) </li></ul><ul><li>Full Table Scan 1. 8500 </li></ul><ul><li>Index Scan 2. 6100 </li></ul>
    29. 29. High Water Mark H D D D D HWM
    30. 30. Pop Quiz 3 <ul><li>A query returns 100% of the rows. Match the method with the # of consistent gets (logical I/Os) </li></ul><ul><li>Full Table Scan 1. 1500 </li></ul><ul><li>Index Scan 2. 7100 </li></ul>
    31. 31. Continued Data <ul><li>Rows are migrated or chained </li></ul><ul><li>Multiple I/O operations </li></ul>
    32. 32. Index all WHERE Columns <ul><li>Indexes may speed queries </li></ul><ul><ul><li>But will always slow other operations </li></ul></ul><ul><li>Unique constraints require indexes </li></ul><ul><li>Index Foreign Keys </li></ul><ul><ul><li>Locking problems </li></ul></ul><ul><ul><li>Join column </li></ul></ul>
    33. 33. Full Table Scans are BAD <ul><li>It depends </li></ul><ul><li>Focus on # of I/O operations </li></ul><ul><ul><li>Multiblock reads </li></ul></ul><ul><ul><li>Data and Block clustering </li></ul></ul><ul><li>Focus on ends, not means </li></ul>
    34. 34. Determining Block Selectivity <ul><li>Identify the data to be returned by focusing on the WHERE clause </li></ul><ul><li>Calculate the Actual Blocks to be accessed </li></ul><ul><ul><li># of blocks below HWM </li></ul></ul><ul><ul><li># of blocks containing data </li></ul></ul><ul><li>Determine how many block selectivity </li></ul><ul><ul><li># of Rows with value / # of Blocks with Row </li></ul></ul><ul><ul><li># of Rows with value / # of Blocks below HWM </li></ul></ul>
    35. 35. DUAL <ul><li>Table often used for non-SELECT operations </li></ul><ul><li>Very expensive, </li></ul><ul><ul><li>Very few I/Os per access </li></ul></ul><ul><ul><li>May actually comprise the largest I/O consumer </li></ul></ul><ul><li>Solutions </li></ul><ul><ul><li>Rewrite code </li></ul></ul><ul><ul><li>Create virtual table </li></ul></ul>
    36. 36. Miscellaneous Tuning Tips <ul><li>Focus on overall length of operations </li></ul><ul><li>Reduce the I/Os </li></ul><ul><li>Identify resource intensive SQL, tune it first </li></ul><ul><li>Table and Index Maintenance </li></ul><ul><li>Make extent sizes multiples of db_block_size * db_file_multiblock_read_count </li></ul>
    37. 37. Focus on overall length of operations <ul><li>Record ‘Bad’ time </li></ul><ul><li>Decide on ‘Good’ time </li></ul><ul><li>Identify where statement is spending most time and tune accordingly </li></ul><ul><li>When Good time is achieved, stop and move on to the next one </li></ul>
    38. 38. Reduce the I/Os <ul><li>Avoid the BCHR Myth </li></ul><ul><ul><li>BCHR is not useless, it may indicate problems </li></ul></ul><ul><ul><ul><li>Excessively High </li></ul></ul></ul><ul><ul><ul><li>Excessively Low </li></ul></ul></ul><ul><li>Identify the most expensive statements </li></ul><ul><ul><li>Find most I/O Intensive </li></ul></ul><ul><ul><li>Reduce Logical I/Os…Physical will follow </li></ul></ul><ul><li>Reorganize tables when needed </li></ul><ul><ul><li>High Water Mark </li></ul></ul><ul><ul><li>Data or Blocks Not clustered </li></ul></ul>
    39. 39. Identify resource intensive SQL – tune it first <ul><li>Look for statements consuming most I/O </li></ul><ul><ul><li>Logical Reads + Physical Reads </li></ul></ul><ul><li>Identify tables with most activity </li></ul><ul><li>Don’t tune 1 query to the detriment of 9 others </li></ul>
    40. 40. Table and Index Maintenance <ul><li>‘Sort tables according to primary key value’ – Fallacy </li></ul><ul><li>Sort tables to achieve common clustering </li></ul><ul><li>Rebuild tables and indexes to </li></ul><ul><ul><li>Reduce storage requirements </li></ul></ul><ul><ul><li>Reset high water mark </li></ul></ul>
    41. 41. Extent Sizing <ul><li>Extent sizes should be multiples of multi block read configuration </li></ul><ul><ul><li>Multiblock read configuration should match hardware limitations </li></ul></ul><ul><li>If extent is 1 block less, multiple I/O calls will be executed </li></ul><ul><ul><li>Even if ‘extra’ blocks are empty, it may be more efficient </li></ul></ul>
    42. 42. Sources <ul><li>“ Oracle Performance Tuning 101” Vaidyanatha, Deshpande, Kostelac, Jr. </li></ul><ul><li>“ Oracle SQL Tuning Pocket Reference” Gurry </li></ul><ul><li>Performance Sites </li></ul><ul><ul><li>www.hotsos.com - Cary Millsap </li></ul></ul><ul><ul><li>www.orapub.com - Craig Shallahamer </li></ul></ul><ul><ul><li>www.evdbt.com - Tim Gorman and Jeff Maresh </li></ul></ul><ul><ul><li>www.oraperf.com - Anjo Kolk </li></ul></ul>
    43. 43. Training Days 2003 <ul><li>Rocky Mountain Oracle User Group Training Days 2003 </li></ul><ul><ul><li>Wednesday, March 5 & Thursday, March 6 </li></ul></ul><ul><li>Denver Colorado </li></ul><ul><ul><li>Stay and Ski information available on website </li></ul></ul><ul><li>Scheduled speakers include </li></ul><ul><ul><li>Tim Gorman, Craig Shallahamer, Anjo Kolk, Gary Dodge, Stephan Haisley, John King, Brad Brown, Rachel Carmichael </li></ul></ul><ul><li>Details available at www.rmoug.org </li></ul><ul><ul><li>NYOUG members eligible for Member Rate </li></ul></ul>
    44. 44. <ul><li>It is not important to find the right answers . </li></ul><ul><li>It is important to ask the right questions . </li></ul>

    ×