¿Cómo las bases de datos de Firebird aumentan de tamaño?

Deja un comentario

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:

  1.  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
  2. Porque como el Firebird aloja el espacio en páginas esos continuos alojamientos fragmentarían excesivamente al disco duro
  3. 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.

ESTRUCTURA1

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 lo tanto 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, salvo que haya sido cambiada.

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:

El índice del blog Firebird21

El foro del blog Firebird21

 

Especificando el archivo FIREBIRD.MSG que queremos usar

Deja un comentario

Este artículo está basado en el artículo:

http://www.firebase.com.br/fb/artigo.php?id=2644

Cuando instalamos al Firebird se copia en el disco duro un archivo llamado FIREBIRD.MSG que contiene los mensajes que mostrará el propio Servidor del Firebird y también algunos de los programas utilitarios que vienen incluidos en la instalación, tales como el GBAK.EXE, el GFIX.EXE, etc.

Si en la computadora hemos instalado solamente una versión del Firebird entonces no tendremos problema, siempre veremos los mensajes correctos, pero si hemos instalado al Firebird más de una vez entonces podremos encontrarnos con un mensaje similar al siguiente:

can't format message...

gbak: writing data for table @1
gbak:@1 records written

¿Qué significa eso?

Que no puede encontrar al archivo FIREBIRD.MSG o que el archivo FIREBIRD.MSG que encontró no corresponde a la versión del Firebird que se está ejecutando.

¿Cómo lo resolvemos?

Configurando a una variable de ambiente llamada FIREBIRD_MSG con la ruta completa al archivo FIREBIRD.MSG que queremos usar, así:

MSG1

Captura 1. Si haces clic en la imagen la verás más grande

Y a continuación podemos llamar al utilitario GBAK.EXE, al utilitario GFIX.EXE, etc. y todos los mensajes aparecerán correctamente formateados.

Alternativa:

La forma de resolverlo mostrada arriba siempre funcionará pero si queremos que funcione sin necesidad de configurar a la variable de ambiente FIREBIRD_MSG deberemos hacer lo siguiente:

  • Copiar el archivo FIREBIRD.MSG en la carpeta superior de donde se encuentra el archivo FBCLIENT.DLL

En Windows lo aconsejable es que el archivo FBCLIENT.DLL se encuentre en la misma carpeta en la cual se encuentra el .EXE de nuestra aplicación.

Por lo tanto, en la misma carpeta donde se encuentra nuestro ejecutable CONTA.EXE, STOCK.EXE, VENTAS.EXE, SUELDOS.EXE, etc. copiamos al archivo FBCLIENT.DLL y en la carpeta superior copiamos al archivo FIREBIRD.MSG

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

Evitando que el tamaño de la Base de Datos se incremente demasiado

4 comentarios

Como Firebird usa la arquitectura MGA el tamaño de sus bases de datos puede crecer mucho y muy rápido.

La arquitectura MGA es muy buena para nosotros porque nos permite regresar la Base de Datos a su estado anterior. Cada vez que se modifica o se borra una fila esta arquitectura guarda una copia de la fila original. De esa manera siempre tenemos disponible la última versión de la fila y la ante-última versión de la fila. Y con los comandos COMMIT y ROLLBACK decidimos cual de esas versiones queremos usar.

En algunas transacciones nuestros cambios afectan a solamente una fila, pero en otras transacciones podrían afectar a decenas, miles, o millones de filas. Y gracias a MGA no debemos preocuparnos porque si queremos retrotraer la Base de Datos a su estado anterior, un simple comando ROLLBACK hará la tarea por nosotros.

Pero no todo son ventajas, también MGA tiene sus desventajas. Y es que esas filas que se fueron agregando con cada comando UPDATE o DELETE que ejecutamos van ocupando espacio dentro de la Base de Datos haciendo que se vuelva cada vez más grande. Y al volverse más grande también muchas operaciones se vuelven más lentas. El conjunto de todas esas filas que están dentro de la Base de Datos pero que ya son totalmente inútiles se llama “basura”.

La buena noticia es que podemos eliminar a la basura muy fácilmente. La mala noticia es que requiere de tiempo, no es algo instantáneo. Como consecuencia, lo recomendable es que la basura sea eliminada cuando nadie usa la Base de Datos. Si esto no es posible, entonces se debe eliminarla el día o la hora en que menos usuarios estén conectados (por ejemplo, todos los Domingos a las 23:00)

Entonces, nuestra tarea de mantenimiento tiene 2 partes:

  1. Un ciclo backup/restore
  2. Un barrido de la basura

El ciclo backup/restore nos asegura que solamente la última versión de cada fila se encuentra en la Base de Datos. Por lo tanto su tamaño disminuirá. Y en ocasiones la disminución es asombrosa, una Base de Datos de 350 Mb podría pasar a tener 40 Mb cuando el ciclo finaliza.

El barrido de la basura nos permitirá evitar que el tamaño de la Base de Datos crezca sin control. Si periódicamente hacemos un barrido entonces siempre tendremos una Base de Datos en muy buen estado de salud. Podríamos barrer un vez al día, o quizás una vez a la semana, ya dependerá de la cantidad de transacciones que durante ese tiempo ocurrieron. Un método es el siguiente:

  1. Detener el Servidor del Firebird
  2. Reiniciar el Servidor del Firebird (no debería durar ni 5 segundos el ciclo detener/reiniciar)
  3. Abrir la ventanita “Símbolo del sistema”
  4. Ejecutar el comando: GFIX -sweep -user SYSDBA -password masterkey MiBaseDatos

Realizar un ciclo backup/restore puede ser muy complicado en las empresas que trabajan 24/7/365, en cambio el barrido de la basura es más factible de encontrar el momento adecuado para hacerlo.

Sea como sea, mantener la Base de Datos con poca o nada de basura es una tarea muy importante, que está implícita cuando se trabaja con Firebird, y que debe realizarse sí o sí, no hay excusas, al menos si queremos que los tiempos de respuesta que obtienen los usuarios sean aceptables.

Artículos relacionados:

La arquitectura MGA

Entendiendo sweep y garbage collection

El índice del blog Firebird21

El foro del blog Firebird21

 

Pasos a seguir para actualizar la versión de Firebird

7 comentarios

En ocasiones ocurre que necesitamos cambiarnos a una versión más nueva del Firebird. Por ejemplo, estamos usando Firebird 1.5 y ahora queremos usar Firebird 2.5.2 ¿Qué debemos hacer en ese caso?

  1. Cerrar todas las conexiones a las bases de datos
  2. Backup con la versión vieja
  3. Verificación con la versión vieja
  4. Detener el Servidor del Firebird
  5. Iniciar la nueva versión del Servidor del Firebird
  6. Restaurar las bases de datos
  7. Actualizar las librerías cliente (el archivo FBCLIENT.DLL) en cada computadora cliente

Paso 1. Cerrar todas las conexiones a las bases de datos

Todos los usuarios deben desconectarse, nadie debe estar conectado. Para asegurarnos que después de todos haberse desconectado nadie más intente conectarse podríamos renombrar a la Base de Datos. Como los usuarios desconocen el nuevo nombre de la Base de Datos jamás conseguirán la conexión. Otra opción es usar el programa GFIX.EXE con la opción -force

Paso 2. Backup con la versión vieja

Esta siempre es una elemental medida de precaución porque si por cualquier motivo algo saliera mal entonces podríamos recuperar el 100% de nuestras bases de datos.

Paso 3. Verificación con la versión vieja

Siempre debemos verificar que los backups puedan ser restaurados exitosamente. Jamás debemos confiar en que se encuentran en buen estado, siempre debemos verificar que sea así antes de continuar. Si no verificamos nuestros backups podríamos encontrarnos con sorpresas muy desagradables cuando los necesitemos.

Entonces, se restaura el backup, y si no aparece algún mensaje de error durante la restauración eso significa que todo está ok

Paso 4. Detener el Servidor del Firebird

Una vez que hicimos un backup, verificamos que se encuentra en perfecto estado, y nos aseguramos de que nadie esté conectado a la Base de Datos, debemos detener el Servidor del Firebird. Si no lo hacemos, el Servidor podría continuar realizando tareas dentro de la Base de Datos sin que se las hayamos pedido (por ejemplo: un sweep, o una reindexación) y cuando nos conectemos con la nueva versión del Firebird habrá dos versiones accediendo a la misma Base de Datos y eso solamente puede ocasionar corrupción.

La probabilidad de que tal cosa ocurra no es alta pero ¿para qué dejar abierta la puerta a los problemas cuándo es tan fácil detener el Servidor del Firebird y asegurarnos de que no tendremos problemas?

Además, como seguramente sabes, puedes tener a dos o más versiones del Servidor del Firebird ejecutándose en la misma computadora. A veces es necesario que sea así. Pero si estás seguro de que ya no necesitarás a la versión vieja lo mejor es desinstalarla y así evitarás toda posibilidad de corrupción, porque si dos Servidores acceden a la misma Base de Datos en el mismo momento eso provoca corrupción.

Entonces ¿ya no necesitarás a la versión vieja del Firebird? desinstálala. ¿No estás seguro? desinstálala, porque siempre podrás volver a instalarla cuando la necesites

Paso 5. Iniciar la nueva versión del Servidor del Firebird

Ya el Servidor de la versión vieja está detenido, entonces podemos iniciar el Servidor de la versión nueva.

Paso 6. Restaurar las bases de datos

Las bases de datos originales no pueden (o no deben) ser usadas. Lo que debemos hacer es restaurarlas con la nueva versión del Firebird y así nos aseguraremos de que cuenten con todas las características de la nueva versión.

Recuerda: no uses la Base de Datos original, lo que debes hacer es restaurar su backup

Paso 7. Actualizar las librerías cliente (el archivo FBCLIENT.DLL) en cada computadora cliente

 Con el Paso 6. se terminó todo lo que le compete al Servidor, pero la tarea aún no está finalizada, porque todavía falta actualizar el archivo FBCLIENT.DLL en cada computadora que se conecta a las bases de datos.

 Si intentamos conectarnos a una Base de Datos administrada por un Servidor 2.5.2 con un Cliente 1.5 eso solamente nos causará problemas. Para conectarnos a un Servidor 2.5.2 debemos usar un Cliente 2.5.2

Conclusión:

Si queremos usar una versión más nueva del Firebird hay algunos pasos que debemos seguir, si no lo hacemos así entonces o no podremos conectarnos o perderemos datos, o corromperemos la Base de Datos. Y ninguna de esas opciones es buena.

Hacer el backup y la restauración no es algo instantáneo, puede tomar mucho tiempo, horas inclusive en bases de datos muy grandes, así que debemos realizarlos en los días o en los horarios en que menos usuarios suelen conectarse.

Artículo relacionado:

El índice del blog Firebird21

 

Mejorando el rendimiento de las bases de datos (4)

Deja un comentario

En este momento los sistemas operativos son de 32 bits o de 64 bits (dentro de unos años también existirán los de 128 bits).

Algo que podemos hacer para mejorar el rendimiento de nuestras bases de datos es instalarlas en computadoras de 64 bits. Resumiendo:

- La computadora que actuará como Servidor debe ser de 64 bits

- El sistema operativo de la computadora Servidor debe ser un Server de 64 bits (Windows Server, Ubuntu Server, etc.)

- No importa si nuestra aplicación es de 32 bits o de 64 bits.

¿Por qué?

Si la Base de Datos se encuentra en una computadora de 64 bits con un sistema operativo de 64 bits entonces todas las operaciones en ella se ejecutarán mucho más rápido que si se encuentra en una computadora de 32 bits con un sistema operativo de 32 bits. ¿La razón? que las computadoras de 64 bits pueden direccionar mucha más memoria que las de 32 bits. Y como seguramente sabrás, cuanta más memoria libre está disponible para que la use un programa ese programa corre más rápido.

Computadora de 32 bits puede direccionar como máximo 2 ^ 32 = 4.294.967.296

Computadora de 64 bits puede direccionar como máximo 2 ^ 64 = 18.446.744.073.709.550.000

Como puedes ver, la de 64 bits es monstruosamente grande comparada con la de 32 bits.

Entonces, aunque la aplicación sea de 32 bits y se ejecute en una computadora de 32 bits si la Base de Datos se encuentra en una computadora de 64 bits con un sistema operativo de 64 bits, se obtiene un gran beneficio.

Desde luego que para que lo anterior sea cierto la computadora donde se encuentra el Servidor debe tener más de 4 Gigabytes de memoria RAM o no habrá mucha diferencia. Pero en esta época lo normal es que todas las computadoras de 64 bits cuenten con más de 4 Gigabytes de memoria RAM.

Artículos relacionados:

Mejorando el rendimiento de las bases de datos (1)

Mejorando el rendimiento de las bases de datos (2)

Mejorando el rendimiento de las bases de datos (3)

El índice del blog Firebird21

 

 

 

 

 

Manteniendo la Base de Datos en buen estado

2 comentarios

Las bases de datos de Firebird es difícil que se corrompan, pero no imposible. Después de todo se trata de archivos de computadora y no existe una fórmula mágica que las salve de la corrupción.

La corrupción puede deberse a:

  • Problemas de hardware
  • Problemas de software
  • Problemas de mantenimiento

Problemas de hardware

  1. Apagado anormal. Es muy raro pero puede ocurrir, sobre todo si FORCED WRITES está en OFF. En Windows siempre debería estar en ON porque el Windows puede tardar mucho tiempo en guardar físicamente en el disco lo que se le pidió que guarde físicamente en el disco. Ese “mucho tiempo” puede ser minutos, horas, e incluso días.
  2. Disco duro levemente dañado. Ocurre cuando solamente algunos clusters se dañan y tuviste la mala suerte de que tu Base de Datos esté usando algunos de esos clusters. El sistema operativo los marca como dañados y no lee el contenido. Esto provoca que algunas partes de la Base de Datos no puedan ser leídas. Por ejemplo, se pueden leer algunas filas de una tabla, pero no todas las filas.
  3. Disco duro fuertemente dañado. Quizás a causa de una fuerte caída, un incendio, cosas así. En estos casos puedes utilizar un programa como R-Studio que encontrarás en: http://www.data-recovery-software.net/ o llevar el disco duro a alguna empresa que se especializa en recuperar discos duros dañados, pero el problema con esta última opción es que puede ser muy cara, nunca cobran por debajo de los 1.000 dólares por su servicio.
  4. Memoria RAM dañada. Esta es la peor de todas las posibilidades, porque es aleatoria. Un día todo puede funcionar perfecto (porque la Base de Datos no se alojó en la parte de la RAM que está dañada) y otro día tienes problemas a cada rato (porque la Base de Datos se alojó justo en la parte de la RAM que está dañada) para que al siguiente día todo parezca estar normal nuevamente. Además, cuando el problema está en el disco duro es toda una página la que se torna inaccesible pero en el caso de la RAM puede ser solamente un bit que cambió de 0 a 1 ó viceversa. Eso hace que pueda pasar muchísimo tiempo hasta que detectes que algo está mal. ¿Qué implica esto? que en general solamente descubres el problema cuando el daño ya es demasiado grande, cuando ya se volvió crítico.
  5. Insuficiente espacio en el disco duro para la Base de Datos. Esto ya es total responsabilidad del Administrador de la Base de Datos, no puede jamás permitir que tal cosa ocurra. El problema aparece cuando el Servidor quiere agregarle más páginas a la Base de Datos pero no hay suficiente espacio libre en el disco duro o en la partición. La situación más peligrosa sucede cuando la falta de espacio en el disco duro es combinada con un caché muy grande y con FORCED WRITES en OFF porque el sistema operativo trata de guardar muchos datos en el disco duro y falla porque no le alcanza el espacio libre.
  6. Insuficiente espacio en el disco duro para los archivos temporales. Nuevamente, esto es total responsabilidad del Administrador de la Base de Datos. Firebird utiliza archivos temporales para ordenar los resultados de las consultas, esos archivos temporales solamente existen mientras se está ordenando y luego desaparecen pero si el ordenamiento envuelve a millones de filas, pueden requerir de mucho espacio en el disco duro.
  7. Insuficiente espacio en el disco duro para el archivo FIREBIRD.LOG. En este archivo se guardan los mensajes relacionados con el funcionamiento de Firebird, puede tener miles y miles de filas y si la Base de Datos tiene algún problema esas filas con mensajes se multiplican.

Problemas de software

  1. Creando y borrando tablas mientras la Base de Datos está siendo usada. Esta es la forma más fácil de corromper una Base de Datos porque el Firebird puede confundirse y escribir en las páginas del sistema (usadas para crear y borrar tablas) lo que debería escribir en las páginas de datos. O viceversa.

Problemas de mantenimiento

  1. Se borró la Base de Datos. Si nadie la está usando puede ser borrada, al igual que cualquier otro archivo de la computadora. A veces ocurre lo siguiente: se hace un backup, y se borra la Base de Datos original, confiando en el backup. Pero el backup por alguna razón está corrupto y entonces no sirve y tampoco se puede usar la Base de Datos original porque ya fue borrada.

Detectando problemas

La forma más rápida de detectar problemas es revisando el archivo FIREBIRD.LOG, si allí encontramos cualquier cosa inusual (por ejemplo, errores 10054) entonces hay algo mal en la Base de Datos y debemos solucionarlo lo antes posible.

¿Qué significa esto?

Que todos los días deberíamos echarle un vistazo al archivo FIREBIRD.LOG porque cuanto más rápido detectemos los problemas menos daños causarán.

También podemos utilizar programas especializados, como el IBSurgeon FirstAid

Solucionando problemas

Si encuentras que una Base de Datos está dañada, esto es lo que debes hacer:

  1. Detener el Servidor del Firebird. Porque más accesos y operaciones en la Base de Datos dañada solamente pueden provocar más daños, nunca menos daños
  2. Hacer un backup de la Base de Datos. Haz este backup con programas como 7Zip, WinZip, WinRar, etc.
  3. Utilizar el backup para intentar la recuperación. Siempre debes mantener el archivo original a salvo, trabaja con el backup
  4. Escribe los siguientes comandos para intentar repararla. Estos son los comandos estándar que se usan para reparar bases de datos dañadas.

Para validar la Base de Datos (recuerda que debes usar el archivo de backup, no el archivo original):

gfix –v –full –user SYSDBA -password MiPassword MiBaseDatosCorrupta.FDB

Si el comando de arriba detectó algún problema entonces debemos eliminar esos problemas:

gfix –mend –user SYSDBA –password MiPassword MiBaseDatosCorrupta.FDB

Repetir los dos comandos anteriores hasta que ya no se detecten problemas. Cuando está todo ok hay que hacerle un backup, porque al hacer un backup pueden detectarse otros problemas:

gbak –b –v -ig –user SYSDBA –password MiPassword MiBaseDatosCorrupta.FDB MiBackup.FBK

Si apareció algún error entonces debemos realizar otro backup, pero sin la recolección de basura:

gbak –b –v -ig –g -user SYSDBA –password MiPassword MiBaseDatosCorrupta.FDB MiBackup.FBK

A veces hacer que la Base de Datos sea de solo lectura (o sea: read only) puede ayudar a recuperarla.

gfix –mode read_only  –user SYSDBA -password MiPassword MiBaseDatosCorrupta.FDB

Si el backup finalizó exitosamente, entonces se lo restaura desde la copia:

gbak –c –user SYSDBA –password MiPassword MiBaseDatosCorrupta.FDB MiBaseDatosRestaurada.FDB

Conclusión:

Las bases de datos de Firebird son archivos de computadora y como cualquier otro archivo pueden dañarse. Los causantes pueden ser problemas de hardware, problemas de software o un mantenimiento inadecuado. Sea cual sea la razón, si detectamos que una Base de Datos está dañada debemos intentar repararla lo antes posible porque si se la continúa usando eso solamente ocasionará más daños.

No siempre se puede reparar una Base de Datos. Por lo tanto es importantísimo que al menos una vez por día se haga un backup de la misma para que la pérdida no sea muy grande si se concluye que es imposible repararla.

Artículo relacionado:

El índice del blog Firebird21

Usando dos servidores para aumentar la velocidad de las operaciones

Deja un comentario

Generalmente los usuarios quieren velocidad, quieren que las operaciones que realizan en la Base de Datos (SELECT, INSERT, UPDATE, DELETE) sean muy rápidas.

Una técnica que podemos emplear para aumentar la velocidad (además de la optimización de las consultas, que ya hemos visto en otros artículos de este blog) es tener en la misma computadora dos (o más) servidores instalados.

Como seguramente sabes, Firebird viene en tres arquitecturas: Classic, SuperClassic y SuperServer.

El problema con SuperServer es que mantiene un caché para todas las conexiones. O sea que si una Base de Datos tiene 40 conexiones, hay un solo caché para las 40 conexiones. Y si alguien está ejecutando una transacción o una consulta muy larga eso crea un “cuello de botella” para todos los demás usuarios, haciendo que sus operaciones se vuelvan muy lentas. Pero la gran ventaja de usar un solo caché es que si el usuario 2 quiere hacer la misma consulta que ya hizo el usuario 1 los datos de esa consulta ya muy probablemente se encuentran en el caché y por lo tanto no deben ser leídos del disco duro, proporcionando una gran velocidad (la memoria RAM es miles de veces más rápida que la memoria secundaria).

Como ves, usar SuperServer o usar Classic tiene sus ventajas y sus desventajas.

Entonces, ¿cuál es la mejor solución?

Usar dos servidores.

Un Servidor con la arquitectura SuperServer se usará para el mantenimiento de los datos de la Base de Datos y para las consultas rápidas. Un Servidor con arquitectura Classic se usará para las consultas lentas (que son lentas porque deben procesar muchos datos, no porque están mal diseñadas que ese es otro tema).

Para que esta técnica funcione sin problemas un solo Servidor será el encargado de las operaciones de mantenimiento de los datos (INSERT, UPDATE, DELETE). ¿Por qué? porque si los dos servidores pueden hacerlo podrían ocurrir conflictos y corromperse la Base de Datos. Por lo tanto hay que evitar esa posibilidad.

Entonces:

  • SuperServer se encargará de las operaciones de INSERT, UPDATE, DELETE y SELECTs rápidos
  • Classic se encargará de los SELECTs lentos

Como Classic usa un caché por cada conexión si un usuario está realizando una consulta muy lenta eso no les afectará a los demás usuarios.

¿Entonces, qué conseguimos con esto?

Que todos estén felices.

Los gerentes y los propietarios de las empresas generalmente se conectan a las bases de datos para realizar consultas. Entonces ellos siempre usarán Classic.

Los operadores se encargan de introducir datos y de imprimir informes de comprobación. Para la introducción de datos y para la impresión de informes cortos, usarán SuperServer; para la impresión de los informes que tendrán muchas páginas o que requieren de mucho procesamiento, usarán Classic.

Artículos relacionados:

Modelos de ejecución del Firebird y sus diferencias

Comparando las arquitecturas

Diferencias entre SuperServer, Classic y SuperClassic

El índice del blog Firebird21

Older Entries

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 176 seguidores