Problema engorde y rendimiento

[Toni]

Buenas a todos,

Tengo una base de datos hecha en FB1.5 que ya funciona correctamente desde hace años. No se exactamente porque en el caso de este cliente la base de datos engorda una barbaridad diariamente. Para que os hagais una idea, una base que se a realizado un backup-restore y se queda en 25mb en cuestion de horas vuelve a ocupar 200mb. El volumen de informacion que se introduce diariamente es minimo. Y la base de datos tiene como maximo 8 usuarios.

Si bien es cierto que hay un programa que esta conectado a esta base de datos para importar datos desde otro sistema. Y esta importando los datos de forma constante cada 5 minutos, importando nuevos registros y actualizando los existentes. Con lo que esta importando varias tablas de 12.000 reg.

El problema en si no es el tamaño sino que va relacionado con el rendimiento. Pues cuando ha engordado como os comentaba antes a 200mb, 450mb, pues procedimientos almacenados que tardaban menos de 1s tardan 1 min. largo. con el problema que ocasiona pues realiza conflictos de bloqueos. Principalmente se nota el problema en un procedimento almacenado que actualiza datos de tablas de forma masiva.

Si vuelvo a realizar un backup-restore el problema se soluciona de inmediato, incluido en dicho procedimiento.

Las aplicaciones utilizan IBX + ClientDataSets para acceder a FB1.5. Y utilizan unicamente commits para las transacciones. Todo esto esta montado en un Windows 2008 Server. FB1.5 (tamaño pagina 1024, intervalo limpieza basura 20000, ODS 10.1)

De igual forma que al realizar un backup-restore todo vuelve a funcionar rapido, he probado a realizar un 'gfix -sweep -user SYSDBA - masterkey' y me deja la base de datos con el mismo tamaño (gorda) pero todo vuelve a funcionar rapido.


Saludos,

[Casimiro Notevi]

Debe haber algo anómalo en el tratamiento de las transacciones porque no es nada normal que tengas problemas de bloqueos, tal y como mencionas:

con el problema que ocasiona pues realiza conflictos de bloqueos

¿Qué parámetros tienes en las transacciones?

Lo que sí te aconsejo es que cambies el tamaño de página de 1024 a 8192, estás penalizando su rendimiento.

[Toni]

Hola Casimiro,

los parametros que tengo en el TIBTransaction que utilizo son los de 'Read Commited' (read_commited, rec_version, nowait)

Lo que comentaba sobre los conflictos en los bloqueos es porque al tardar tanto tiempo la ejecucion de un procedimiento almacenado que realiza muchas actualizaciones (masivas) pues puede provocoar eso. Pero cuando todo esta bien funciona muy rapido.

Para cambiar el tamaño de pagina que utilizo el gfix? puede dañar la base?

Muchas gracias!

saludos,

[guillotmarc]

Hola.

Parece bastante lógico pensar que tus problemas vienen por transacciones demasiado largas (en tiempo y nº de registros).

Las transacciones tienen que ser lo más cortas posibles, y sobre todo nunca debes dejar transacciones abiertas con modificaciones realizadas (esos registros quedan bloqueados, con lo que bloquean las importaciones, los procedimientos almacenados, etc. ...). Yo incluso te recomendaría no dejar nunca transacciones abiertas de ningún tipo (ni siquiera que sean de lectura).

Así pues, en tu proceso de importación de datos, ve confirmando las transacciones cada poco rato (por ejplo. cada 500 registros es un buen valor), en lugar de esperar hasta el final de la importación.

Y en tu aplicación, no dejes nunca transacciones abiertas. Si el usuario tiene que modificar datos, ponlos en un ClientDataset, de manera que el usuario puede modificar los datos tan tranquilamente como quiera (ya que no se mantiene ninguna transacción abierta), y cuando sea necesario los aplicas a la base de datos llamando al método ApplyUpdates (eso inicia una transacción, ejecuta las sentencias INSERT, DELETE y UPDATE necesarias para aplicar a la Base de Datos los cambios realizados a los Datos en el ClientDataset, y cierra automáticamente la transacción. Todo el proceso apenas dura unos pocos milisegundos con la transacción abierta).

En definitiva, cuanto más cortas sean tus transacciones, menos posibilidades hay de encontrar bloqueos. Y si las transacciones solo duran unos pocos milisegundos (abres la transacción, lees los datos, se pasan al clientdataset y se cierra, o se realizan los cambios y se cierra) es bastante difícil encontrar bloqueos (yo puedo contar con los dedos de una mano los bloqueos que me he encontrado en diez años usando Firebird).

Respecto al tamaño de la base de datos, yo no me preocuparía lo más mínimo por ello. Firebird es una base de datos multigeneracional, cuando modificas un registro se hace una copia del mismo, eso quiere decir que si hay muchas modificaciones simultaneas en largas transacciones abiertas (como parece ser actualmente tu caso), entonces tienes muchas copias de tus registros. Pero una vez confirmada la transacción, ese espacio se reutiliza. Así que tu Base de Datos crecerá hasta un tamaño determinado para poder mantener todas las versiones en memoria que haces en tu uso normal del programa, y a partir de ese punto solo crecerá moderadamente, a medida que se vayan dando de alta registros.

NOTA: Aunque verás que si haces las transacciones más cortas, tu base de datos también crece mucho menos (ya que no tiene que mantener tantas versiones simultaneas de los registros).

Saludos.

[guillotmarc]

NOTA: Por cierto, para cambiar el tamaño de la base de datos yo hago un Backup y un Restore (parámetro -P). No creo que puedas hacerlo con el GFix.

[guillotmarc]

Casimiro, ¿ puedes borrar este último mensaje ?, te me has adelantado.



Gracias.

[Casimiro Notevi]

Por mucho que tarde un procedimiento no puede causar errores por bloqueos.

Para cambiar el tamaño de página puedes hacer un backup y restore:

gbak -b -t -v -user sysdba -password masterkey tubd.fdb tubd.fbk

gbak -r -v -p 8192 -user sysdba - password masterkey tubd.fbk tubd.fdb

Edito: acabo de leer lo escrito por guillotmarc, hazle caso
Y en cuanto al tamaño de la base de datos, esta mañana he estado atendiendo una duda de un cliente que su BD ha pasado los 24 GB y no se queja por el rendimiento.