Un poco de todo

Hola a todos. Hace ya unas cuantas semansa que no escribía nada pero es que con el calor que hace en Zaragoza da mucha pereza escribir. 

Hoy voy a hablaros un poco de esas situaciones en donde inexplicablemente no sabemos porque está actuando un índice sobre una consulta.

1.- Se devuelven muchos registros.

Aquí está la eterna pelea en cual es el límite en donde el índice deja de funcionar. En algunos libros se fija en el 5%, otros en el 10% y en algunas de las pruebas realizadas en mis clases de Administración de bases de datos se situaba en el 31%.

2.- Conversiones de datos implícitas.

A veces nos encontramos con algunas consultas que llevan implícitas algún tipo de conversión. 

3.- No hay estadísticas.

El optimizador de la base de datos construye un plan de ejecución basado enteramente en estadísticas de los objetos, almacenadas en el dicionario de datos. La recolección de estas estadísticas debe realizarse periódicamente para que Oracle sepa cuales son los costos asociados a cada método de acceso a los registros, y de esta manera elegir la mejor opción. Al insertar y eliminar datos frecuentemente, cambian las estadísticas quedan obsoletas, y esto puede traer aparejado un impacto directo en la performance de las consultas.

Pueden recolectarse estadísticas de todo el esquema, de una tabla, de un índice, del sistema. El paquete DBMS_STATS contiene procedimientos para hacer el trabajo: GATHER_TABLE_STATS, GATHER_INDEX_STATS, GATHER_SCHEMA_STATS.
Para saber si una tabla tiene estadísticas, puede utilizarse la siguiente consulta:

SELECT last_analyzed
FROM user_tables
WHERE table_name = ‘mi_tabla’;

Retorna la fecha de la ultima recolección. Si retorna NULL, entonces nunca fueron recolectadas.

Oracle dispone de una herramienta (Explain plan) que permite al administrador de la base de datos comprobar como se ejecutará una determinada consulta, es decir, podemos saber, por ejemplo, si se accederá al índice de una determinada tabla o por el contrario se recorrerá la tabla entera. 

Esta es la sintaxis general: EXPLAIN PLAN [SET STATEMENT_ID = ‘text’] FOR sentencia; Ejemplo:
DELETE PLAN_TABLE;
EXPLAIN PLAN FOR SELECT * FROM T_PEDIDOS WHERE CODPEDIDO = 5;

Para ver el resultado:
SELECT
SUBSTR(LPAD’ ‘, LEVEL-1) || OPERATION || ‘ (’ || OPTIONS || ‘)’,1,30 ) "OPERACION",
OBJECT_NAME "OBJETO"
FROM PLAN_TABLE
START WITH ID = 0
CONNECT BY PRIOR ID=PARENT_ID;

Sobre todo hay que evitar búsquedas del tipo FULL TABLE SCAN.

El miércoles pasado terminó la asígnatura de administración de bases de datos. Ha sido un cuatrimestre muy bueno y estoy muy contento de lo aprendido en la asignatura. La parte de performance se me ha hecho un tanto dura pero la de PL/SQL más cercana al mundo de la programación ha colmado todas mis espectativas iniciales con la asignatura.

Tengo que dar las gracias a mi profesor, Jorge LLoret, por ayudarme en todo momento y por mostrarme una parte de las bases de datos hasta el momento un tanto desconocida para mi.

Por cierto, la nota, un gran gran 9.5. Podría optar a la matrícula pero me coincide el mismo día que otro examen. Mmm, ya veré. 

Hace unos días escribí tanto en este blog como en la comunidad de oracle en ning sobre mis vivencias con los índices. Aquí os dejo el enlace con las respuestas de algunos compañeros en la comunidad.

Os recomiendo que si os interesa Oracle no dudéis un segundo en formar parte de esta comunidad.

Indexes and I en Oracle Community 

El otro día en clase (llamarle clase siendo que soy el único que va a clase) estábamos Jorge Lloret (mi profesor) y yo corrigiendo unos ejercicios sobre costes. Me encontré con un problema curioso. Los resultados que obtenía con una tabla similar a la de mi profesor eran anómalos. Los índices actuaban cuando les daba la gana y daban costes imposibles. Bueno, pero el tema de la posesión infernal de mi ordenador lo dejaremos para otro día. Lo que sí que quería comentar es una cosa curiosa que comprobamos. Estamos siguiendo el libro Oracle High Performance tuning for 9i and 10g. En él, el autor, nos indica que los índices actúan sólo cuando el resultado está alrededor del 10% de las filas de la tabla. Bien, decidimos crear una tabla con 100000 filas. Una de las columnas con el nombre número iba del 1 al 100.000. Bien, creamos un índice en la columna número y realizamos la consulta: SELECT * FROM tabla WHERE numero < 10000. Bien, comprobamos el coste y vimos que el índice había actuado. Todo correcto hasta aquí. Ahora tocaba ver como con un resultado mayor al 10% no entraban en juego los índices. Probamos < 15000 ups, funciona, probamos < 20000 ups, funciona… así hasta <31250 ups, el índice actuaba hasta el 31%. ¿cómo podía ser? ¿el autor del libro se equivocó al determinar ese 10%? Bueno, siguiente idea que se nos pasó por la cabeza, si ha llegado al 31% con < 31250, con >70000 también tendría que actuar el índice, no? pues… no. Así sólo actuaba con >85000 un 15% y más aproximado a lo que ponía el libro. Entonces… ¿dónde está el límite? ¿por qué si empezamos por delante o por detrás son valores distintos??? Lo que decía, los índices y yo, esa gran tragedia.