You are hereCariño, encogi los indices - Parte 2

Cariño, encogi los indices - Parte 2


By OracleDisected - Posted on 27 April 2008

Como escoger a los candidatos perfectos

Cuidado: la compresión de los indices puede afectar adversamente los planes de ejecución y degradar el performance, le recomendamos que efectue estas pruebas en un ambiente de replica o pruebas, y verifique el comportamiento de las consultas SQL y el código PL/SQL.

No todos los indices pueden ser comprimidos, pues algunas veces la reduccion de espacio obtenida al comprimirlos no amerita el trabajo extra que implican los procesos de compresion/descompresion. Pero ¿Como sabemos eso por anticipado?

Permitanme sugerirles dos aproximaciones al tema:
1) Orientado al tamaño
2) Orientado a la frecuencia de acceso

Orientado al Tamaño

Comencemos con la propuesta de selección de acuerdo al tamaño, diciendo: mientras mas gordo es el elefante, mejores los resultados cuando lo pongamos a dieta.

He usado un script como el siguiente para obtener una lista de candidatos a comprimir:

SELECT
substr(segment_name,1,20) as index_name,
bytes, blocks, extents
FROM  dba_segments
WHERE owner = '{write here the owner}'
AND   segment_type = 'INDEX'
AND   extents > 63            <---esto se puede modificar
ORDER BY bytes DESC; 

Despues de ejecutar el script anterior, obtendrán un listado como el siguiente:

INDEX NAME                BYTES     BLOCKS    EXTENTS                         
-------------------- ---------- ---------- ----------                         
PROD_NAME_IX             524288         64          8                         
PRD_DESC_PK              327680         40          5                         
SYS_C009603              131072         16          2                         
SYS_C009607               65536          8          1                         
SYS_C009606               65536          8          1                         
ACTION_TABLE_MEMBERS      65536          8          1                         
LINEITEM_TABLE_MEMBE      65536          8          1                         
SYS_C009602               65536          8          1                         

Ahora tendremos que estimar el mejor porcentaje de compresion para los indices seleccionados, y existe una caracteristica de Oracle bastante precisa para hacerlo: la sentencia ANALYZE.

A pesar del hecho de que analizar las tablas u objetos, se le ha separado el proposito de la generacion de estadisticas (uno de sus propositos), podemos usar esta sentencia para verificar la estructura de indices y tablas.

El siguiente comando y una sencilla consulta a la tabla INDEX_STAT nos mostrara si el indice es buen candidato, que nivel de compresion esoger y la reduccion de espacio esperada.

SQL> ANALYZE INDEX owner.index_name VALIDATE STRUCTURE OFFLINE;

Index Analyzed

SQL> SELECT name, height, blocks, OPT_CMPR_COUNT, OPT_CMPR_PCTSAVE
FROM index_stats
WHERE name = '{index_name}';

El valor resultante OPT_CMPR_COUNT es el valor que le debemos pasar en la clausula COMPRESS {n}, y OPT_CMPR_PCTSAVE es el porcentaje de compresion "esperado" para ese valor. Todos los demas valores obtenidos de INDEX_STATS son numeros actuales.

Entonces sus sentencias DDL se podran ver similares a las siguientes:

SQL> ALTER INDEX owner.index_name REBUILD COMPRESS {value from OPT_CMPR_COUNT}

or

SQL> CREATE INDEX owner.index_name ON {table_index_clause}
2:   TABLESPACE {Tablespace Name}
3:   COMPRESS {value from OPT_CMPR_COUNT}
4:   {other storage clauses};

Segunda propuesta: Frecuencia de Acceso

Para este enfoque vamos a necesitar la ayuda de dos vistas muy importantes: V$SEGSTAT(9i and up) y ALL_OBJECTS. Requerimos consultar V$SEGSTAT ya que esta vista dinamica muestra estadisticas muy valiosas sobre lecturas/escrituras, tanto físicas como lógicas.

El script que les muestro a continuación les puede ayudar para obtener los objetos mas accesados de un esquema.

SELECT a.object_name, b.statistic_name, b.value
FROM all_objects a, v$segstat b
WHERE  a.object_id = b.obj#
AND  a.owner = '{your schema owner here}'
AND  a.object_type = 'INDEX'
AND  b.statistic_name = 'physical reads'  <-- You may change this for physical reads direct
ORDER by b.value desc 

De la ejecucion del script, obtendran una lista de candidatos para compresion, ahora lo que tienen que hacer es aplicar ANALYZE y consultar INDEX_STATS para ver si las proyecciones de compresión 'pueden' corresponder a menor actividad de E/S.

Esperen la próxima entrega de esta serie: Compresión de Indices: ¿Es buena o mala? ¿Cómo medimos los efectos?


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