Clustering Factor

Oracle toma las I/O por bloques. Por lo tanto la decisión del optimizador de realizar TABLE FULL SCAN  está influenciado por la cantidad de bloques accedidos, no de filas. Esto es conocido como index cluatering factor. Si los bloques contienen una fila, entonces, las filas y bloques accedidos son los mismos.

Por todo esto, el clustering factor es una característica muy importante para la toma de decisiones del CBO, mas concretamente, a la hora de elegir el coste asociado a una operación mediante un INDEX RANGE SCAN o un TABLE FULL SCAN.

Con esta característica podemos observar la ordenación del índice con los datos en la tabla. Una tabla con los datos mal ordenados tendrá un clustering factor alto o cercano al número de registros, lo cual llevará a que el CBO acceda a los datos mediante FULL TABLE SCAN. Por el contrario si los datos están bien ordenados en la tabla , tendremos un clustering factor bajo o cercano al numero de bloques de datos, y el CBO llevara a cabo un INDEX RANGE SCAN.

Cuando un índice puede ser usado, Oracle revisa la información del Clustering Factor del índice, el cuál le dice a Oracle el número de bloques que deben ser leídos para conseguir los datos necesarios por la condición de la query.

Evidentemente podemos ver que con un clustering factor bueno, reducimos el número de I/O lógicas requeridas.

Algo importante a tener en cuenta es que no vamos a reducir el clustering factor llevando a cabo un rebuild del índice, ya que el clustereing factor está asociado con la ordenación de los datos dentro de la tabla y no del índice. La única forma de cambiar esto es cambiar el índice o el orden de la tabla.

La siguiente query es un ejemplo de como podemos obtener el clustering factor, entre otros valores, del índice dado:

SELECT a.index_name, b.num_rows, b.blocks, a.clustering_factor
FROM dba_indexes a, dba_tables b
WHERE a.index_name = ‘nombre_indice’
AND a.table_name = b.table_name ;

4 Comments

  • Pingback: Clustering Factor « DbRunas – Noticias y Recursos sobre Bases de Datos

  • Ricardo Calderón

    12/04/2013

    Gracias por la explicación .. breve pero muy clara!. Una duda, si tenemos una tabla con 100 millones de registros con índice generado en un campo con valores únicos. Si borramos los primeros 20 millones registros de la tabla, el árbol o ‘btree’ queda desbalanceado? realmente es necesario el ‘rebuild index’ o de manera automática Oracle reorganiza la tabla ?

    Gracias, saludos!

    Reply
    • moikmeg

      17/04/2013

      Hola Ricardo,

      una de las cuestiones que más nos hacemos es cuándo realizar un rebuild index, algo que no se aconseja salvo que sea necesario. Pienso que los B-Tree Index se balancean automáticamente, pero lo mejor es que observes el Clustering Factor como indico en la entrada del blog.

      Por mi experiencia yo no suelo realizar rebuild de índices, salvo cuando se ejecutan algunos procesos que me suelen dejar el índice con un b-level de 3 o mayor de 3. Con la siguiente sentencia puedes ver el b-level y clustering-factor de tus índices:

      SELECT owner,table_name,index_name, blevel,
      decode(blevel,0,’OK BLEVEL’,1,’OK BLEVEL’,2,
      ‘OK BLEVEL’,3,’OK BLEVEL’,4,’OK BLEVEL’,’BLEVEL HIGH’) OK,
      clustering_factor
      FROM dba_indexes
      order by 4,1
      /

      Reply
  • Ricardo Calderón

    19/04/2013

    Muchas gracias Moises..saludos!

    Reply

Deja un comentario