Cita: - Por un lado, el SP sigue borrando los registros, pero las metricas resultantes no se graban en el archivo de log.
Sin conocer los detalles del Procedure, se me ocurren dos motivos para que no se escriba en el fichero de log:
1. Un error en la lógica del Procedure, como por ejemplo, condiciones en el algoritmo (valor de un contador, false de un if, etc) por las que se decida no escribir en el log, o bien, ejecuciones paralelas del procedimiento que produzcan un borrado del fichero (fopen con open_mode 'W' en vez de 'A'). Si este es el caso, con un debug o con una traza (dbms_output) deberías poder identificar el problema.
2. Un error en la gestión de excepciones, es decir, que en algún momento el paquete UTL_FILE esté devolviendo una excepción al hacer FOPEN, FCLOSE, PUT_LINE, etc. y el procedimiento no lo informe correctamente, por ejemplo:
Código:
begin
utl_file.fopen();
utl_file.put_line();
utl_file.fclose();
exception
when others then
null;
end;
El paquete UTL_FILE tiene una colección muy completa de excepciones, por lo tanto, si no se produce ninguna excepción y además estás seguro del algoritmo, lo más probable es que sea un error del sistema operativo.
Cita: - Por otro lado, luego de algunas horas, el borrado se va haciendo más lento, como si algo obstruyera el proceso.
Esto lo puedes analizar en dos partes, por un lado, la operación de escritura en el fichero log que se produce fuera de la base de datos, y por otro lado, el resto de las operaciones del procedure que se producen dentro de la base de datos.
1. En el primer caso, los motivos más comunes de UTL_FILE donde se incrementa la lentitud durante la ejecución de un proceso son:
1.1. El modo Append, ya que el tamaño del fichero se van incrementando, y hace más costosa la operación de I/O para abrir el fichero y agregar una línea nueva.
1.2. La frecuencia de FOPEN y FCLOSE, por ejemplo, dentro de un loop, por cada FOPEN se crea un puntero (handle) en la cache de la base de datos y en la cache del sistema operativo, que en teoría, ambos se destruyen con FCLOSE, pero Oracle no garantiza funcionamiento del filesystem, y es posible tener una pérdida o diferencia de rendimiento en repetidas operaciones de I/O con ntfs y no con ext4.
1.3. La frecuencia de PUT_LINE, al igual que FOPEN y FCLOSE, el rendimiento depende el filesystem, y aunque es cómodo ejecutar el PUT_LINE por cada línea del fichero log, lo más óptimo es ejecutar el PUT_LINE por cada 32k de datos (límite del buffer), es decir, concatenar las líneas hasta el límite del buffer y después escribir en el fichero.
2. En el segundo caso, cuando un procedimiento se ejecuta durante mucho tiempo o se ejecuta con mucha frecuencia, es normal que se produzcan variaciones en el rendimiento, y teniendo en cuenta que pueden ser por diferentes motivos (locks, waits, memoria, hardware, sql, etc, etc), analizar el plan de ejecución de las consultas no es suficiente, tienes que utilizar herramientas de monitoreo mas avanzadas, como por ejemplo Statspack (a partir de 8.1.6) que permite tomar fotos (snapshots) del estado de la base de datos y generar reportes de rendimiento, tienes más información en
http://docs.oracle.com/cd/B10500_01/...3/statspac.htm y
http://www.orafaq.com/wiki/Statspack Cita: Lo único que podemos hasta ahora determinar es que por alguna razón que no podemos determinar la grabación del log se detiene, y el buffer parece irse saturando, impidiendo primero los asientos y luego bloqueando el borrado de la tabla
No estoy seguro a que te refieres con buffer saturado. Respecto al bloqueo del borrado, esto no tiene que ver con UTL_FILE, ya que las operaciones de I/O no tienen transacciones ni waits. Finalmente, aunque no tengo información sobre los requerimientos, se pueden hacer algunas recomendaciones:
1. Si es necesario UTL_FILE, reducir la cantidad de operaciones FOPEN, PUT_LINE y FCLOSE y evitar las ejecuciones en paralelo de PUT_LINE.
2. Si no es necesario UTL_FILE, generar las métricas en una tabla dentro de la base en vez de un fichero fuera de la base.
3. Evaluar alternativas para gestionar Logs, por ejemplo, Advanced Queuing que permite guardar o enviar mensajes de forma asincrónica, lo que reduce el impacto de generar un log, tienes un ejemplo en
http://asktom.oracle.com/pls/asktom/...:8760267539329
Saludos