You are hereOracle / Index Rebuild vs Coalesce vs Shrink Space - (3 animales distintos)

Index Rebuild vs Coalesce vs Shrink Space - (3 animales distintos)


By admin - Posted on 07 September 2010

Autor: Richard Foote
Translated from the English original

Previamente, discutí cómo un ALTER INDEX ... COALESCE va a ser menos costoso en términos de usar recursos que un ALTER INDEX ... SHRINK SPACE COMPACT (o ALTER INDEX ... SHRINK SPACE) pues el COALESCE no tiene que preocuparse él mismo de asegurar que todos los bloques hoja en el extremo físico del segmento del índice se han movido para permitir que el almacenamiento sea des-asignado del segmento del índice. Si simplemente quiere desfragmentar un índice y no necesariamente reducir el espacio total asignado al segmento, utilice COALESCE en vez de las opciones de SHRINK es más barato/usa menos recursos.

¿Pero qué hay sobre un ALTER INDEX ... REBUILD? ¿Cuando, si acaso, debe ser utilizado?

Bueno la respuesta es como con la mayoría de las temas Oracle: depende.

Escenario Uno

Tenemos una tabla y la aplicación borra o elimina datos históricos pero de forma tal que los bloques hoja no se están vaciando por completo. Básicamente, se elimina la información más vieja, pero se borra en un patrón aleatorio, de aproximadamente el 10% "inicial" de la tabla. El índice esta en secuencia, lo que significa que solamente aquellos bloques hoja en el 10% del "extremo izquierdo" de la estructura del índice son afectados pero todo este espacio de los datos suprimidos es "madera muerta" pues las nuevas entradas de índice se están insertando solamente en el "extremo derecho" del índice.

Observe que básicamente el 90% del índice está utilizado muy bien, y que solamente el 10% del índice es problemático. Del problema el 10% de los bloques hoja, hay un montón de espacio libre o suprimido, con muchos bloques hoja casi vacios.

COALESCE (asi como SHRINK) básicamente recorreran a través del 10% de bloques hoja fragmentados y combinarán las entradas de fila del índice en tan pocos bloques hoja como sea posible. Con el 90% de los bloques que están muy bien, COALESCE básicamente los leerá e ignorará para cualquier proceso pues no hay nada que hacer por ellos.

REBUILD por otro lado, tomará una estrategia completamente distinta. Leerá (y así es como generalmente lo hace) toda la estructura existente del indice y construirá un nuevo y reluciente segmento de índice. Como parte de este proceso, reconstruirá el índice entero, no tiene ninguna opción (si se asume que el índice no esta particionado, pero ésa es otra historia) y reconstruirá el 90% del índice que esta de hecho perfecto, para comenzar. Reconstruir el 90% de algo que no necesita reconstrucción no suena eficiente y de hecho no lo es. Consecuentemente, la reconstrucción del índice utilizará substancialmente más recursos y generara substancialmente más redo el equivalente COALESCE (o SHRINK Space).

Escenario Dos

Tenemos una aplicación que elimina datos de una tabla y tambien suprime datos a través de la estructura de índice entero. El borrado es significativo con una proporción substancial de las filas totales siendo suprimidas. Adicionalmente, la tabla no va a ser repoblada con el mismo volumen de datos o no sera alimentada por un periodo sustancial de tiempo. Como tal, todo este espacio suprimido del índice es "madera muerta" pues no va a ser utilizado pronto, si es que llegara a serlo.

Ahora típicamente en esta clase de escenario, es por supuesto la tabla tanto como los índices asociados que necesitan ser reconstruidos. Esto es un punto clave. Sin embargo, las exploraciones completas de la tabla (Full Table Scans) no son quizá una problema para esta tabla así que el espacio perdido en la tabla no es una situación de urgencia. Quizá la tabla no esta en un tablespace ASSM o en una base de datos que soporte un comando Shrink de la tabla y quizá mover la tabla no es una opción inmediata debido a consideraciones de disponibilidad. Sin embargo, cualquiera sea la razón (o falta de ella), en este caso el índice necesita ser defragmentado.

Notemos que es el índice completo el que es problemático aquí y que podría haber porciones del índice que tienen muy pocas entradas de índice remanentes.

Ahora el desdichado COALESCE (y por lo tanto el SHRINK) tienen un pequeño problema aquí. Ambos combinan entradas de índice a partir de dos bloques en un bloque destino, donde puede hacerlo. Sin embargo, si los bloques hoja están realmente vacíos, estas entradas de índice combinadas se pueden combinar alternadamente y mover otra vez con las entradas de índice a un tercer bloque hoja. Y quizá aún otra vez con otro bloque hoja. Y así sucesivamente… así que una entrada de índice en particular, de hecho se podría trasladar repetidas veces a varios bloques hoja durante todo el proceso. Cada uno de éstos movimientos requiere recursos, genera actividad en redo logs y tarda tiempo.

Veamos la reconstrucción (Rebuild), la cual tiene un comportamiento distinto. Según lo mencionado, básicamente leerá (generalmente lo hace) toda la estructura del índice existente y construirá una estructura totalmente nueva, pero es importante remarcar que solo tendra que localizar las entradas específico del índice una vez, y solo una vez. También, pues es la estructura de todo el índice la que es problemática, que no hay problema con arreglar el índice completo, pues "ya no es funcional".

Como resultado de tener que ocuparse solamente de una entrada de índice existente una vez, versus el COALESCE que puede volver a poner una entrada de índice específico muchas veces, la reconstrucción del índice va a ser substancialmente más eficiente y potencialmente utiliza significativamente usará menos recursos y generará menos actividad de redo.

Esta representación de las diferencias entre COALESCE, SHRINK SPACE and REBUIL pretende señalar cuando una es superior que las otras.

Básicamente, COALESCE es particularmente eficiente y utiliza menos recursos cuando el porcentaje de la estructura de índice total que es problemática y hecha fragmentos es relativamente pequeño (aproximadamente por debajo del 20-25% de bloques hoja). La reconstrucción (REBUILD) es particularmente eficiente cuando el porcentaje de la estructura de índice total que es problemática y fragmentada es relativamente grande y el grado de fragmentación dentro de un bloque de la hoja del índice es relativamente alto.

Para releases anteriores a Oracle 10g, un índice requiere tener por lo menos espacio libre del 50% menos pctfree en los bloques hoja vecinos para que un Coalesce sea eficaz.

Ahora Rebuild/la reconstrucción (y la reconstrucción en línea) potencialmente tienen implicaciones de bloqueo que necesitan ser consideradas aunque como veremos más adelante, 11g haya resuelto algunas de estas dificultades…

Texto Original: Index Rebuild vs. Coalesce vs. Shrink Space (Pigs – 3 Different Ones)

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 1 guest online.

Estadisticas

Locations of visitors to this page

hidden hit counter