Nice demonstrations.

I was suffering from a bit of a mental block a couple of days ago when trying to visualize what the clustering factor should be for the ascending and descending sequence of numbers. I am still a little upset with myself about the second to the last paragraph in this article. Fortunately, people like you, Dom Brooks, and Narendra stepped up to identify the logic flaw in my reasoning.

That’s a pretty good demonstration of clustering factor. Lession learnt for me too..
After going through the test case, I just check across the trace file, while collecting statistics and finally came to information which you stated across. Thanks for sharing across and even Jonathan posted across the information quite long before

http://www.jlcomp.demon.co.uk/index_efficiency.html

That is awesome. Did not know that. Thanks.

“I could not give a dry answer, depends on the case and the variables in play”
(I think that this statement is almost always)

But honestly I would not have immediately thought of all the possible combinations.

With regard to the clustering factor, re-running your test, I get
the following result:

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE    11.2.0.2.0      Production
TNS for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production


SQL> SELECT a.table_name,
  2         a.index_name,
  3         a.clustering_factor,
  4         a.num_rows,
  5         b.BLOCKS as table_blocks
  6  FROM  user_indexes a
  7  join  user_tables  b
  8  on    a.TABLE_NAME = b.TABLE_NAME
  9  where a.TABLE_NAME = 'T1'
 10  ORDER BY a.TABLE_NAME,
 11           a.INDEX_NAME;

TABLE_NAME  INDEX_NAME  CLUSTERING_FACTOR NUM_ROWS   TABLE_BLOCKS
----------- ----------- ----------------- ---------- ------------
T1          IND_T1_C1   15873             1000000    16267
T1          IND_T1_C2   15873             1000000    16267

I was not surprised by the value of the clustering factor on the columns c1
and c2.

The definition I give to the clustering factor is as follows:

“represents the adjacent index keys
not point to the same data block. ”

In your case can not be different .. can not

Narendra,

If I remember correctly, Oracle, calculate the clustering factor
using the function(undocumented) sys_op_countchg.
If I remember correctly, I read this thing on the book by
J. Lewis or somewhere else.

In the case of the index, the table T1 in the test of Charles:

SQL> select /*+ cursor_sharing_exact
  2        dynamic_sampling(0)
  3        no_monitoring
  4        no_expand
  5        index(t1,"IND_T1_C1")
  6        noparallel_index(t1,"IND_T1_C1") */
  7     sys_op_countchg(substrb(t1.rowid,1,15),1) as clustering_factor
  8     from t1 ;

CLUSTERING_FACTOR
-----------------
            15873

In the case of your example (with duplicate values)

SQL> CREATE TABLE T2 (
  2    C1 NUMBER,
  3    C2 NUMBER);

SQL> INSERT INTO
  2  T2
  3  SELECT C1, C2 FROM (
  4  SELECT
  5  MOD(ROWNUM,1000) C1,
  6  1000 - MOD(ROWNUM,1000) C2
  7  FROM
  8  DUAL
  9  CONNECT BY
 10  LEVEL<=100000)
 11  ORDER BY C1;

SQL> commit;


SQL> CREATE INDEX IND_T2_C1 ON T2(C1);

SQL> CREATE INDEX IND_T2_C2 ON T2(C2);

SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T2',CASCADE=>TRUE,ESTIMATE_PERCENT=>NULL)


SQL> SELECT a.table_name,
  2         a.index_name,
  3         a.clustering_factor,
  4         a.num_rows,
  5         b.BLOCKS as table_blocks
  6  FROM  user_indexes a
  7  join  user_tables  b
  8  on    a.TABLE_NAME = b.TABLE_NAME
  9  where a.TABLE_NAME = 'T2'
 10  ORDER BY a.TABLE_NAME,
 11           a.INDEX_NAME;

TABLE_NAME  INDEX_NAME   CLUSTERING_FACTOR NUM_ROWS   TABLE_BLOCKS
----------- ------------ ----------------- ---------- ------------
T2          IND_T2_C1    122               100000     121
T2          IND_T2_C2    228               100000     121

how is it calculated?

Reflecting on the definition of clustering factor that I gave earlier:

“How many adjacent index keys
not point to the same data block. ”

So, if I think the definition of the clustering factor, I can imagine that Oracle does something like this:

1) for column c1 of table t2

SQL> select count(*) clusf
  2  from (
  3  with dist_key_blk as (
  4             select distinct c1
  5             , dbms_rowid.rowid_block_number(rowid) as current_blk
  6             , lead(dbms_rowid.rowid_block_number(rowid), 1, 99999999) over (ORDER BY c1) as next_blk
  7             from t2
  8             order by 1, 2
  9  )
 10  select c1
 11       , current_blk
 12       , next_blk
 13  from dist_key_blk
 14  where current_blk <> next_blk
 15  )
 16  ;

     CLUSF
----------
       122

2) for column c2 of table t2

SQL> select count(*) clusf
  2  from (
  3  with dist_key_blk as (
  4             select distinct c2
  5             , dbms_rowid.rowid_block_number(rowid) as current_blk
  6             , lead(dbms_rowid.rowid_block_number(rowid), 1, 99999999) over (ORDER BY c2) as next_blk
  7             from t2
  8             order by 1, 2
  9  )
 10  select c2
 11       , current_blk
 12       , next_blk
 13  from dist_key_blk
 14  where current_blk <> next_blk
 15  );

     CLUSF
----------
       228

Obviously, the query is only the fruit of my imagination, how it should work according to the definition …
I did not say which is right, but I think it’s pretty close …

HTH

Donatello Settembrino

As per my knowledge it would be depend on the part of the of data that got inserted and % deletions/modifications carried out on index segment (impacted by table changes). From you example I observe that, index tree would right hand tree for c1 and left hand tree for c2 columns, as the data got inserted in chronological order. Looking into real transaction table, we might not come across. So as the data got inserted newly segment (perhaps no row migrations/chained rows) – inturn directly impacting on index it would be less. From the posted example in the above scenario, we hae 0% changes we could see the “table data is stored clustered as per index key values”.

I hope it would be helpful to suggest your valuable comments, so inturn I can rectify my understanding with concept.

Thanks for correcting my post. I should have mentioned my test was carried out on 10.2.0.1.
Now, I must admit that I don’t know how oracle calculates clustering factor so I can’t really explain whether (and how) number of non-unique index key values will impact the index clustering factor when the table data is in exact reverse order of the index key but I have a feeling that as long as the “exact reverse order” criteria is met by table data (with corresponding index keys), the clustering factor would remain close to number of blocks (rather than number of rows), which would enable the CBO to use that index to access data when possible.

Nice example! I was expecting to see results similar to those for the test case that I posted in this blog article. I guess that is the reason why results should be tested when the results are inconsistent with what one remembers to be true. These are the results that I received on one of the servers (running 10.2.0.2):

TABLE_NAME INDEX_NAME CLUSTERING_FACTOR   NUM_ROWS     BLOCKS
---------- ---------- ----------------- ---------- ----------
T2         IND_T2_C1                221     100000        180
T2         IND_T2_C2                479     100000        180

Nice catch – you are correct regarding the C3/C4 column was populated. I wonder if that is a sign that I need to work on my short-term memory too. I see that I have a bit more experimentation to do before clustering some other factor again.

You’ve said C3 in your comment above, but that seems to be C4 from the original examples.

> a faint memory of something that I just simply do not think about often enough
If it wasn’t for faint memories and vague recollections, my mind would be blank.