Hi, This blog contains some questions about material I covered in the recent SQL Performance Tuning webinars I did for Toad World. IF you have questions about Oracle, PL/SQL, performance tuning…funnel them to me at DanHotka@Gmail.com . I’ll do my best to answer based on the level of detail you send. I generally share my answers in these blogs, removing your name and contact information (unless you are good with it being in there…most don’t want their names to appear). Enjoy the answers to the clustering factor part of my presentation. I posted the Index_Info.sql script last week, pull it from there if you would like to use it. Hi, Dan: Thank you for the Dell Webnars you presented lately. I really enjoyed them and learned. I have some questions about your index_info.sql script: Question 1 . I found one "poor" index with very high clustering factor ratio. How do I make clustering factor lower ? I rebuilt the index, updated stats, validated structure... Nothing made clustering factor lower. DAN REPLIES >>> As per the discussion in the webinar, clustering factor is a % that is derived from the relationship of the order of the rows in the table to the indexing key value. Indexes are maintained in sequence so...when you are doing a range scan (ie: selecting repeating values such as city = 'Des Moines', name = 'HOTKA'...etc), how many different data blocks does EACH leaf block point to. Clustering factor is multiplied in on range scans and if the value is over 20%, Oracle's cost based optimizer generally does a full table scan operation...ie: will be accessing more than 20% of the underlying table, Oracle has always preferred to do a full table scan. This was corroborated by the optimizer group at Oracle, they reviewed my index_info script and liked it. Single row lookups...clustering factor isn't used and isn't needed because you are accessing 1 index leaf block to access 1 data block. Question 2. There has been a popular script since many years ago from Oracle to discover fragmented indexes by finding height>4 and del_lf_rows/lf_rows >20%. Is this script obsolete for Oracle 11g/12c in your opinion ? I found the bad index identified by this script is "excellent" when using your script, while "poor" index identified with your script appears acceptable with Oracle script. SQL from the person asking>>> SELECT name, height,lf_rows,lf_blks,del_lf_rows FROM INDEX_STATS; DAN REPLIES >>> Height is the number of levels in the index. This used to be an indicator of when to reorg an index. My opinion from yesteryear was more of when this number increased, the index added another level (and was typically lopsided when this happened...ie: more rows at one end of the b-tree than the other). This is more of just an extra I/O operation when starting the index usage process...not a huge factor on performance really. It is more of a sign, when height increased, that it was time to reorg the index. My opinion, and I also shared this in the webinar, is...when the table meets the 'stale' requirements, its a good time to reorg the indexes too. Lots of DML has a huge impact on index space utilization and the less free space in your leaf blocks, the faster and less physical I/O operations your range scan operations will require...hence...better performance. Height has no real impact on the performance of the index. Clustering factor tells the CBO what the relationship is and the percentage of table blocks that will be needed to satisfy the range of the scan. This has a direct impact on performance, not the height factor. The index_info script keys off of clustering factor and this relationship of order. How you lower the clustering factor? Reorg the table and put the rows back in the table in the order of the key value of the index. This will fix that particular index...at the expense of all the other indexes. You can only have the table data in 1 order...so...only 1 index will have a super low (or excellent) rating, the others are all kind of how wide is your range and what is the clustering factor to whether the index will be used at all...ie: poor quality indexes should be dropped. I have heard but not verified that Oracle11+ does not leave empty leaf blocks in the index anymore...I have also heard that a reorg will also now not leave empty blocks behind in the index leaf row. I’ll do my best to share useful information from your questions. I’ll continue with Oracle12.2 new features syntax and technology as well. Thank you for following my blogs. Dan Hotka Oracle ACE Director Author/Instructor/CEO
↧