How to find the worst cluf having indexes? on 10gR2

Question

If the clustering factor(dba_index.clustering_factor) value is close to number of rows of the related table(dba_table.num_rows) this shows bad clustering_factor(CLUF) where as if CLUF is close to the number of blocks of that related table than this shows good CLUF.
So how may I find the indexes having the worst CLUF valuse in my database. Looking for an SQL operator which produces this "close to" output;
create table tdba_indexes nologging parallel 4 pctused 99 pctfree 1 as
SELECT t2.owner, t2.table_name, index_name, clustering_factor, t2.num_rows, t2.blocks, t2.sample_size
  FROM dba_indexes t1, dba_tables t2
WHERE clustering_factor > 0
   AND t1.owner NOT IN ('SYS', 'SYSTEM')
   AND t2.owner NOT IN ('SYS', 'SYSTEM')
   and t1.owner = t2.owner
   and t1.table_name = t2.table_name
   AND t2.blocks > 0
ORDER BY clustering_factor DESC ;
create table tcluf_bad nologging parallel 4 pctused 99 pctfree 1 as 
SELECT *
  FROM (SELECT CASE
                  WHEN a_sql_operator_needed_here_for_close_to_determination THEN
                   'BAD'
                  ELSE
                   'NOT SO BAD'
               END AS "CLUF",
               abs(clustering_factor / num_rows) ratio1,
               abs(clustering_factor / blocks) ratio2,
               t.*
          FROM tdba_indexes t)
WHERE cluf = 'BAD' ;Thank you.

Answer 1

John thank you for your comments. You are right, making structural changes on a table(like CTAS with ORDER BY parallel to the bad CLUF indexes' columns sort) may introduce new problems for other queries involved with other indexes.
This is not a good approach after all. What I am trying is to reduce he high db file sequntial read waits on my CRM database.
http://www.perfvision.com/wait/db_file_sequential_read.html
My primary focus must be SQL and Application tuning to reduce the logical i/o amounts of these queries which are the root cause of this wait. But also I saw that these queries have high CLUF values and doing INDEX RANGE SCAN and this kind of a change may also helpful.
In order to find the root cause queries of this wait I am planning to use this query, can I also have your comments on this;
SELECT a.sql_text, t.*
  FROM (SELECT tt.*
          FROM (SELECT rownum rn, x.*
                  FROM (SELECT a.sql_text, a.user_io_wait_time, a.executions, a.sql_id
                          FROM v$sqlstats a
                         WHERE user_io_wait_time > 0
                           AND executions > 10
                         ORDER BY a.user_io_wait_time DESC) x) tt
         WHERE rn < 11) a,
       TABLE(dbms_xplan.display_cursor(a.sql_id,
                                       NULL,
                                       'ALL')) t
WHERE plan_table_output LIKE '%INDEX%RANGE%SCAN%';Best regards.
Message was edited by:
antu