Problema engorde y rendimiento

[guillotmarc]

Por cierto, yo en FIBPlus pongo un TimeOut de 1 a mis transacciones para asegurarme de que nunca queden abiertas. No sé si en IBX tienes algo similar.

[Toni]

Hola,

respecto a esto:

Por cierto, para las consultas de modificacion, insercion y/o procedimientos alm. como los utilizais con los clientdataset para sincronizar todo en una transaccion?

Creo que no me he explicado correctamente, quiero decir que yo utilizo los clientdataset para consultas y consultas modificables y realizo un applyupdates para grabar todos los cambios.

Pero cuando en el mismo proceso de guardar esos cambios quiero incluir en una misma transaccion una actualizacion o insercion mediante instrucciones SQL (insert, update) o un procedimiento almacenado.

Por ejemplo solamente con componentes IBX lo haria asi:

/* componente IBQuery + IBUpdateSQL*/
IBXQuery->Edit();
IBXQuery->FieldByName("Ejercicio")->AsInteger = Ejercicio;
IBXQuery->Post();

/* insert, update o procedimiento */
IBXQuery2->ParamByName("P_EJERCICIO")->AsInteger = Ejercicio;
IBXQuery2->ExecSQL();

TIBTransaction->Commit(); /* Confirmo todas las operaciones anteriores */

utilizando los clientdataset:

ClientDataSet->Edit();
ClientDataSet->FieldByName("Ejercicio")->AsInteger = Ejercicio;
ClientDataSet->Pots();

/* insert, update o procedimiento */
IBXQuery2->ParamByName("P_EJERCICIO")->AsInteger = Ejercicio;
IBXQuery2->ExecSQL();

ClientDataSet->ApplyUpdates(-1);
TIBTransaction->Commit(); /* Confirmo todas las operaciones anteriores */

[guillotmarc]

Hola.

Yo te recomendaría que definas una sola transacción y que la controles manualmente (la inicies y la finalices tú, en lugar de dejar que se haga implícitamente).

Empezado por Toni

IBTransaction->StartTransaction();

ClientDataSet->Edit();
ClientDataSet->FieldByName("Ejercicio")->AsInteger = Ejercicio;
ClientDataSet->Post();
ClientDataSet->ApplyUpdates(-1);

IBXQuery->ParamByName("P_EJERCICIO")->AsInteger = Ejercicio;
IBXQuery->ExecSQL();

IBTransaction->Commit();

NOTA: No utilizo IBX, pero debería ser algo así.

[Toni]

Hola,

He probado a ir aislando los problemas y finalmente lo que me engorda la base de datos es la ejecuccion de un procedimiento almacenado que realiza calculos sobre tablas de forma 'masiva'. Algo similiar a esto pero 5 veces con diferentes tablas.

   for select "Campo1", "Campo2" from "Tabla1"
   where "Campo5"=:P_PARAM and "Campo5"<>'F' group by "Campo1", "Campo2"
   into :P_PARAM2, :P_PARAM3
    do
     begin
      update "Tabla2" U set "Campo6"='A'
      where U."Campo1"=:P_PARAM and U."Campo2"=:P_PARAM2 and U."Campo3" = :P_PARAM;
     end

Incluso si lo ejecuto desde el IBManager me engorda la base de datos. Aunque lo que realmente me importa no es el tamaño de base de datos, sino que por algun motivo este engorde afecta al 'rendimiento brutalmente'.

Tambien he probado a realizar el cambio de paginado que me comentaba Casimiro, pero al realizar el cambio con la nueva base de datos con el tamañp de paginado a 8192, me empezo a realizar unos extraños (cambiar masivamente el estado de diferentes documentos) y tuve que recuperar la copia de seguridad que habia realizado justo antes. La verdad que no le pude encontrar otra explicacion a la incidencia. No se si tenia que haber cerrado el servicio de FB al realizar el cambio de base de datos.

Muchas gracias por las aportaciones.

[guillotmarc]

Hola Toni.

¿ Cuantos registros hay involucrados en ese procedimiento almacenado ?.

Si la Base de Datos crece exageradamente, es que se están modificando de golpe una cantidad desorbitada de registros, lo cual ocurre lógicamente en una única transacción con lo que crece la base de datos por el versionado de esos registros (y también explica la caída de rendimiento).

¿ Estás seguro que no hay triggers enmedio que te están forzando la actualización inesperada de más registros en otras tablas ?.

Será mejor que revises el código para ver si en ese procedimiento almacenado no estás haciendo muchísimas más actualizaciones de las necesarias.

[Toni]

Hola Guillotmarc,

Como comentaba este procedimiento recalcula (suma y agrupa el contenido de unas tablas y actualiza con el resultado otras) las tablas que agrupan tienen al rededor de 11000 registros y la que actualiza tambien.

He comprobado que no hay triggers implicados.

Se que esto no es lo mas optimo, pero inicialmente funciona bastane bien. A medida que va 'acumulando' versiones de los registros y va aumentando el tamaño de la base de datos, cuando el tamaño se multiplicado ya 5 el rendimiento cae en picado.

¿Pero estos registros no tendrian que influirle tanto, no?

¿la unica manera de mejorar el rendimiento sera hacer backup-restore?

Muchas gracias.

[[duilioisola]]

Habría que ver cómo es ese procedimiento. Tendrías que ver si puedes aplicar esta idea a tu procedimiento:

Código SQL [-]
/*Por cada registro tratado hago un update*/
declare variable importe double precision;
begin
   for select importe from tabla
       where ...
       into :importe
   do
   begin
       update totales 
       set importe=importe + :importe
       where ...;
   end
end

Código SQL [-]
/*Acumulo en una variable y hago un solo update final*/
declare variable importe double precision;
declare variable total double precision;
begin
   for select importe from tabla
       where ...
       into :importe
   do
   begin
       Total = Total + importe;
   end
   update totales 
   set importe=total
   where ...;
end

[guillotmarc]

Empezado por Toni

Hola Guillotmarc,

Como comentaba este procedimiento recalcula (suma y agrupa el contenido de unas tablas y actualiza con el resultado otras) las tablas que agrupan tienen al rededor de 11000 registros y la que actualiza tambien.

He comprobado que no hay triggers implicados.

Se que esto no es lo mas optimo, pero inicialmente funciona bastane bien. A medida que va 'acumulando' versiones de los registros y va aumentando el tamaño de la base de datos, cuando el tamaño se multiplicado ya 5 el rendimiento cae en picado.

¿Pero estos registros no tendrian que influirle tanto, no?

¿la unica manera de mejorar el rendimiento sera hacer backup-restore?

Muchas gracias.

Todo apunta a que sigues teniendo como mínimo una transacción que se queda siempre abierta, por lo que no se puede ejecutar la recolección de basura de Firebird, y no se recupera el espacio usado por el versionado de productos, aparte de finalmente caerse el rendimiento de la base datos.

Tienes todos los síntomas relatados en este artículo de Firebird :

http://www.ibphoenix.com/main.nfs?a=...x&page=ibp_oit

Tienes que revisar todas las transacciones de tu programa, y verificar que se finalicen inmediatamente una vez terminada su tarea. Nunca dejes transacciones abiertas a la espera de que el usuario haga algo, y no confíes en las transacciones implícitas de los componentes, puesto que si hay una transacción abierta, ejecutarán su consulta dentro de esa transacción y la dejarán como estaba, es decir abierta. Programa tu mismo el inicio y commit de las transacciones en cada actualización de la base de datos.

Saludos.