El tamaño que ocupan en el disco duro las Bases de Datos de Firebird no es tan sencillo de conocer como a primera vista se podría uno imaginar.
Cuando creas una Base de Datos de Firebird ésta no está vacía sino que ya tiene dentro suyo muchas tablas que luego serán usadas durante las tareas que se realicen en esa Base de Datos. A esas tablas internas se las conoce como «metadatos«.
Entonces, lo primero que notarás después de crear una Base de Datos si miras su tamaño es que éste es de cientos de kilobytes. Eso es debido a los metadatos. Está ok, así tiene que ser.
Luego, tú o los usuarios empiezan a realizar operaciones de manipulación de datos (inserciones, modificaciones, borrados) y allí puedes notar algo curioso: el tamaño de la Base de Datos parece ser muy grande para la cantidad de filas que hay en las tablas.
¿Por qué?
Porque cuando el Firebird necesita que la Base de Datos tenga más espacio para las filas que estás insertando, modificando o borrando no aloja espacio solamente para esa fila en particular sino que aloja mucho más espacio.
¿Y por qué hace eso, por qué no aloja solamente el espacio en disco exactamente necesario?
Por tres motivos:
- Porque la tarea de alojar más espacio lleva tiempo, no es instantánea. Si cada vez que se inserta una nueva fila tendría que estar alojando espacio en el disco duro para esa fila entonces esas inserciones demorarían demasiado tiempo en bases de datos donde hay muchas inserciones concurrentes y los usuarios se quejarían de la extrema lentitud
- Porque como el Firebird aloja el espacio en páginas esos continuos alojamientos fragmentarían excesivamente al disco duro
- Porque si el disco duro se queda sin espacio entonces hay una gran posibilidad de que la Base de Datos aún tenga suficiente espacio libre previamente alojado para que pueda terminar todas las operaciones que se estaban realizando en ella, sin corrupción.
Entonces, alojar más espacio del necesario, para tener bastante espacio libre disponible tiene tres grandes ventajas: a) se consigue una gran rapidez en todas las operaciones de inserción, modificación, borrado, porque el espacio ya está disponible, b) no se fragmenta excesivamente el disco duro y c) si el disco duro se queda sin espacio libre es muy probable que la Base de Datos no se corrompa porque los datos que faltaban grabarse se grabarán en el espacio previamente alojado.
Claro que esto también tiene sus desventajas. Estas son: a) cada vez que hay que alojar más espacio ocurre una demora, y b) la Base de Datos puede estar ocupando en el disco duro mucho espacio y si la cantidad libre en el disco duro es escasa eso afectará a los otros programas.
Claro que la desventaja b) es muy improbable que ocurra en esta época en que los discos duros son gigantescos y muy baratos, además si se cuenta con un Administrador que verifique el espacio libre en el disco duro nunca debería ocurrir algo así.
Un gráfico que ilustra el concepto
En este gráfico podemos ver como se aloja el espacio en una Base de Datos de Firebird.
Gráfico 1. Si haces clic en la imagen la verás más grande
El espacio en C) está libre, nada hay ahí pero ya está asignado a la Base de Datos y para el Sistema Operativo es espacio ocupado por la Base de Datos y por ese motivo no puede ser usado por otros archivos. Cuando los usuarios insertan, modifican, o borran filas, esas inserciones, modificaciones, o borrados ocurren en C) y cuando el espacio en C) ya es pequeño se aloja más espacio a la Base de Datos, para que siempre tenga espacio libre a su disposición. Pero siempre esos alojamientos sirven para alojar a cientos o a miles de filas, no son para alojar a una o a dos filas sino a cientos o a miles de ellas. O sea que cada vez que se aloja un nuevo C) hay suficiente espacio en él para cientos o miles de filas.
¿Y cuántos bytes se alojan cada vez que la Base de Datos requiere de más espacio?
Cuando el Servidor descubre que la Base de Datos ya casi no tiene espacio libre debe reservar más espacio para ella. En el gráfico anterior la parte B) va creciendo hacia arriba haciendo que la parte C) sea cada vez más pequeña. Es entonces que el Servidor le aloja más espacio, según esta fórmula:
Al tamaño actual de la Base de Datos lo divide por 16
Nunca aloja más espacio que el establecido en la entrada DatabaseGrowthIncrement del archivo FIREBIRD.CONF (que por defecto es 128 Mb) ni menos de 128 Kb
Ejemplos:
Si la Base de Datos tiene 16 Mb entonces aloja 1 Mb (o sea, el tamaño de la Base de Datos dividido 16)
Si la Base de Datos tiene 16 Gb entonces aloja 128 Mb. No aloja 1 Gb sino que aloja 128 Mb. ¿Por qué? porque ese es el valor de la entrada DatabaseGrowthIncrement (que indica cual es el incremento máximo), salvo que haya sido cambiada. Recuerda: Nunca aloja más que el incremento máximo.
Si la Base de Datos tiene 16 Gb y la entrada DatabaseGrowthIncrement tiene el valor 268435456 (que equivale a 256 Mb) entonces aloja 256 Mb.
¿Es conveniente aumentar o disminuir el valor de la entrada DatabaseGrowthIncrement?
En general, el valor por defecto de 128 Mb es bastante bueno para la gran mayoría de las situaciones y podríamos dejarlo así, pero en bases de datos que tienen muchísimo movimiento y crecen mucho y rápido puede ser conveniente aumentarlo, para que el Firebird no esté a cada rato alojando nuevo espacio. Disminuirlo no se justifica (salvo que el disco duro tenga poquísimo espacio libre) porque disminuir significa aumentar la fragmentación del disco duro algo que nunca es conveniente porque un disco duro fragmentado tarda más en ser leído.
El valor de la entrada DatabaseGrowthIncrement se expresa en bytes, no en megabytes. Por lo tanto en ella por defecto veremos el número 134217728 que equivale a 128 Mb.
Conclusión:
Para que las operaciones de mantenimiento de tablas (inserción, modificación, borrado) sean muy rápidas el Firebird les asigna a las bases de datos más espacio en el disco duro que el estrictamente necesario. Eso además tiene la ventaja de que es muy improbable de que ocurra corrupción porque si el disco duro se queda sin espacio libre es muy posible que la Base de Datos no, que aún tenga suficiente espacio libre previamente alojado para terminar exitosamente todas las operaciones que estaban realizando los usuarios.
Para saber cuantos bytes debe alojar cada vez que lo hace, el Firebird divide por 16 al tamaño actual de la Base de Datos. El tamaño mínimo que aloja es 128 Kb y el tamaño máximo que aloja lo determina la entrada DatabaseGrowthIncrement del archivo FIREBIRD.CONF que por defecto es de 128 Mb pero que puede ser cambiado. Si se cambia entonces lo aconsejable es aumentarlo porque disminuirlo aumentará la fragmentación del disco duro, algo que nunca es bueno.
Artículos relacionados:
Firebird SQL 
Dic 22, 2017 @ 16:26:40
Buenas tardes, tengo una pregunta, tengo una base de datos GDB pesa 270 megas, quiero borrar la informacion para utilizarla de nuevo para este año que comienza, pero a pesar q borro todo no baja de tamaño, es normal?
Dic 22, 2017 @ 17:35:02
Sí, es normal y es lo correcto, el espacio que ya se usó y luego se liberó continúa disponible para la Base de Datos. Se hace así porque es más rápido usar el espacio libre que tiene la Base de Datos que buscar en el disco duro espacio libre y asignarlo a la Base de Datos.
Por lo tanto, si tienes suficiente espacio en tu disco duro, déjalo así. Pero si tienes poco espacio libre en tu disco duro, con un ciclo backup/restore, la nueva Base de Datos ocupará el tamaño mínimo posible.
Saludos.
Walter.