« Como cambiar un dominio Weblogic de Development mode to Production Mode y sus diferencias (Weblogic)Fusion Middleware 11g : Oracle Content Server no disponible »

¿Reconstruir o no un índice? (rebuild or not rebuild an index?)



Index Rebuild ¿es necesario?



Leyendo un artículo de Oracle sobre la reconstrucción de los índices , indica que rara vez es necesario hacer un rebuild de los índices, es más ... indica que la política de reconstruir índices está muy "embebida" en los DBAs y a veces reconstruyen sin siquiera haber realizado un pequeño análisis estadisticos del índice.

¿Por qué no se debiese reconstruir un índice?
Pues simplemente porque un índice de B*Tree es en sí una estructura que se auto-balancea y que se auto-mantiene por sí misma.

Por ejemplo siempre escuchamos que las DMLs dejan "orificios" en el índice que no son llenados y desbalancean el índice.

Pues eso no es tan así, pues cada vez que se produce un borrado de datos, se genera un leaf node vacío, el cual será sí o sí reutilizado.

¿Cuáles son las mayores justificaciones para hacer un rebuild a un índice?

  • Fragmentación del índice
  • Crecimiento del índice y su espacio "borrado" no es reutilizado
  • Factor de clustering del índice está fuera de sincronización

    En muchos de los casos , se mantiene el balanceo y sin fragmentación , debido a que las entradas (leafs) son reusadas.

    Las DMLs resultan en un slot libre que pueda estar alrededor de un bloque de índice. Pero estos "espacios libres" tipicamente son rellenados

    El índice de clusterización refleja como los datos en la tabla son ordenados respecto a su
    llave de indexación.

    La reconstrucción de un índice nunca va a influenciar en el factor de clustering, para esto se debiese llevar a cabo una reorganización de la tabla



    ¿Cuáles son los costos de reconstruir un índice?

    Pues son muchos y por ello se debiesen tener en cuenta los siguientes aspectos

    1.- Casi todos los scripts dependen de los datos de la tabla INDEX_STATS, la cual se carga con el comando

    ANALYZE INDEX ... VALIDATE STRUCTURE;

    El problema de este comando es que deja la tabla en un modo de bloqueo exclusivo, mientras se analiza el índice. Para índices muy grandes esto puede ser dramático, pues cualquier DML sobre la tabla en el período de análisis, no va a poder ser llevado a cabo.


    2.- La actividad de redo y la performance en generar se ven afectadas como resultado directo de la reconstrucción del índice.

    Cada vez que se realiza una DML sobre un índice, este índice va evolucionando ya sea por los splits que se van produciendo como por el crecimiento mismo del índice.
    Mientras el índice es reconstruído, es empaquetado y comprimido, cada bloque con los leaf nodes es reorganizado, sin embargo , con las DMLs que se están produciendo este reordenamiento afectan al empaquetamiento que tiene el índice por la reconstrucción del mismo.

    Todo lo anterior redunda en que hay muchísima más actividad de REDO, el hecho de que se produzcan splits produce que haya más I/O y uso de CPU .


    3.- Un INDEX COALESCE es el comando preferido en vez de la reconstrucción, pues posee las siguientes ventajas

  • No requiere 2 veces el tamaño del índice en Storage
  • Siempre es online
  • No reestructura el índice, pero trata de recombinar de la mejor forma los bloques donde se encuentran los leaf nodes (datos), esto evita por ejemplo el overhead del punto 2

    Todo lo anterior , es para indicar que no es recomendable colocar como política corporativa la reconstrucción de índice y que se debe hacer en casos muy excepcionales


    ¿Qué es un Index Block Split?
    Es un evento que sucede cuando un bloque de datos de índices no puede contener más información, lo que debe hacer es migrar toda esa info a bloques nuevos, y dejar en el bloque original los punteros de esos bloques, eso implica que se produce un nuevo nivel dentro del índice.

  • by Ligarius
    23.06.12. 22:42:59. 648 words, 16267 views. Categories: Base de datos, Oracle 11g, Oracle 10g, Oracle11gR2 ,