Cita:
|
Empezado por kinobi
Hola y bienvenido,
|
Gracias
Cita:
|
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.
Cita:
|
Empezado por kinobi
Algo habitual en bases de datos InterBase con mucha actividad (altas y actualizaciones).
|
Sip, eso he leido ya en varios sitios.
Cita:
|
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
Cita:
|
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.
Cita:
|
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
Cita:
|
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!
Cita:
|
Empezado por kinobi
Juan J. Rodríguez (127.0.0.1, sweet 127.0.0.1)
|
PD: jeje, graciosa la firma.