You are hereCariño, encogi los indices

Cariño, encogi los indices


By OracleDisected - Posted on 19 April 2008

Introduccion

Oracle provee un caracteristica a partir de la version 8i, que puede proporcionar ahorro en uso de storage y disminucion de IO. ¿Has escuchado hablar de la "compresion de indices"? Bueno, en este articulo abordaremos una descripcion de esta caracteristica, resultados practicos, recomendaciones y metodologia de implementacion.

A pesar de las optimizacion de administracion de storage que provee Oracle 10g, siempre hay una ganancia resultante de mantener las estructuras de indices. Si tu realizas periodicamente una revision de indices y mantenimiento de los mismos, entonces eres un buen DBA... por el contrario, ste recomiendo que le pongas cuidado de ahora en adelante.

Adicional a las ganancias por la reconstruccion o defragmentacion de indices, puedes considerar el comprimir algunos muy bien seleccionados candidatos, para los cuales el ahorro de espacio y el costo en IO, compense el ligero(?) incremento de trabajo en CPU que causa. Escribo un signo de interrogacion despues de "ligero", ya que trataremos de estimar ese costo en el corto plazo.

Propongo las siguientes preguntas de inicio:
* ¿Como se usa la compresion de indices?
* ¿Cuales son los resultados a primera vista?
* ¿Como escoger los mejores candidatos para la compresion?
* ¿Compresion de Indices: ¿es buena, mala ... o ambas?
* ¿Cual es el costo beneficio posterior a la compresion?
* ¿Cuales son los resultados "internos" o como analizar el efecto en las consultas y procesos actuales?

Si tienes mas preguntas, por favor ten la confianza de ingresarla en un comentario, y nosotros (ustedes y yo) trataremos de abordarla y proveer una respuesta satisfactoria.

¿Como se usa la compresion de indices?
Hay dos formas de utilizarla:

1) borra el indice (DROP) y crealo de nuevo con COMPRESS
2) reconstruye (REBUILD) el indice con COMPRESS

Vamos a utilizar el segundo metodo, con este enorme indice que tengo en una base de datos de pruebas (10.2.0.3 en HPUx11i). Estas son los datos iniciales del indice:

TABLE_ROWS   TABLE_BLOCKS   INDEX_BLOCKS   INDEX_BYTES    BLEVEL  LEAF_BLOCKS
----------   ------------   ------------  -------------   ------  -----------
7,331,706        459,210        155,648  1,275,068,416        3      149,394

Ahora que tenemos nuestra linea base, es tiempo de utilizar la sentencia DDL que reorganizara el indice:

SQL> ALTER INDEX idx_big_comp_test REBUILD COMPRESS 2;

Index Rebuild

Despues del comando anterior, el almacenamiento utilizado por el indice es el siguiente:

TABLE_ROWS   TABLE_BLOCKS   INDEX_BLOCKS   INDEX_BYTES    BLEVEL  LEAF_BLOCKS
----------   ------------   ------------  -------------   ------  -----------
7,331,706        459,210        139,904   1,146,093,568        3     133,682


Una comparacion rapida arroja que se requirieron menos bloques, contabilizando un 10.5% de ahorro en espacio.

Ahora permitamosle a nuestra imaginacion volar un poco... estamos mostrandole a nuestro supervisor la manera de extender la fecha funesta en que se agote nuestro storage, pavimentando el camino para un muy bien ganado aumento de sueldo, derivado del ahorro por compra de almacenamiento secundario... regresemos a la realidad: en esta vida todo tiene un precio, por ahora no te apresures a comprimir todo indice que encuentres en tus bases de datos, hasta que hablemos de los pros y los contras, y aprendamos como escoger buenos candidatos para la compresion.

Espera la siguient entrega: Como escoger los mejores candidatos para la compresion


Visita mi pagina en Oracle Community
Visita mi blog en Blogger

Suscripcion a Contenido Sindicado(RSS)

Suscribir a Databases Hispamerica por Email



Syndicate

Syndicate content

Follow DatabasesLA on Twitter

Who's online

There are currently 0 users and 5 guests online.

Estadisticas

Locations of visitors to this page

hidden hit counter