Crecimiento anomalo fichero Interbase

EL WINDSURFISTA · #1 29-10-2003

Interbase 6.0 instalado sobre un Win2000 y 6 terminales trabajando a tope, el problema esta en el crecimiento del fichero GDB. Si el tamaño es 150MB en un mes de trabajo se duplica a 300MB, realizo un Backup y Restore y se queda en un poco mas 170MB como es lógico. Se realizan muchas consultas. Creo que el problema puede venir por la arquitectura multigeneracional de Interbase, cada vez que hay una consulta, se generan copias de registro, que al final Interbase no elimina.
¿ Como hay que configurar Interbase para solucionar el problema ?.

Gracias

guillotmarc · #2 29-10-2003

Hola.

Interbase/Firebird debería recuperar ese espacio, al concluir la transacción.

¿ Tienes transacciones que se mantienen abiertas mucho tiempo ?. Si mantienes la transacción abierta mucho tiempo y vas confirmando los cambios con un CommitRetaining en lugar de con un Commit, estás impediendo la recogida de basura, con lo que la base de datos puede crecer desmesuradamente, como comentas.

Si es el caso, intenta utilizar algún Commit, cada x tiempo entre los CommitRetaining (o mejor, intenta sustituir los CommitRetaining por Commit).

Saludos.

EL WINDSURFISTA · #3 31-10-2003

He cambiado el programa y cada vez que salen de una opción ejecuto un commit. Observo que el fichero aumenta aproximadamente en 2MB cada día, en un mes puede crecer 40MB. Los usuarios realizan mayoritariamente consultas. Se supone que el recolector de basura entra a funcionar cuando ejecuto un commit.

Gracias.

kinobi · #4 31-10-2003

Hola,

Cita:

Posteado originalmente por EL WINDSURFISTA
Se supone que el recolector de basura entra a funcionar cuando ejecuto un commit.

en principio eso es así. Ahora bien, ¿qué entiendes por basura?. Los registros eliminados no son considerados basura; éstos permanecen ocupando espacio en las páginas de la base de datos hasta que es reclamado por el motor para introducir nuevos datos o se hace una reconstrucción de la base de datos (backup/restore). De todas formas, si, como comentas, la mayor parte de las operaciones son de lectura, y a falta de saber el tamaño de los registros, parece raro.

Si has seguido las indicaciones de Marc, yo probaría (sobre una copia de la base de datos) a utilizar otra versión de InterBase (la 6.0 no es demasiado confiable), bien Firebird o alguna de las versiones comerciales de IB posteriores a la 6.0: 6.5 o 7.x

Saludos.

rastafarey · #5 25-11-2003

puedes hacer un bakup y restore y te evitas ese problema.

Pero tratare de explicarte cual es el problema.

Lo que pasa es que interbase trabaja con una cosa que llaman versioning es decir cada quien trabaja sobre una copia del registro y si se van quedando transaciones en el limbo eso es basura.

Esta forma por ser tan segura y buena. algo tiene que arriesgar, vez esto ocupa mucho espacio en discopa para poder realizar el control de las transaciones pero si tu le quieres desactivar lo mejor que tiene interbase especificale que no use las transacciones con versioning y trabajas al estilo sqlserver

kinobi · #6 26-11-2003

Hola,

Cita:

rastafarey comentó:
[...] pero si tu le quieres desactivar lo mejor que tiene interbase especificale que no use las transacciones con versioning y trabajas al estilo sqlserver

No puedo asegurarlo en IB 7, pero sí en IB 6.x (e inferiores) y en todas las versiones de Firebird, que tal cosa, desactivar la arquitectura multigeneracional (o versionado de registros) y utilizar un mecanismo de bitácoras ("al estilo SQLServer"), no existe. La única novedad, en cuanto a transacciones se refiere, que se ha introducido últimamente son los savepoints, pero no afecta a la MGA.

Saludos.