You are hereDinamica de Indices en Oracle - Parte 2

Dinamica de Indices en Oracle - Parte 2


By IgnacioRuiz - Posted on 31 October 2008

Si deseas ver los antecedentes, visita Dinamica de Indices en Oracle - Parte 1

If you want to see this post in english, go to Index Dynamics - Part II

Lo prometido es deuda, hoy compartire con ustedes los resultados preliminares de mis observaciones a 4 indices en ambiente productivo.

Comencemos con una grafica del Espacio Usado, tal y como lo reporta la columna PCT_USED de la tabla INDEX_STATS (datos obtenidos inmediatamente despues de ejecutar un ANALYZE sobre el indice). Este porcentaje indica la cantidad de espacio asignada al B-Tree que es utilizada.

Apreciamos en la grafica, una linea por cada indice considerado, notemos que en la leyenda de la grafica aparece el numero del indice con el dato de numero de columnas dentro de parentesis.

Que puede ser observado en esta grafica?
1) Despues de reconstruir el indice (hecho esto el Sabado), cada indice inicia con 95% de espacio utilizado.
2) El primer dia es Domingo y el sistema tuvo "casi" nula actividad; de ahi que el uso de espacio muestre ligera variación.
3) La actividad transaccional comenzó el Lunes. A partir de ahi el INDEX1 reporta datos erronoeos para PCT_USED y los otros indices comenzaron su tendencia a "decaer".
4) Despues de una semana completa de actividad, los indices ganaron espacio libre; algunos mas rápido que otros (por ejmplo INDEX4 paso del 95% al 84% en espacio usado, eso es 11% en solo 5 dias).

El punto 3 motivo a levantar un requerimiento de servicio con Oracle.
El punto 4 puede ser explicado en terminos de:
a) Transaccionalidad de la Tabla (que tantas inserciones/actualizaciones/borrados tuvo).
b) El tipo de indice, es decir si es UNIQUE o NOT UNIQUE.
c) Numero de columnas que conforman el indice.
d) El tipo de cada columna indexada.

Voy a proponer la siguiente hipótesis: el ritmo de "decadencia" de un indice es directamente proporcional a la transaccionalidad de la tabla, al número de columnas y el tipo de ellas, e inversamente proporcional al tipo de indice y el tamaño de bloque.

Como ustedes saben, los indices tipo B-Tree poseen dos tipos de nodos, llamados Ramas (Branches) y Hojas (Leafs).

Veamos ahora en donde es donde se asigna el espacio, si en las "hojas" o en las "ramas".

La grafica a continuación nos permite ver el incremento o delta en porcentaje para los bloques "hoja", considerando muestreos diarios de la columna LF_BLKS de la tabla INDEX_STATS.

Observen el gran ahorro en espacio asignado a bloques hojas resultado de reconstruir el indices; sin embargo, los ahorros se desvanecen lentamente en los dias subsecuentes.

La grafica a continuación hace un acercamiento, para poder observar con detalle el ritmo de variación experimentado durante esos dias.

Tengamos presente el ritmo al cual estan incrementandose el numero de bloques hoja, posteriormente veremos como se relaciona con el incremento o de llaves (entradas del indice).

¿Que pasa con los bloques "rama"? ... eso es precisamente lo que veremos en la siguiente gráfica: el comportamiento de variación del numero de bloques rama (branch) en esos indices. Para estos datos, tome el valor de BR_BLKS muestreado diariamente y lo comparé contra el valor del día anterior.

Observen por favor, el incremento pronunciado que presentan los indices INDEX2 e INDEX4, es decir que durante el primer dia de actividad el numero de bloques "rama" casi se duplicó, evidenciando una intensa reorganización del indice. Esto podría ser causado por la naturaleza de estos indices (todos son UNIQUE) y/o por el alto ritmo de transacciones.

Para el indice INDEX3, el incremento se divide en dos dias, Domingo y Lunes. Esto es porque la tabla presentó actividad al dia siguiente que la reconstrucción de indices fue realizada (probablemente un proceso batch).

Tendremos que poner el analisis sobre INDEX4 en pausa, ya que sus numeros no son confiables.

¿Porque se manifiesta un incremento mucho mayor en el número de bloques rama? Esta pregunta puede responderse regresando al antecedente que tenemos de inicio: los indices fueron reconstruidos al 95% de espacio utilizado, esto es 5% de espacio libre. Ese margen es muy pequeño para los bloques hoja de un indice, y la probabilidad de observar divisiones se incrementan aun mas, considerando que el indice es UNIQUE. Recordemos tambien que la división de un bloque hoja(leaf), puede impliar la división de un bloque rama (branch).

Nuestras conclusiones parciales pueden recapitularse asi:
1) Dependiendo del porcentaje de espacio libre, el estado del indice es menos estable despues de la reconstrucción.
2) Los Indices tienden a tomar una forma "estable", con el paso del tiempo.
3) Los bloques "rama"(branch) son aparentemente la parte mas estresada del B-Tree, posterior a la reconstrucción.

La próxima y última entrega sobre este tema (abarcando datos finales, conclusiones y eventualmente el modelo matemático para el ritmo de "decadencia" para indices) la publicaré el próximo Martes.

Les agradezco mucho su atención, Saludos!!!

Si deseas ir a la primera parte del articulo, visita Dinamica de Indices en Oracle - Parte 1 o ver el siguiente articulo de la serieDinamica de Indices en Oracle - Parte III


Visita mi pagina en Oracle Community
Visita mi blog en Blogger

Suscripcion a Contenido Sindicado(RSS)

Suscribir a Databases Hispamerica por Email



Distribuir

Distribuir contenido

Follow DatabasesLA on Twitter

En línea

En este momento hay 0 usuarios y %count invitados en línea.

Estadisticas

Locations of visitors to this page

hidden hit counter