Problemon , Oldest active y Oldest transaction , corrompe la bd.

[tefots]

Bueno, no se como explicar el problema exactamente pero el caso es que me está provocando bastantes dolores de cabeza , debido a que se me quedan transacciones sin finalizar (bueno realmente se quedan perdidas) , y llega un momento en que la base de datos se jode y se corrompe debido a las innumerables transacciones que se quedan perdidas.

ejemplo de un rato de funcionamiento

Flags 0
Checksum 12345
Generation 24181
Page size 4096
ODS version 11.0
Oldest transaction 21955
Oldest active 21956
Oldest snapshot 21943
Next transaction 24172
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 4096

(como veis hay diferencia entre oldest active y next transaction).
todas las transacciones se inician y finalizan correctamente , excepto una transaccion (la que por defecto se asigna a la base de datos) que se queda activa.

El entorno es el siguiente . uso ibexpres , atacando a fb2.0. y varios clientes y distintas aplicaciones atacando a la base de datos. por su naturaleza , algunas de estas aplicaciones , han de estar encendidas 24 horas al año.

Inicialmente pensaba que el problema era alguna transaccion que me dejaba abierta , luego pense que era por hacer commitretaining en vez de commit , lo que me obligó a realizar varios cambios en distintas aplicaciones , pero no , despues de varias pruebas , el verdadero problema , es que al hacer commit o commitretaning , firebird deja las transacciones perdidas en el hiperespacio mientras haya alguna otra aplicacion/cliente que mantenga una transaccion activa y no finalizada.

para muestra , he hecho un programita de prueba , que mantiene una transaccion abierta , y genera insercciones repetitivamente hasta el infinito (cada una con su starttransaction y commit) , pues bien , mientras se mantenga una transaccion activa , (la misma aplicacion o cualquier otra aplicacion) , las transacciones se quedan en hiperespacio , y llega un momento que al haber tantas , pues la bd se ralentica y se corrompe.
sin embargo , si se cierra la transaccion que mantenemos activa , entonces es cuando esas transacciones se 'liberan' por llamarlo de alguna forma.

un simple progamita como este , que realice inserciones masivas en una base de datos , y manteniendo por encima una transaccion activa (la que por defecto esta asociada a tibdatabase ) , hace que las transacciones se queden perdidas en el hiperespacio.

Código Delphi [-]
 
  Q:=TIBQUERY.CREATE(SELF);
  Q.SQL.ADD('INSERT INTO PRUEBA (NOMBRE,TELEFONO) VALUES (:N,:T)');
  Q.ParamByName('N').DataType:=FTSTRING;
  Q.ParamByName('T').DataType:=FTINTEGER;
  Q.Transaction:=IBTransaction2;
  WHILE (NOT FIN) DO BEGIN
    TRY
      if not IBTransaction2.Active then
        IBTransaction2.StartTransaction;
      Q.ParamByName('N').value:='NOMBRE '+inttostr(CONTADOR);
      Q.ParamByName('T').value:=CONTADOR;
      q.ExecSQL;
      IBTransaction2.Commit;
    EXCEPT
      IBTransaction2.Rollback;
    End;
    Application.ProcessMessages;;
    Label2.Caption:='Transaccion nº'+inttostr(contador);
    Inc(Contador);
  End;
  Q.free;

como el funcionamiento es ese y no lo puedo modificar , el problema es que , como tengo aplicaciones que han de mostrar datos de la bd y mantener una transaccion siempre activa , y por otra parte hay procesos que insertan modifican y borran con su correspondiente transaccion , como todo ello ha de estar 24 horas al año enmarcha , al final al cabo de un mes , la base de datos dice 'basta' , se ralentiza , se corrompe y peta.

A mi modo de ver , y a no ser que este equivocado , todo esto es un fallo de diseño muy grave de firebird , que hace que no pueda ser usado en entornos de produccion , en los que se necesite siempre tener una transacccion activa y la aplicaciones funcionando 24horas, ya que al final la base de datos acaba petando con el consiguiente problema.

en fin , una solucion busco a todo este rollo.. .

Saludos.

[pvizcay]

hola,
mira puede que este guitarreando porque eso lo leí del firebird book hace un tiempo y no lo volví a repasar, pero según tengo entendido si tienes al menos UNA sola transacción abierta por tiempo indeterminado sucede lo que comentas.. y más en un programa corriendo las 24hs como dices..

yo creo que la solución es que TODAS las transacciónes se inicien y terminen en el menor tiempo posible.. (indispensable si el programa corre todo el tiempo desde mi punto de vista).. no se que papel juega esa transacción que dejas todo el tiempo pero tendrías que cambiar la arquitectura de la aplicación para que eso no suceda más..

si tienes el firebird book hay 3 capitulos de transacciones que te explican TODO.. son un poco densos pero realmente indispensables

salu2 espero que mi respuesta esté bien encaminada..

[[duilioisola]]

excepto una transaccion (la que por defecto se asigna a la base de datos) que se queda activa

Esta transaccion (si no me equivoco) es solo para que los componentes que dependen del componente BaseDeDatos la utilicen por defecto.

Prueba ese programita que has hecho con una modificación.

Una vez que te conectes haces commit de la transaccion que se asigna a la base de datos y luego sigues (con los insert).

Dime si esto soluciona el problema.

[pvizcay]

Empezado por tefots

A mi modo de ver , y a no ser que este equivocado , todo esto es un fallo de diseño muy grave de firebird , que hace que no pueda ser usado en entornos de produccion , en los que se necesite siempre tener una transacccion activa y la aplicaciones funcionando 24horas, ya que al final la base de datos acaba petando con el consiguiente problema.

creo que estás comparando el concepto de transacción con el de conexión.. es cierto que no poder tener una conexión abierta todo el tiempo es un fallo de diseño; pero una transacción es un conjunto lógico atómico de operaciones..

TU ELIGES LA GRANULARIDAD QUE DESEES PARA ESE CONJUNTO..

tienes una operación que depende lógicamente de otra con una diferencia de tiempo importante (24hs)? lo dudo..

cualquiera sea la necesidad de esa transacción has que se crea una cuando la necesitas y has un commit cuando la mínima cantidad de operaciones con coherencia lógica sea completada.. y así se solucionará tu problema

[[duilioisola]]

24 horas al año no es demasiado ... todavía te quedan 8736 horas en el ano para apagar la aplicacion

[tefots]

el tema esta claro , mientras tenga una transaccion activa , el resto de transacciones por muy bien que las haya finalizado , se quedan pendientes realmente.
tambien tengo claro , que lo ideal para hacer cualquier operacion sobre la bd , es conectarse , iniciar transaccion , realizar operaciones , finalizar transaccion y desconectarse. lo qe pasa es que esto por la naturaleza de las aplicaciones no siempre es posible, y de serlo para poder llevarlo a cabo hay que realizar trabajo extra.

la cosa es que en una aplicación tengo controles enlazados que muestran alarmas, eventos , etc... . la aplicacion (ademas de hacer otras cosas ) como ya he dicho ha de estar siempre en marcha y estas pantallas han de estar siempre mostrandose.
y para mostrar todos estos datos he de tener siempre una transacion activa , (ademas d que el usuario puede abrir pantallas y dejarlas abiertas hasta el final de los dias , las cuales tambien usan transacciones) , asi que aqui esta el problema.
la solucion ya la se , y es cada x tiempo (digamos 1 hora) , cerrar e iniciar de nuevo las transacciones activas que tenga , sin que el usuario y sin que los controles enlazados que usan esta transaccion se enteren .
pero me parece una verdadera chapuza y una perdida de tiempo andar realizando estas cosas simplemente porque sino la base de datos peta con el tiempo.

como ya he dicho me parece un fallo muy grave , y no creo que yo haya diseñado la aplicación mal , sino que hay que diseñar la aplicacion cliente de tal forma que aunque se inicien y finalizen las transacciones correctamente , si no se tiene en cuenta , al final la bd acaba corrompiendose .
¿donde se ha visto un SGBD que por que un cliente deje una transaccion abierta , la base de datos acabe corrompiendose ?.
en fin que no volvere a usar firebird para proyectos futuros hasta que estos temas no este solucionados realmente.

saludos.

[pvizcay]

Empezado por tefots

el tema esta claro , mientras tenga una transaccion activa , el resto de transacciones por muy bien que las haya finalizado , se quedan pendientes realmente.

mmm no, no se quedan pendientes, ya están en commit o completadas.. pero el punto es que la performance se degrada como dices..

Empezado por tefots

tambien tengo claro , que lo ideal para hacer cualquier operacion sobre la bd , es conectarse , iniciar transaccion , realizar operaciones , finalizar transaccion y desconectarse. lo qe pasa es que esto por la naturaleza de las aplicaciones no siempre es posible, y de serlo para poder llevarlo a cabo hay que realizar trabajo extra.

"no siempre es posible" ?? yo creo que si, tal vez tengas que cambiar el diseño de la aplicación.. tal vez si de entrada sabías como funcionaba firebird y su arquitectura multigeneracional te hubieras ahorrado el trabajo..

Empezado por tefots

la cosa es que en una aplicación tengo controles enlazados que muestran alarmas, eventos , etc... . la aplicacion (ademas de hacer otras cosas ) como ya he dicho ha de estar siempre en marcha y estas pantallas han de estar siempre mostrandose.
y para mostrar todos estos datos he de tener siempre una transacion activa , (ademas d que el usuario puede abrir pantallas y dejarlas abiertas hasta el final de los dias , las cuales tambien usan transacciones) , asi que aqui esta el problema.

para alarmas y eventos FB tiene los events.. la aplicación cliente que los "escucha" no tiene que crear una transacción para los mismos.. asi que esto es claramente falso

Empezado por tefots

la solucion ya la se , y es cada x tiempo (digamos 1 hora) , cerrar e iniciar de nuevo las transacciones activas que tenga , sin que el usuario y sin que los controles enlazados que usan esta transaccion se enteren .
pero me parece una verdadera chapuza y una perdida de tiempo andar realizando estas cosas simplemente porque sino la base de datos peta con el tiempo.

puedes hacer que las pantalla cargue los datos y luego cerrar la transacción.. (con controles no enlazados por ej); si es una operación interactiva no hace falta que quede un día la ventana abierta.. si te pones a pensar como solucionarlo encontraras 100 maneras elegantes de realizarlo..

Empezado por tefots

como ya he dicho me parece un fallo muy grave , y no creo que yo haya diseñado la aplicación mal , sino que hay que diseñar la aplicacion cliente de tal forma que aunque se inicien y finalizen las transacciones correctamente , si no se tiene en cuenta , al final la bd acaba corrompiendose .
¿donde se ha visto un SGBD que por que un cliente deje una transaccion abierta , la base de datos acabe corrompiendose ?.
en fin que no volvere a usar firebird para proyectos futuros hasta que estos temas no este solucionados realmente.

saludos.

yo creo que si la diseñastes mal y estas enojado con firebird por eso.. es más gran parte del problema viene por los componentes de acceso a datos que usas que están pensados para programas con otros requerimientos.. si quieres algo mas tienes que escribir un poco de código.. diseñar una aplicación que corre 24x356 no es trivial, y ni siquiera hicistes una pequeña investigación de la tecnología que usastes.. yo creo que puedes aprender algo de todo esto que te sucedió.. éxitos!

[tefots]

Hola , gracias por responder.

Empezado por pvizcay

mmm no, no se quedan pendientes, ya están en commit o completadas.. pero el punto es que la performance se degrada como dices..

exacto , aqui esta el problema y la gran cagada de firebird. la performance se degrada , y al final se corrompe , te lo aseguro.
[/quote]

Empezado por pvizcay

para alarmas y eventos FB tiene los events.. la aplicación cliente que los "escucha" no tiene que crear una transacción para los mismos.. asi que esto es claramente falso

no me referia a los events de firebird , con esto me referia a que muestro una serie de registros que guardan alarmas y eventos de diversos tipos, tambien estados de distintos equipos hardware. todo ello con controles enlazados (dbgrid's , etc).

Empezado por pvizcay

puedes hacer que las pantalla cargue los datos y luego cerrar la transacción.. (con controles no enlazados por ej); si es una operación interactiva no hace falta que quede un día la ventana abierta.. si te pones a pensar como solucionarlo encontraras 100 maneras elegantes de realizarlo..

Siempre he usado controles enlazados , creo que es una de las cosas en las que delphi se aventaja de sus adversarios. si por usar firebird , en algunos casos no voy a poder usar controles enlazados (que esten permanentemente mostrandose) , o voy a tener problemas por usarlos , creo que es un paso atrás y una desventaja en vez de una ventaja.
como bien dices , hay muchas formas de solucionar el problema , pero no habria nada que solucionar si firebird no tuviera dicho problema.

Empezado por pvizcay

yo creo que si la diseñastes mal y estas enojado con firebird por eso.. es más gran parte del problema viene por los componentes de acceso a datos que usas que están pensados para programas con otros requerimientos.. si quieres algo mas tienes que escribir un poco de código.. diseñar una aplicación que corre 24x356 no es trivial, y ni siquiera hicistes una pequeña investigación de la tecnología que usastes.. yo creo que puedes aprender algo de todo esto que te sucedió.. éxitos!

No estoy enojado con firebird (solo conmigo mismo por haberlo elejido) , llevo usandolo en todas sus versiones , desde que se liberó ib6 , así que unas cuantas pruebas si que he hecho. lo que no sabia era que la bd se degradaba al mantener una transaccion activa (supongo que la mayoria de usuarios fb no lo saben) , ya que la > de aplicaciones no corren 24x365.

Escribiendo un poco de código todo puede hacerse , pero los controles gráficos enlazados están para que el programador pierda el menor tiempo posible en esto , dile a alguien que está acostumbrado a usar un dbgrid que para que firebird no se degrade , que use un stringgrid , o mejor aun que lo pinte directamente en el canvas.

Como ya he dicho , un sgbd que se degrada porque un cliente mantiene una transaccion activa , no me parece un sgbd serio. independientemente del tiempo que un cliente mantenga una transaccion abierta , fb deberia mantener el performance y la integridad de los datos , y no lo hace.

No hay que ser taliban de firebird (que nadie se ofenda) , para un tipo de aplicaciones firebird va muy bien (de hecho llevo usandolo y defendiendolo muchos años) , pero para otro tipo de aplicaciones , es mejor no usarlo (o se si usa , hay que tener en cuenta algunas cosas para que no se degrade).


Saludos