Hola y bienvenido,
Cita:
|
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.
Cita:
|
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.
Cita:
|
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).
Cita:
|
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).
Cita:
|
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.
Cita:
|
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).
Cita:
|
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.
Cita:
|
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.
Cita:
|
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).
Cita:
|
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.
Cita:
|
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.
Cita:
|
Empezado por enlavin
Bendito sea el que haya llegado leyendo hasta aquí  |
Yo me he ganado la bendición
Cita:
|
Empezado por enlavin
Muchas gracias por vuestro tiempo.
|
Y por el tuyo.
Saludos.