¿Lentitud en proceso de registros ...?

[Bretema]

Buenos días,

tengo una aplicación que maneja una base de datos a través de Firebird con componentes IBX. Uno de los procesos consiste en la elaboración de un diario con registros importados de varias tablas. Una vez tengo la tabla del diario cargada con sus movimientos, leo de otra tabla el saldo inicial de la cuenta y después recorro todos los movimientos del diario estableciendo el saldo después de cada movimiento. El código es simple:

 TMov.Open;
 TMov.First;

 while not TMov.Eof do
    begin
    TMov.Edit;

    TMovSaldo.Value := Saldo + TMovDebe.Value - TMovHaber.Value;
    Saldo := TMovSaldo.Value;
    DebeMo := DebeMo + TMovDebe.Value;
    HaberMo := HaberMo + TMovHaber.Value;

    TMov.Post;
    TMov.Next;
    end;

El problema viene dado que, ahora que tengo diarios con mas de 2.000 movimientos, el recorrer los registros para incluir el saldo tarda mucho, estamos hablando de cerca de 30 segundos con un Pentium 4 ..... o unos 10 en un dualcore.

El código, desde mi modesto punto de vista, no tiene mucho mas donde rascar .... pero me parece excesivo el tiempo de procesamiento para ese numero de registros ....

He hecho la prueba exportando las tablas a Interbase y a traves de ese gestor los tiempos empeoran ligeramente.

Alguna sugerencia ..... ?

[guillotmarc]

Esto es un ejemplo perfecto de un proceso que se ejecuta muchísimo más rápido en un procedimiento almacenado.

Sería más o menos así :

Código SQL [-]
SET TERM ^ ;

create procedure ACTUALIZAR_SALDO
returns (
    TOTAL_SALDO numeric(15,2),
    TOTAL_DEBE numeric(15,2),
    TOTAL_HABER numeric(15,2))
as
declare variable MOV_ID integer;
declare variable MOV_DEBE numeric(15,2);
declare variable MOV_HABER numeric(15,2);
begin
  TOTAL_SALDO = 0;
  TOTAL_DEBE = 0;
  TOTAL_HABER = 0;

  for select ID, coalesce(DEBE,0), coalesce(HABER,0)
      from MOVIMIENTOS
      into :MOV_ID, :MOV_DEBE, :MOV_HABER
  do begin
    TOTAL_SALDO = TOTAL_SALDO + MOV_DEBE - MOV_HABER;
    TOTAL_DEBE = TOTAL_DEBE + MOV_DEBE;
    TOTAL_HABER = TOTAL_HABER + MOV_HABER;

    update MOVIMIENTOS set
           SALDO = :TOTAL_SALDO
    where ID = :MOV_ID;
  end
end
^

SET TERM ; ^

Al ejecutarse todo el procedimiento almacenado en el servidor, te ahorras todo el movimiento de red necesario para recorrer los 2.000 registros, recuperar los valores de sus campos, modificar el registro, etc. ...

El paso por la red suele ser el cuello de botella de estos procesos. Mediante la ejecución en un procedimiento almacenado, por la red solo se pasa la solicitud de ejecución del procedimiento almacenado, y se reciben como resultado los valores de Saldo, Debe y Haber Totales.

Saludos.

[Bretema]

Muchas gracias por tu respuesta Guillotmarc, he puesto en marcha la solución que me propusiste y efectivamente el descenso en el tiempo de proceso ha sido apreciable, el tiempo de proceso de los registros se ha reducido a un tercio del anterior.

Saludos cordiales.

[guillotmarc]

Empezado por Bretema

Muchas gracias por tu respuesta Guillotmarc, he puesto en marcha la solución que me propusiste y efectivamente el descenso en el tiempo de proceso ha sido apreciable, el tiempo de proceso de los registros se ha reducido a un tercio del anterior.

Saludos cordiales.

Sinceramente, 10 segundos (un tercio de los 30 segundos originales), me siguen pareciendo excesivos para solo 2.000 registros.

Parece que la base de datos tiene algún trigger para AFTER UPDATE en la tabla MOVIMIENTOS, y que la ejecución de ese trigger para cada registro ralentiza todo el proceso.

Deberías considerar desactivar los triggers que no sean imprescindibles, antes de lanzar el proceso. Una vez finalizado el proceso, ya puedes reactivar de nuevo los triggers.

ALTER TRIGGER MOVIMIENTOS_AU01 INACTIVE;
ALTER TRIGGER MOVIMIENTOS_AU02 INACTIVE;
EXECUTE PROCEDURE ACTUALIZAR_SALDO;
ALTER TRIGGER MOVIMIENTOS_AU01 ACTIVE;
ALTER TRIGGER MOVIMIENTOS_AU02 ACTIVE;

Saludos.

[Casimiro Notevi]

Empezado por guillotmarc

Sinceramente, 10 segundos (un tercio de los 30 segundos originales), me siguen pareciendo excesivos para solo 2.000 registros.

Yo uso un store procedure similar y con bastantes más de 2000 registros tarda apenas una décima de segundo. Así que es seguro que sea lo que comenta guillotmarc, algún trigger.

[Bretema]

He revisado la tabla en cuestión y no tiene triggers, de hecho es una tabla que solo se usa para volcar los registros desde un par de tablas y después realizar el proceso que comenté para establecer el saldo tras cada movimiento. Una vez el usuario lo ve, cuando cierra la ventana se vacia la tabla. El tiempo lo mido exclusivamente desde justo la llamada a la store proc. hasta que finaliza ..... en mi dual core tardaba unos siete segundos y bajó a dos ... en otro mas lento, un amd con xp y un mega de ram en el cual tardaba 17 segundos bajó a unos seis. El ahorro es evidente pero desde luego lejos de las décimas que comenta Casimiro .... no se ya si será cuestión de tocar algún parámetro del gestor de la base de datos ... la página de la tabla la tengo definida en 4096 que creo es el estandar.

Saludos.

[Casimiro Notevi]

Supongo que no será posible probar la base de datos, ¿verdad?.

Por cierto, haz un backup y luego restauras a tamaño de página 8192, debe de ir bastante mejor.

[[newtron]]

Igual suelto una tontería porque yo no uso firebird pero ¿no sería posible crear esa tabla en memoria?, eso agilizaría bastante.

Saludos

[Casimiro Notevi]

Es que realmente debe tener algún problema añadido, 2.000 registros es nada, es como si dice que son 2 registros, igual, debe ser algo instantáneo.

[JXJ]

Empezado por guillotmarc

Esto es un ejemplo perfecto de un proceso que se ejecuta muchísimo más rápido en un procedimiento almacenado.

Sería más o menos así :

Código SQL [-]SET TERM ^ ; create procedure ACTUALIZAR_SALDO returns ( TOTAL_SALDO numeric(15,2), TOTAL_DEBE numeric(15,2), TOTAL_HABER numeric(15,2)) as declare variable MOV_ID integer; declare variable MOV_DEBE numeric(15,2); declare variable MOV_HABER numeric(15,2); begin TOTAL_SALDO = 0; TOTAL_DEBE = 0; TOTAL_HABER = 0; for select ID, coalesce(DEBE,0), coalesce(HABER,0) from MOVIMIENTOS into :MOV_ID, :MOV_DEBE, :MOV_HABER do begin TOTAL_SALDO = TOTAL_SALDO + MOV_DEBE - MOV_HABER; TOTAL_DEBE = TOTAL_DEBE + MOV_DEBE; TOTAL_HABER = TOTAL_HABER + MOV_HABER; update MOVIMIENTOS set SALDO = :TOTAL_SALDO where ID = :MOV_ID; end end ^ SET TERM ; ^


Al ejecutarse todo el procedimiento almacenado en el servidor, te ahorras todo el movimiento de red necesario para recorrer los 2.000 registros, recuperar los valores de sus campos, modificar el registro, etc. ...

El paso por la red suele ser el cuello de botella de estos procesos. Mediante la ejecución en un procedimiento almacenado, por la red solo se pasa la solicitud de ejecución del procedimiento almacenado, y se reciben como resultado los valores de Saldo, Debe y Haber Totales.

Saludos.

hola

http://www.clubdelphi.com/foros/imag...ine=1267189133 guillotmarc
Registrado

tu codigo me parece muy interesante.

com puedo aprender mas.

dijamos si quiero hacer unos reportes de ventas
y quiero mostrar la informacion ordenada
por ventas por cliente. por dia. por tipo de pago.

apenas se me ocurrio que esto de los stored procedures
me serviria.

[Bretema]

Al final solucioné el problema atacándolo desde dos frentes, el proceso de cálculo del saldo lo hago con una store procedure tal y como me sugirió guillotmarc, con esto tengo una reducción apreciable del tiempo de proceso. La tabla en cuestión arrastra movimientos de varios años (exigencias del usuario), pero para cortar el problema de raíz puse en el formulario un campo para dar la opción de seleccionar un año en concreto o manejar todo el conjunto. Hago la select sobre ese campo y con ello me aseguro de que siempre habrá una opción para que el proceso sea rápido aunque la tabla se vaya cargando de nuevo de registros .... como el saldo inicial de la cuenta no es anual, tuve que crear otra store procedure para calcular el saldo inicial en función del año .... al final la consulta de un año concreto es casi instantáneo.

De todas formas me queda el mosqueo de que incluso con la primera solución de guillomarc siguiese tardando tanto, sin triggers y sobre una tabla temporal exclusivamente para ese proceso ..... también probé la sugerencia de Casimiro pero el variar el tamaño de página en este caso no tuvo demasiada incidencia.

Gracias a todos por vuestras sugerencias.

[[Delphius]]

Hay algo que no se dijo... ¿Y, cómo andamos con los índices?

Saludos,

[guillotmarc]

Empezado por Delphius

Hay algo que no se dijo... ¿Y, cómo andamos con los índices?

Saludos,

Muchísimos índices tendría que tener para provocar esos retardos. También lo pensé, pero no creo que sea la causa.

A mi en todo momento me ha parecido que por algún lado se está disparando código adicional (mediante eventos en Delphi o triggers en Firebird), pero no lo ha encontrado. Así que no sé que pensar.