PDA

Ver la Versión Completa : al hacer update la base de datos crece sin parar


tefots
17-07-2007, 10:04:28
Hola

tengo el siguiente problema con firebird

tengo una aplicación , la cual monitoriza estados de equipos (unos 100) , estos equipos cambian sus estado constantemente (y muy rapidamente) . la aplicación lo que hace es registrar estos cambios en la base de datos actualizando sus campo de estados en una tabla llamada equipos.

Pero la base de datos , crece y crece sin parar , simplemente haciendo UPDATE EQUIPOS SET SET ESTADO1=XXX ,ESTADO2=XXX ,ESTADO3=XXX WHERE EQUIPOS.IDEQUIPO=XXX.

el problema es que al cabo de una semana , la base de datos ha crecido considerablemente (unos 300mb), y no tiene porque , ya que tan solo estoy actualizando datos y no insertando.
las transacciones las inicio y finalizo correctamente (uso mdolib) , he probado con firebird 1.5 y firebird 2.0 , y el resultado es el mismo , la base de datos sigue creciendo sin parar.
La unica forma que tengo para poder reducir el tamaño es haciendo un backup y un restore , pero es algo que no puedo hacer , ya que es un sistema critico el cual no puedo parar a mi antojo.

es normal que la base de datos crezca al hacer update ? , alguna solucion ? , o me he equivocado al elejir firebird como base de datos ?

saludos

mensana
17-07-2007, 12:04:37
... la base de datos , crece y crece sin parar , simplemente haciendo UPDATE EQUIPOS SET SET ESTADO1=XXX ,ESTADO2=XXX ,ESTADO3=XXX WHERE EQUIPOS.IDEQUIPO=XXX.

es normal que la base de datos crezca al hacer update ?



Revisa la información que devuelve gstat (para Interbase)
* Oldest transaction
* Oldest active
* Oldest snapshot
* Next transaction
* Sweep interval

Comprueba si haciendo un sweep la BBDD ya no crece.

tefots
17-07-2007, 13:51:03
devuelve esto



Database "C:\BD\Acpas.fdb"

Database header page information:
Flags 0
Checksum 12345
Generation 215744
Page size 4096
ODS version 10.1
Oldest transaction 54
Oldest active 55
Oldest snapshot 47
Next transaction 215738
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jul 3, 2007 11:25:41
Attributes force write

Variable header data:
Sweep interval: 20000
*END*



significa que hay transacciones no finalizadas ??.

saludos.

mensana
17-07-2007, 14:57:36
Database header page information:
Oldest transaction 54
Oldest active 55
Oldest snapshot 47
Next transaction 215738
Sweep interval: 20000

significa que hay transacciones no finalizadas ??.


(215738 - 55) = Más de 200.000 transacciones pendientes !!!

Revisa tu aplicación, prueba también con "Interbase Performance Monitor" en http://blogs.teamb.com/craigstuntz/articles/InterBasePerformanceMonitor.aspx

mensana
17-07-2007, 14:59:41
Bueno ... más que "pendientes" son transacciones que han dejado registros que ya no son válidos pero por "lo que sea" no se han podido eliminar con un sweep

tefots
18-07-2007, 09:46:07
voy a probar con el performance monitor ese.
pero he revisado la aplicación , y no hay nada 'raro' , tan solo hago

try
query1.execsql
Query1.transaction.commitretaining;
Except
queyr1.transaction.rollbackretainig;
end;

y los querys son simplemente updates.
deberia hacer commit , en vez de commitretaining ?.
por eso no hace sweeep automaticamente ?.
la base de datos no tiene triggers ni procedimientos almacenados , simplemente tablas con sus primarykeys e indices.

he probado ha forzar hacerler un sweep , y nada , las transacciones siguen estando ahi pendientes .
el verdadero problema de todo esto , es que ademas de que la bd crece y crece , llega un momento que debe tener tantas transacciones por ahi perdidas que que la bd se espatarra , y el fbserver se pone al 100%.

saludos.

mensana
18-07-2007, 09:52:18
... tan solo hago


try
query1.execsql
Query1.transaction.commitretaining;
Except
queyr1.transaction.rollbackretainig;
end;


deberia hacer commit , en vez de commitretaining ?.



commitretaining !! Ahí tienes el problema, haces un commit y retienes (continuas) la transacción. Debes hacer un commit/rollback normal

tefots
18-07-2007, 14:15:50
commitretaining !! Ahí tienes el problema, haces un commit y retienes (continuas) la transacción. Debes hacer un commit/rollback normal

yo pensaba que commitretaining hacia lo mismo que el commit solo que finalizaba y retenia la misma transacción (evitando tener que abrir una nueva ) y que no afectaba negativamente a la base de datos.

Entonces el commitretaining /rollbackretaning no es bueno usarlo para ciertas cosas , sobre todo si se está usando la misma transaccion y realizando commitsretainings masivamente sobre esa transaccion.

gracias y un saludo

mensana
18-07-2007, 14:29:46
Básicamente el CommitRetaining sirve para una multi-transacción con varios "puntos de control" (checkpoint), pero siempre hay que finalizar con un commit normal.

En pseudo-código:

IniciarTransacción

try

Cambios en BBDD
CommitRetain (punto 1) // Los cambios son válidos en la BBDD

Cambios en BBDD
CommitRetain (punto 2) // Los cambios son válidos en la BBDD

... etc ...

Commit // Último commit

except
Rollback

rastafarey
18-07-2007, 22:01:21
Eso del CommitRetaining hay que usarlo con mucho cuidado ay que puede darte mas dolores de cabesas de lso que se iamginan.

Volviendo la tema del tamaño de la bd. Segun mencionastes haces muchas actualizaciones y pocas consultas segun veo es poco lo que sirves(los datos que se consultan) de ser asi pon un tamaño muy pequeño a la paginacion. de esta manera no se mantiene datos en memoria y la base de datos va ser mas pequeña con siderablemente.

La cosa es mas compleja que lo que te acabo de decir.

Rolopy
09-04-2008, 20:35:04
Buenas Tardes, un saludo desde Asunción del Paraguay....bueno navegando por elclubdelphi, encontre este hilo y me parecio interesante ya que en estos momentos estoy teniendo el mismo inconveniente, usando procedimientos almacenados en firebird 1.5 a la hora de hacer la llamada desde mi aplicativo ( delphi 7 + Zeos 6.62)....al procedimiento de actualización, la base de datos va incrementandose constantemente , cada vez que es llamado el procedimiento.

Se me ocurrio que algun garbage colector que use la base de datos no este eliminnando los residuos de datos o transacciones y por ello cada vez que se ejecuta el proc. crece mi base de datos.

No hay alguna forma de decirle explicita o implicitamente al motor para eliminar dichos residuos si asi fuese el caso?.

Desde ya muchas gracias por su atención.