Analisis de BD diario

[MiToNiOeS]

Hola, no soy DBA pero estoy a cargo de un sistema importante (en tamaño) de datos y hay cosas en las que CREO que el DBA se esta equivocando...

A ver, tenemos una BD con unas 200 tablas, la mayoria de ellas son pequeñas (digamos menos de 10000 registros) y luego hay unas 30 o 40 tablas que tienen entre 10.000 y 50.000.000 registros que tienen la mas grande.

Bien, resulta que tenemos un analisis completo de la BD programado para que se ejecute cada noche, ademas tenemos varios procedimientos pl/sql que se ejecutan de noche para aplicaciones en concreto. El problema es que entre analisis y ejecucion de procedimientos se alarga este procesamiento de noche hasta media mañana del dia siguien (con la consecuencia de que la BD va lenta mientras tanto y lo que es mas importante, algunas aplicaciones no funcionan correctamente hasta que no terminan de ejecutarse los pl/sql)

Mi pregunta es, es necesario un analisis completo CADA NOCHE??, no seria mejor un analisis por estimacion?? que porcentaje deberiamos usar??, incluso no seria mejor un analisis cada un tiempo??, una semana por ejemplo...

PD: La BD usada es oracle 9i (en otro sistema tenemos la oracle 10 que lleva el auto analisis y se encarga solo de estas cosas...)

[matanga]

Hola,

Necesario, no. La realidad es que periodicidad y tipo de estadisticas te las tendria que dar tu proveedor de la aplicacion, dado que eso es una politica que se adopta al momento de construir y diseñar las consultas a la base de datos.

Si no tienes esa informacion, generalmente lo mejor es tomar estadisticas por porcentajes, por ejemplo la opcion DBMS_STATS.AUTO_SAMPLE_SIZE para la captura de estadisticas de un esquema, donde Oracle decide cual es la mejor opcion en % ademas de ser variable en cada ejecucion.

Tambien existe la opcion de tomar estadisticas de un esquema completo, DBMS_STATS.GATHER_SCHEMA_STATS, generalmente la mas facil dado que con una sola linea de codigo tengo hecho todo el trabajo, pero muchas veces las tablas no cambian o lo hacen muy poco, en estos casos es mejor optar por analizar las tablas e indices con mayor cantidad de cambios en bloques, DBMS_STATS.GATHER_TABLE_STATS.

Por otro lado esta la necesidad de histogramas, estadisticas para columnas, no todas las columnas tienen la necesidad de ser analizadas, pero muchas veces se utiliza la opcion FOR ALL COLUMNS en vez de FOR ALL INDEXED COLUMNS.

En fin, para cambiar el modelo de captura de estadisticas, y cuando no tengo idea del impacto que va a tener, lo que hago es utilizar PERFSTATS, esto me permite ir sacando fotos del rendimiento de la base de datos en el tiempo y asi determino si fui para peor o mejor.

Saludos

[kikolice]

Iniciado por MiToNiOeS

tenemos un analisis completo de la BD programado para que se ejecute cada noche, ademas tenemos varios procedimientos pl/sql que se ejecutan de noche para aplicaciones en concreto. El problema es que entre analisis y ejecucion de procedimientos se alarga este procesamiento de noche hasta media mañana del dia siguien (con la consecuencia de que la BD va lenta mientras tanto y lo que es mas importante, algunas aplicaciones no funcionan correctamente hasta que no terminan de ejecutarse los pl/sql)

de entrada lo que haria es ver que de las dos cosas es la que se esta tardando, el analisis o los procesos, si es el analisis checa lo que te dice matanga, pero si son los procedimientos igual ya no va tanto por el lado del DBA si no de los desarrolladores, en mi experiencia, un pl el 99% de las veces se tarda por DMLs (select, insert, delete, update) mal generados, checate los planes de ejecucion de esos DMLs para bajarles los tiempos

[MiToNiOeS]

esta noche hemos desactivado el analisis y hemos ejecutado solo los pl/sql, ha terminado antes que los dias anteriores pero no ha sido mucho antes. Estoy trabajando en un nuevo metodo de hacer los calculos que hacemos en estos pl/sql y esperamos mejorar los tiempos, ya os contare...