Firebird en un entorno 24x7

[enlavin]

Hola a todos,

Soy nuevo en este foro, así que espero no soltar burradas muy graves

Más que un problema concreto lo que aquí voy a plantear es una duda de concepto. Voy a exponer las conclusiones a las que he ido llegando para luego plantear algunas preguntas. Lo primero indicar que utilizo Delphi5 y Firebird 1.0.3-972 en Windows 2000 y XP. Lo segundo es que no soy muy ducho en Delphi ya que lo mio es más unix y la programación de sistemas. Así que si el problema es de un mal uso de los componentes no teneis más que decirlo y la colleja me la pego yo solo

[TOCHO MUY LARGO]
Tengo un software de adquisición de datos que ha de estar funcionando lo más continuadamente posible. Básicamente, cada cierto tiempo se recibe información que actualiza registros ya existentes en una tabla. Es decir que, exceptuando los mecanismos internos de Firebird (versionado de registros, etc), el volumen de información total de la base de datos no cambia. La actualización de datos siempre se hace mediante componentes Delphi y los métodos Edit y Post.

En otra base de datos diferente se van a añadiendo registros históricos con Append y Post, y cada cierto tiempo se borran. Según he leido, al borrar no se reaprovecha automáticamente el espacio hasta que se lleva a cabo una recolección de basura.

El problema es que nuestro sistema debe funcionar lo más autónomamente posible. Con el tiempo se observa un crecimiento bastante significativo de los ficheros .GDB , aparejado con una bajada de rendimiento considerable (el problema de rendimiento se aprecia tanto en 2000 como XP, por lo que no creo que tenga que ver con la restauración del sistema de XP). En ocasiones hemos llegado a tener el sistema completamente parado. Siempre se soluciona con un backup/restore. A veces simplemente parando la BD, haciendo una copia del .GDB y rearrancando la aplicación se recupera buena parte del rendimiento original (puede ser algo relacionado con la fragmentación en sistema de ficheros del fichero original). Los ficheros .GDB tienen 20000 en el parámetro "sweep interval". Usamos dialecto 1.

Leyendo un documento de uno de los moderadores de este foro decidimos empezar a utilizar "gfix -sweep" por las noches y parece que la BD contiene su tamaño. Aún así no estoy tranquilo del todo, ya que es un sistema en producción y esas cosas dan bastante yuyu.

Bueno, todo ese rollo es para plantear la situación. Ahora vienen las cuestiones:
[EOT]

1- Utilizando los componentes estándar de Delphi5, ¿con {Edit|Append}/Post es suficiente para finalizar una transacción o es necesario realizar las operaciones en el contexto de una transacción de forma explícita (StartTransaction + {Edit|Append}/Post +Commit)? ¿Si no hago commit se me quedan transacciones en el limbo?

2- ¿Usar gfix es la forma correcta de hacer las cosas para que la BD no crezca desmesuradamente? ¿Por qué no se hace el sweep solito sin que nadie se lo diga?

3- ¿Alguno ha observado la degeneración de rendimiento que comento más arriba? ¿Es un mal inevitable o con la recolección de basura se soluciona? En nuestro caso aparece aproximadamente después de 1-2 semanas después del último restore.

A mis jefes les precupan mucho éstos dos problemas (sobre todo el del rendimiento), hasta el punto de considerar el cambio a otra BD (mysql probablemente) con mucho menos mantenimiento, aunque también menos características. Les he dicho que aplacen la decisión, porque problablemente es un tema de desconocimiento por nuestra parte en la configuración de Firebird. ¿Qué me decís?

Bendito sea el que haya llegado leyendo hasta aquí

Muchas gracias por vuestro tiempo.

Nos vemos!

[kinobi]

Hola y bienvenido,

Empezado por enlavin

Es decir que, exceptuando los mecanismos internos de Firebird (versionado de registros, etc), el volumen de información total de la base de datos no cambia.

Y, en mi opinión, sin exceptuar la multiversión de registro. Todos los gestores de bases de datos que implanten el mecanismo transaccional disponen de un sistema que les permite "regresar" a estados anteriores. En el caso de InterBase (y Firebird) es la multiversión de registro, en otros son bitácoras.

Empezado por enlavin

En otra base de datos diferente se van a añadiendo registros históricos con Append y Post, y cada cierto tiempo se borran. Según he leido, al borrar no se reaprovecha automáticamente el espacio hasta que se lleva a cabo una recolección de basura.

Si te refieres a si ese espacio es devuelto al sistema de archivos estás en lo cierto, no es devuelto. Si por el contrario te refieres a si ese espacio puede ser aprovechado para almacenar información nueva en la base de datos, el propio servidor lo "reclamará" según lo vaya necesitando.

Empezado por enlavin

El problema es que nuestro sistema debe funcionar lo más autónomamente posible. Con el tiempo se observa un crecimiento bastante significativo de los ficheros .GDB , aparejado con una bajada de rendimiento considerable

Algo habitual en bases de datos InterBase con mucha actividad (altas y actualizaciones).

Empezado por enlavin

Siempre se soluciona con un backup/restore. A veces simplemente parando la BD, haciendo una copia del .GDB y rearrancando la aplicación se recupera buena parte del rendimiento original (puede ser algo relacionado con la fragmentación en sistema de ficheros del fichero original).

El asunto de la fragmentación del sistema de archivos puede tener su importancia. Al fin y al cabo InterBase no asigna espacio por adelantado a los archivos que constituirán la base de datos (al estilo Oracle y similares).

Empezado por enlavin

Leyendo un documento de uno de los moderadores de este foro decidimos empezar a utilizar "gfix -sweep" por las noches y parece que la BD contiene su tamaño. Aún así no estoy tranquilo del todo, ya que es un sistema en producción y esas cosas dan bastante yuyu.

Previo al gfix puedes hacer un backup de la base de datos, nunca está de más.

Empezado por enlavin

1- Utilizando los componentes estándar de Delphi5, ¿con {Edit|Append}/Post es suficiente para finalizar una transacción o es necesario realizar las operaciones en el contexto de una transacción de forma explícita (StartTransaction + {Edit|Append}/Post +Commit)?

Eso depende de los componentes de acceso que estés utilizando (y de cómo estén configurados). En general, abren transacciones implícitas (si tú no las abres explícitamente) y las cierran con una desconexión (controlada) de la base de datos o un cierre (controlado) de Dataset... Otro asunto es cómo las cierran: algunos (por defecto) llevan a cabo un rollback otros un commit.

De todas formas, este asunto es tema a discutir en el foro: "Conexión con bases de datos"; allí se tratan los asuntos referentes a los componentes de acceso (incluidos los propios de InterBase).

Empezado por enlavin

¿Si no hago commit se me quedan transacciones en el limbo?

Sí, si el servidor no hace el commit y la transacción involucra a varias bases de datos. Las transacciones en estado limbo están asociadas a transacciones que operan contra dos o más bases de datos y no hayan superado la segunda fase de un commit en dos fases.

Empezado por enlavin

2- ¿Usar gfix es la forma correcta de hacer las cosas para que la BD no crezca desmesuradamente?

Es un mecanismo (que funciona con mejor o peor eficacia en función del estado de la base de datos), otro es el backup/restore.

Empezado por enlavin

¿Por qué no se hace el sweep solito sin que nadie se lo diga?

Y lo hace, todo depende del valor fijado para el intervalo de sweeping. Por defecto se fija a una diferencia de 20,001 unidades entre el identificador de la OIT (Oldest Interesting Transaction) y el identificador que se asignará a la próxima transacción. Puedes bajarlo y hacer que el sweeping se lance automáticamente con más frecuencia, pero con el riesgo de repercutir en la respuesta del servidor a los clientes si la diferencia se alcanza en un momento de actividad en el sistema (por ejemplo durante el horario laboral).

Empezado por enlavin

3- ¿Alguno ha observado la degeneración de rendimiento que comento más arriba?

En esto foros se ha comentado más de una vez.

Empezado por enlavin

¿Es un mal inevitable o con la recolección de basura se soluciona? En nuestro caso aparece aproximadamente después de 1-2 semanas después del último restore.

Más que un "mal inevitable", yo hablaría de un hecho inevitable. Bueno, tal vez no haya que ser tan categóricos y en un futuro se pueda utilizar la asignación de espacio (en el sistema de archivos) por adelantado. También es buena idea evitar, en la medida de lo posible, el uso de los métodos commit_retaining y rollback_retaining.

Empezado por enlavin

Bendito sea el que haya llegado leyendo hasta aquí

Yo me he ganado la bendición

Empezado por enlavin

Muchas gracias por vuestro tiempo.

Y por el tuyo.

Saludos.

[enlavin]

Empezado por kinobi

Hola y bienvenido,

Gracias

Empezado por kinobi

Si te refieres a si ese espacio es devuelto al sistema de archivos estás en lo cierto, no es devuelto. Si por el contrario te refieres a si ese espacio puede ser aprovechado para almacenar información nueva en la base de datos, el propio servidor lo "reclamará" según lo vaya necesitando.

Efectivamente. No me supone un problema el que el .GDB crezca lo suficiente como para tener un rendimiento óptimo (no tener que volver a pedir páginas al S.O. reutilizando el espacio previamente reservado). El problema viene del crecimiento progresivo (monotono creciente? ) que obliga cada cierto tiempo a detener el sistema para hacer un backup/restore. Ya comenté que eso no me conviene dado que van a ser sistemas autónomos sin operador y sin ninguna conectividad. Aunque siempre se puede hacer el backup programáticamente prefiero una solución más simple.

Empezado por kinobi

Algo habitual en bases de datos InterBase con mucha actividad (altas y actualizaciones).

Sip, eso he leido ya en varios sitios.

Empezado por kinobi

Eso depende de los componentes de acceso que estés utilizando (y de cómo estén configurados). En general, abren transacciones implícitas (si tú no las abres explícitamente) y las cierran con una desconexión (controlada) de la base de datos o un cierre (controlado) de Dataset... Otro asunto es cómo las cierran: algunos (por defecto) llevan a cabo un rollback otros un commit.

De todas formas, este asunto es tema a discutir en el foro: "Conexión con bases de datos"; allí se tratan los asuntos referentes a los componentes de acceso (incluidos los propios de InterBase).

Es lo que imaginaba. Cojo la (in)directa y a partir de ahora haré las preguntas en su sitio

Empezado por kinobi

Sí, si el servidor no hace el commit y la transacción involucra a varias bases de datos. Las transacciones en estado limbo están asociadas a transacciones que operan contra dos o más bases de datos y no hayan superado la segunda fase de un commit en dos fases.

Eso también lo he observado, sobre todo porque por un error de programación no terminábamos una transacción.

Empezado por kinobi

Y lo hace, todo depende del valor fijado para el intervalo de sweeping. Por defecto se fija a una diferencia de 20,001 unidades entre el identificador de la OIT (Oldest Interesting Transaction) y el identificador que se asignará a la próxima transacción. Puedes bajarlo y hacer que el sweeping se lance automáticamente con más frecuencia, pero con el riesgo de repercutir en la respuesta del servidor a los clientes si la diferencia se alcanza en un momento de actividad en el sistema (por ejemplo durante el horario laboral).

La puñeta del "sweep interval" es que no es predecible.

Las conclusiones que hemos sacado de esto en el trabajo es que en nuestro caso es preferible dejar el "sweep interval" a 0 y ejecutar "gfix -online -sweep" todos los días en horas de baja carga (madrugada normalmente). De esta forma el sweep reduce en mucho el rendimiento de la BD, pero sigue online y sabemos a qué hora va a pasar.

Llevo experimentando con una instalación desde hace 1 semana y los .GDB no han aumentado de tamaño

Empezado por kinobi

Yo me he ganado la bendición

Ya te digo !

Seguiré visitando estos foros (que no conocía) porque hay mucha y buena información. Muchas gracias por la respuesta.

Nos vemos!

Empezado por kinobi

Juan J. Rodríguez (127.0.0.1, sweet 127.0.0.1)

PD: jeje, graciosa la firma.

[guillotmarc]

Hola.

Por lo que dices, yo revisaria las transacciones. En Interbase/Firebird se produce una caída importante del rendimiento cuando se acumulan muchas operaciones en una misma transacción. Como comenta Juan José, debes evitar los CommitRetaining y realizar Hard Commits, al menos al llegar sobre los mil registros no confirmados.

NOTA : Yo tengo una aplicación 24x7 funcionando desde hace más de un año, y Firebird se comporta muy bien, como mínimo hace 6 meses que no me acerco por allí (controla el tráfico marítimo de un importante puerto del Mediterraneo).

Saludos.

[enlavin]

Hola guillotmarc,

La lentitud que he observado no parece que esté directamente relacionada con transacciones grandes. En nuestro sistema no suelen verse involucradas más de 10 o 20 tuplas de una tabla por transacción.

Más bien parece provenir de la gran cantidad de actualizaciones de registros que hacemos al cabo del dia (unas 200000). En algún sitio leí que eso podía afectar al balanceo de los índices. He observado que una reconstrucción diaria de los mismos agiliza sensiblemente las consultas, a cambio de perder un poco de rendimiento en los momentos puntuales donde se reconstruyen.

Gracias por la respuesta

Nos vemos.