Copiando completamente o parcialmente una Base de Datos (1)

1 comentario

A veces puedes querer copiar una Base de Datos completa, con todo su contenido, pero a veces puede interesarte copiar solamente una parte de ella. Por lo tanto, tus opciones serían:

  1. Copiarla totalmente. Con todos sus metadatos y todos sus datos
  2. Copiar solamente los metadatos. Es decir, su estructura
  3. Copiar todos los metadatos y el contenido de algunas tablas
  4. Copiar algunos metadatos y el contenido de algunas tablas

Como el tema es largo, será tratado en 2 artículos. En este veremos como realizar esas tareas manualmente, o sea sin usar un programa de administración gráfica y en el siguiente artículo usaremos un programa de administración gráfica.

Opción 1. Copiarla totalmente. Con todos sus metadatos y todos sus datos

Para este caso lo más recomendable es hacer un backup usando el programa GBAK. ¿Por qué es lo más recomendable? porque al hacer un backup con GBAK se elimina la basura que contenía la Base de Datos original y en el backup no hay basura, ni índices (que serán creados cuando se restaure el backup), y el identificador de todas las transacciones del backup es puesto en cero.


GBAK -b MiBaseDatos.FDB MiBackup.FBK -user SYSDBA -password masterkey

Si el Servidor del Firebird no está funcionando también se puede copiar la Base de Datos con el Explorador de Windows o algún programa similar. ¿Por qué el Servidor del Firebird no debe estar funcionando? Porque si lo está y alguien está conectado, la Base de Datos puede corromperse. Y si nadie está conectado existe el riesgo (pequeño, pero existe) de que el Servidor esté realizando alguna tarea en la Base de Datos (por ejemplo, un sweep). Por lo tanto, copiar con el Explorador del Windows solamente es seguro si el Servidor del Firebird está apagado.

Opción 2. Copiar solamente los metadatos. Es decir, su estructura

El programa GBAK tiene la opción -m la cual copia solamente los metadatos. Su sintaxis es:


GBAK -b -m MiBaseDatos.FDB MiBackup.FBK -user SYSDBA -password masterkey

Opción 3. Copiar todos los metadatos y el contenido de algunas tablas

Para este caso lo mejor es crear un archivo de script con el contenido completo de la Base de Datos y luego eliminar lo que no nos interesa, modificar lo que queremos cambiar, y dejar como está a lo demás.

El programa ISQL tiene una opción -extract que sirve para crear un script de toda la Base de Datos.

COPIAR04

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

En la Captura 1. vemos que todo el contenido de la Base de Datos DEISY.FDB fue copiado al archivo de script llamado DEISY.SQL

COPIAR05

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

El archivo de script DEISY.SQL por supuesto que es muchísimo más largo, en la Captura 2. se muestran solamente las primeras líneas.

Ahora, tenemos la posibilidad de eliminar lo que ya no nos interesa tener y de modificar cualquier cosa. Podemos cambiar el nombre o el contenido de los dominios, de las tablas, de los stored procedures, etc. Lo que se nos ocurra.

Después de haber eliminado y modificado todo lo que quisimos, para generar una nueva Base de Datos, debemos quitarle el comentario a la línea CREATE DATABASE, poner el nombre que tendrá la nueva Base de Datos, y el usuario y la contraseña que la creará.

COPIAR06

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

Para crear la Base de Datos llamada DEISY2.FDB, ingresamos a ISQL y con el comando INPUT ejecutamos el script. Todo lo que esté escrito dentro del script será ejecutado.

COPIAR07

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

Si todo está bien, la nueva Base de Datos será creada. Si hay algún error, habrá que encontrar cual es el error y corregirlo. Luego, se vuelve a intentar crear la Base de Datos.

Copiando solamente el contenido de algunas tablas

Hasta ahora hemos visto como copiar a una Base de Datos completa, con todos sus metadatos y todos sus datos. Pero ¿y si queremos copiar solamente el contenido de algunas tablas?

Para eso entramos a ISQL, nos conectamos a una Base de Datos, y usando el comando OUTPUT enviamos a un archivo de texto todo lo que hacemos, tal y como vemos a continuación:

COPIAR01

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

La primera línea le indica al ISQL que todo lo que se escriba a continuación se guarde en un archivo de texto. No se verá en la pantalla, sino que se guardará en el archivo cuyo nombre se escriba después de la palabra OUTPUT.

Ese nombre puede ser cualquiera y puede tener cualquier extensión. Para los datos se acostumbra a ponerle la extensión .DAT pero eso no es obligatorio.

El OUTPUT que se encuentra en la tercera línea se usa para que la salida vuelva a verse en la pantalla, o sea que dejará de enviarse al archivo de texto.

Entre el primer OUTPUT y el segundo OUTPUT puede haber muchas líneas, no solamente una como en este ejemplo.

En el contenido del archivo de texto BANCOS.DAT se verá algo como:

COPIAR02

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

Donde, como puedes ver, se muestra el nombre de cada columna y el contenido de cada fila.

Opción 4. Copiar algunos metadatos y el contenido de algunas tablas

Es igual a la Opción 3.

Conclusión:

Como has podido ver en este artículo, con Firebird tenemos la posibilidad de realizar backups completos o parciales de nuestra Base de Datos.

Enviar el backup a un archivo de script tiene la gran ventaja de que todo es legible y así podríamos revisar ese script y descubrir errores o mejoras que se podrían realizar.

Artículos relacionados:

Entendiendo a los scripts

Usando scripts para documentar la Base de Datos

Ejecutando un script desde Visual FoxPro

El índice del blog Firebird21

El foro del blog Firebird21

Haciendo backups con GBAK (3)

Deja un comentario

En artículos anteriores ya vimos mucho sobre la parte teórica de hacer backups en general, y de hacer backups con GBAK en particular, así que vayamos ahora a la parte práctica:

La sintaxis general de GBAK

GBAK <opciones> -USER <usuario> -PASSWORD <contraseña> <origen> <destino>

Opciones: con ellas le indicamos a GBAK lo que queremos hacer

Usuario: es el nombre del usuario que realizará el backup o la restauración. Debe ser SYSDBA o el creador de la Base de Datos o un usuario con el rol RDB$ADMIN.

Contraseña: es la contraseña del usuario que realizará el backup o la restauración

Origen: si se hará un backup es nombre completo de la Base de Datos (la cual generalmente tiene la extensión .FDB) o un alias definido en el archivo ALIASES.CONF; si se hará una restauración es el nombre completo del archivo de backup (el cual generalmente tiene la extensión .FBK)

Destino: si se hará un backup, es el nombre del archivo que será generado (generalmente con la extensión .FBK); si se hará una restauración es el nombre que tendrá la nueva Base de Datos (generalmente con la extensión .FDB)

Tipos de opciones

Las opciones de GBAK pueden ser de tres tipos:

  1. Opciones generales
  2. Opciones del backup
  3. Opciones de la restauración

Las opciones generales son las que se pueden usar en ambos casos (es decir, cuando se hace el backup o cuando se hace la restauración) y son las siguientes:

nodbtriggers Impide que se desencadenen los triggers de la Base de Datos.

-pas[sword] <contraseña> La contraseña que el usuario utiliza para conectarse a la Base de Datos. Alternativamente se puede usar -fet[ch_password] para no escribir la contraseña

-fet[ch_password] <nombre_archivo> En lugar de escribir la contraseña en la línea de comandos se puede extraerla de un archivo, de esta manera si hay un curioso mirando lo que escribes no podrá saber cual es tu contraseña

-m[etadata] Solamente hace el backup o la restauración de los metados, los datos introducidos por los usuarios serán ignorados

-role <nombre_del_rol> Si el usuario usó un rol

-se[rvice] <hostname[/port]>:service_mgr Cuando se está haciendo el backup: el archivo se crea en el Servidor, usando para ello al Service Manager. Cuando se está haciendo la restauración: la Base de Datos se crea en el Servidor, usando para ello el Service Manager. Tanto la Base de Datos como el archivo de backup como el archivo de log deben encontrarse en uno de los discos duros del Servidor y cuando se los especifica debe hacerse desde la perspectiva del Servidor, aún cuando se llame a GBAK desde una computadora remota. La ventaja de usar el Service Manager es que el backup y la restauración se hacen muy rápido.

-u[ser] Nombre del usuario de la Base de Datos

-v[erbose] Muestra en la pantalla lo que está haciendo GBAK

-y [nombre_archivo> Crea un archivo de log y escribe todos los mensajes de GBAK que normalmente se mostrarían en la pantalla en el archivo de log. El archivo de log no debe existir. Por lo tanto, si existe, hay que borrarlo antes de ejecutar a GBAK. Si se usa la opción -se[rvice] el archivo de log debe encontrarse sí o sí en uno de los discos duros del Servidor.

-y suppress No muestra los mensajes de GBAK en la pantalla ni los escribe en un archivo de log

-z Muestra la versión de GBAK y del Servidor del Firebird

Las opciones del backup son las que solamente se usan cuando se está realizando el backup y son las siguientes:

-b[ackup_database] Se desea realizar un backup. Es opcional.

-co[nvert] Convierte las tablas externas en tablas internas

-e[xpand] Crea un archivo de backup no comprimido. Por lo tanto, ocupará más espacio en el disco duro

-fa[ctor] n Factor de bloqueo para los dispositivos de cinta

-g[arbage_collect] No recolecta la basura durante el backup, por lo tanto el backup terminará más rápido. Debes usar esta opción cuando inmediatamente después del backup harás un Sweep

-ig[nore] Ignora los checksums mientras realiza el backup

-l[imbo] Ignora las transacciones en limbo mientras realiza el backup

-nt Formato no transportable. Debes usarlo solamente cuando estás 100% seguro que la restauración se hará en el mismo Sistema Operativo y con la misma versión del Firebird

-t[ransportable] Crea un backup que es transportable entre Sistemas Operativos y versiones del Firebird. Es la opción por defecto

Las opciones de la restauración son las que solamente se usan cuando se está restaurando el backup y son las siguientes:

-bu[ffers] Establece el tamaño del caché para la Base de Datos restaurada

-c[reate_database] Restaura a una nueva Base de Datos (el nombre de la nueva Base de Datos no debe existir)

-fix_fss_d[ata] Repara códigos UNICODE_FSS de los datos que estaban mal formados

-fix_fss_m[etadata] Repara códigos UNICODE_FSS de los metadatos que estaban mal formados

-i[nactive] Todos los índices son restaurados como inactivos

-k[ill] No crea los archivos de shadow que fueron definidos en el backup

-mo[de] read_write La Base de Datos restaurada será read/write (o sea: lectura y escritura). Es el valor por defecto

-mo[de] read_only La Base de Datos restaurada solamente podrá ser leída y no se podrán realizar cambios en ella

-n[o_validity] No restaura las restricciones de validación. Sirve para restaurar datos que no cumplen con las restricciones y que no podrían ser restaurados de otra manera

-o[ne_at_a_time] Lo normal es que la restauración se haga en una sola transacción para toda la Base de Datos. El problema es que si se encuentra algún error entonces ninguna tabla será restaurada. Con esta opción se abre una transacción para cada tabla y después de restaurarla se ejecuta el COMMIT. De esta manera se puede restaurar parcialmente una Base de Datos corrupta.

-p[age_size] <tamaño_página> Pone el tamaño de la página de la Base de Datos. Los valores posibles son 4096, 8192, 16384. El valor por defecto es 4096.

-r[eplace_database] Restaura sobre una Base de Datos existente. Esto solamente puede ser realizado por SYSDBA o por el creador de la Base de Datos que será sobre-escrita. ¡¡¡CUIDADO!!! No hay que restaurar sobre una Base de Datos que está siendo usada.

-rep[lace_database] Igual que la opción anterior. Es simplemente una nueva abreviación.

-r[ecreate_database] o[verwrite] Restaura sobre una Base de Datos existente. Solamente puede ser ejecutada por SYSDBA o por el creador de la Base de Datos que será sobre-escrita. Si la Base de Datos está siendo usada el Firebird te lo advertirá porque es algo que no deberías hacer, de todas maneras: debes ser cuidadoso

-use_[all_space] Normalmente cuando se realiza la restauración cada página de la Base de Datos es escrita en un 80%, en cambio si se usa esta opción cada página será llenada al 100%. Es muy útil cuando la Base de Datos restaurada será read-only (y por lo tanto ya no será modificada), porque ahorra mucho espacio en el disco duro.

Ejemplo Nº 1. Un backup normal

GBAK -v -USER SYSDBA -PASSWORD masterkey D:\BASESDATOS\CONTA.FDB D:\BACKUPS\CONTA.FBK

Si en el archivo ALIASES.CONF hemos definido CONTA=D:\BASEDATOS\CONTA.FDB también se podría escribir:

GBAK -v -USER SYSDBA -PASSWORD masterkey CONTA D:\BACKUPS\CONTA.FBK

La opción -v nos muestra en la pantalla lo que está haciendo GBAK.

Ejemplo Nº 2. Un backup con archivo de log

DEL D:\BACKUPS\CONTA.LOG

GBAK -v -USER SYSDBA -PASSWORD masterkey -y D:\BACKUPS\CONTA.LOG D:\BASESDATOS\CONTA.FDB D:\BACKUPS\CONTA.FBK

El archivo de log no debe existir, por eso se lo borra primero. Todo lo que GBAK hubiera mostrado en la pantalla será escrito en el archivo de log, así ese archivo podrá ser revisado cuando se lo necesite.

Ejemplo Nº 3. Una restauración normal

GBAK -c -v -USER SYSDBA -PASSWORD masterkey D:\BACKUPS\CONTA.FBK D:\BASESDATOS\CONTA2.FDB

La Base de Datos restaurada tiene un nombre distinto (CONTA2.FDB) al de la Base de Datos original (CONTA.FDB), esa es la práctica normal y la más recomendada.

Ejemplo Nº 4. Restaurando a una Base de Datos de sólo lectura

GBAK -c -v -mode read_only -use_all_space -USER SYSDBA -PASSWORD masterkey D:\BACKUPS\CONTA.FBK D:\BASESDATOS\CONTA3.FDB

Como -mode es read_only entonces la Base de Datos será de sólo lectura, y como será de sólo lectura entonces se establece que cada página esté llena al 100%, ahorrando así mucho espacio en el disco duro.

Ejemplo Nº 5. Backup y restauración al mismo tiempo

Es muy útil para verificar que el archivo de backup se encuentra en perfecto estado. Un archivo de backup que no se encuentra en perfecto estado puede ser inútil e inservible, por lo tanto una muy buena medida administrativa es verificar que está ok.

GBAK -c [opciones] <base_de_datos_origen> stdout | GBAK -r [opciones] stdin <base_de_datos_destino>

Como puedes ver aquí el programa GBAK se ejecuta dos veces:

  • La primera vez, en lugar de crear al backup en el disco duro (que es lo normal) lo crea en stdout que es la salida estándar (la cual por defecto es la pantalla de la computadora)
  • La barra vertical significa que el programa que se encuentre a continuación (y que en este caso también es GBAK pero podría ser otro) tome como entrada la salida del primer programa ¿en qué lugar? en donde se encuentre stdin
  • El primer GBAK crea el archivo de backup, el segundo GBAK restaura ese archivo de backup

Esta es una forma simplificada de realizar un ciclo backup/restore normal:

  • Con GBAK conectarse a una Base de Datos y crear un archivo de backup
  • Con GBAK leer el archivo de backup y crear una nueva Base de Datos

Artículos relacionados:

Entendiendo a las bases de datos

Entendiendo a los metadatos del programador

Los triggers de la Base de Datos

Haciendo backups con GBAK (1)

Haciendo backups con GBAK (2)

El índice del blog Firebird

El foro del blog Firebird21

 

Haciendo backups con GBAK (1)

2 comentarios

El Firebird nos permite realizar copias de seguridad (generalmente llamadas backups) de nuestras bases de datos de varias formas diferentes, tal como ya habíamos visto en:

https://firebird21.wordpress.com/2013/07/03/los-metodos-para-hacer-backup/

Cada uno de esos métodos tiene sus ventajas y sus desventajas, ninguno es perfecto (evidentemente, porque si uno fuera perfecto ¿para qué tendríamos los demás?).

En el presente artículo empezaremos a ver como hacer backups usando para ello el programa GBAK. Como el tema es muy largo, lo trataremos en varios artículos.

¿Qué es el ciclo backup/restore?

Todos sabemos que debemos realizar frecuentemente copias de seguridad de nuestra Base de Datos porque si ocurre un accidente (como el disco duro dañado), la única forma rápida y confiable de recuperar su contenido en todo o en gran parte es a través de una copia de seguridad actualizada. Este proceso tiene dos partes:

  1. Copiar todo el contenido de la Base de Datos en un archivo. A este paso se le llama realizar el backup.
  2. Usar el archivo de backup para obtener una Base de Datos operativa, a ese paso se le llama restaurar la Base de Datos.

Por lo tanto, el ciclo backup/restore significa: crear un archivo de backup y luego restaurarlo.

Hay que enfatizar que el proceso no está completo si solamente se realiza el backup. Hay que realizar ambos, sí o sí: el backup y el restore. O sea: la copia de seguridad y la restauración de esa copia.

¿Qué programa usaremos para realizar el ciclo backup/restore?

El programa se llama GBAK.EXE, y con él podremos:

  • Realizar el backup
  • Restaurar la Base de Datos

¿Qué tareas realiza GBAK.EXE?

Cuando hace el backup:

  • Lee todo el contenido de una Base de Datos y copia ese contenido en otro archivo. Pero no lo copia completo. Los índices por ejemplo no son copiados. Gracias a eso el tamaño de la copia es menor de lo que sería si los hubiera copiado.
  • No copia la basura en el backup (la Base de Datos original continúa con toda la basura que tenía)

Cuando restaura la Base de Datos:

  • Pone el TID de cada fila de cada tabla en 1. (El TID es un número que identifica a la transacción que creó la fila). Por lo tanto es como si todas las millones y millones de filas de las tablas hubieran sido insertadas por una sola transacción.
  • Verifica que cada fila tenga datos válidos
  • Crea los índices
  • Calcula las estadísticas de los índices

¿Dónde se encuentra el programa GBAK.EXE?

En la sub-carpeta \BIN de la carpeta donde está instalado el Firebird, por ejemplo en:

C:\Archivos de Programa\Firebird\Firebird_2_5\Bin\

¿Es necesario que el programa GBAK.EXE se encuentre ahí para hacer un backup?

No. Puedes tener una copia del programa GBAK.EXE en cualquier carpeta de tu disco duro. Por ejemplo si tienes un programa de contabilidad en la carpeta:

D:\MisSistemas\Contabilidad\

en esa misma carpeta podrías tener una copia de GBAK.EXE y entonces tu programa ejecutable (por ejemplo: CONTA.EXE) podría buscarlo a GBAK.EXE allí mismo. O sea que si lo deseas podrías tener a GBAK.EXE en la misma carpeta donde tienes a CONTA.EXE

¿Qué versión de GBAK.EXE debo utilizar?

La misma versión que el Servidor del Firebird. Si por ejemplo tu versión del Firebird es la 2.5.4, entonces deberías siempre usar el programa GBAK.EXE que viene incluido en esa versión.

¿Y si no coincide la versión del Servidor del Firebird con la versión de GBAK.EXE?

Hmmmmmmm, eso no es recomendable. Podría funcionar bien pero … también podrían ocurrir errores, no hay garantías.

Una buena posibilidad para que no ocurran errores es tener al programa GBAK.EXE en una carpeta compartida. Y asegurándote que corresponde a la versión del Firebird que se está usando. Para no confundirte, puedes renombrar a GBAK.EXE para que te indique su versión, algo como: GBAK_2_5_4.EXE para saber que es el correspondiente a la versión 2.5.4 del Firebird.

Ejemplo:

  • En la carpeta compartida D:\EJECUTABLES\ tienes una copia de GBAK.EXE
  • Esa copia de GBAK.EXE coincide con la versión del Firebird que utilizas
  • Como tu versión del Firebird es la 2.5.4 entonces lo renombras como GBAK_2_5_4.EXE
  • Tus programas ejecutables que se encuentran distribuidos en un montón de computadoras (en nuestro ejemplo: CONTA.EXE) cuando necesitan hacer un backup llaman al programa D:\EJECUTABLES\GBAK_2_5_4.EXE

¿Cuáles son las ventajas de usar GBAK.EXE para hacer los backups?

  • Se obtiene una copia completa de la Base de Datos
  • Los usuarios pueden continuar trabajando normalmente mientras se realiza el backup
  • Al restaurar el backup se reconstruyen los índices y sus estadísticas
  • Al restaurar el backup se puede cambiar el tamaño de la página
  • En la Base de Datos restaurada se ha recolectado la basura y se ha realizado el barrido (sweep)
  • Se puede ver que tarea está realizando el programa
  • En el disco duro la Base de Datos restaurada se encuentra (generalmente) menos fragmentada que la Base de Datos original, y por lo tanto todos los accesos son más rápidos

¿Cuáles son las desventajas de usar GBAK.EXE para hacer los backups?

  • El archivo generado no puede ser utilizado directamente, debe ser restaurado con la misma versión de GBAK o con una versión posterior, para poder ser utilizado
  • Si la Base de Datos es muy grande, tanto hacer el backup como la restauración demoran mucho tiempo
  • Si la Base de Datos es muy grande, el archivo de backup también lo será
  • Si la Base de Datos es muy grande, habrá un período de muchos minutos (desde que empezó la ejecución del programa GBAK.EXE hasta que terminó) en que no se contará con un backup actualizado. De todo lo que haya ocurrido dentro de la Base de Datos en ese período no se tendrá un backup.

¿Cuáles son las consecuencias de usar GBAK para hacer backups?

  • La Base de Datos restaurada (si no ocurrieron errores durante la restauración) se encuentra en perfecto estado de salud. Eso significa: índices perfectamente balanceados, estadísticas correctas, nada de basura.
  • En la Base de Datos restaurada todas las filas de todas las tablas que se encontraban en la Base de Datos original ahora tienen un TID (identificador de la transacción) igual a 1.
  • Los identificadores de las transacciones (OAT, OIT, OST, NT) ahora tienen valores muy pequeños. NT (next transaction) no es igual a 1 porque al restaurar se realizan algunas tareas dentro de la Base de Datos y esas tareas inician transacciones. Pero de todas maneras el valor de NT siempre es pequeño, típicamente menos que 100.

¿Por qué en la Base de Datos restaurada algunas consultas son más lentas que en la Base de Datos original?

Uno supondría que en la Base de Datos restaurada, como su salud es perfecta todos los SELECT serían más rápidos que en la Base de Datos original pero … no siempre sucede así.

¿Por qué?

Bien, uno de los métodos que utiliza el Firebird para que las consultas sean muy rápidas es guardar en el caché de la computadora donde se encuentra el Servidor las filas retornadas por los últimos SELECTs.

Si el Servidor se apaga, todo el contenido del caché desaparece (porque se encuentra en memoria RAM, la cual es volátil). Pero en las organizaciones que nunca apagan el Servidor el contenido del caché sirve para agilizar de gran manera a las consultas. Si las filas que solicita un usuario ya se encontraban en el caché entonces desde allí le son entregadas, y eso es muchísimo más rápido que leerlas desde el disco duro.

Sin embargo, al restaurar una Base de Datos el caché se vacía (porque los identificadores de las transacciones cambiaron, ahora ya son todos 1) y entonces hay que reiniciar el proceso de ir cargando el caché.

Como consecuencia, algunas consultas (no todas, solamente las que tenían filas en el caché) serán más lentas en la Base de Datos restaurada que en la Base de Datos original. Claro que esto será solamente durante un corto tiempo, luego será distinto.

¿GBAK siempre realiza el backup correctamente?

No. Y esto es algo súper importante para recordar. Al hacer el backup, GBAK no verifica si los datos que está copiando tienen errores o no. Eso solamente se puede descubrir en el momento de la restauración, nunca en el momento del backup.

Por lo tanto, el backup que realizó GBAK …. puede ser totalmente inservible.

¿Terrible?

Sí, así mismo, eso es. Terrible.

Por ejemplo, una columna definida como NOT NULL tiene valores NULL. Tal cosa no debería ocurrir pero a veces la Base de Datos se corrompe y sucede. GBAK copia esas filas sin ningún aviso, ninguna advertencia, ningún mensaje de error. Sin embargo, al querer restaurar ese backup allí sí se enojará … y finalizará la restauración. El archivo que estaba generando se muere ahí mismo, se vuelve completamente inservible.

Hay métodos para solventar ese problema (que veremos en otro artículo) pero lo importante a recordar es:

JAMÁS SE DEBE CONFIAR EN EL BACKUP. JAMÁS

¿Cómo se puede saber si un backup está correcto?

Ya vimos que al hacer el backup GBAK no nos avisa si la Base de Datos tiene errores. Solamente nos avisa cuando está restaurando, así que por lo tanto….

La única manera de verificar que un backup está ok es restaurándolo.

No hay otra forma.

¿Cuál es la mejor manera de hacer y verificar un backup?

Escribiendo un comando que apenas termine el backup lo restaure, de esa manera enseguida sabremos si nuestro backup es confiable o si por el contrario es inútil (y por lo tanto debemos corregir los errores que tiene y realizar otro backup).

Ese comando es el siguiente:

GBAK -b -user SYSDBA -password masterkey MiBaseDatos.FDB stdout | GBAK -r -user SYSDBA -password masterkey stdin Restaurada.FDB

¿Qué hace este comando?

En lugar de crear un archivo de backup en el disco duro (que es lo normal), lo crea en la salida estándar (stdout). Luego realiza la restauración, tomando como archivo de entrada del segundo GBAK el archivo generado por el primer GBAK.

¿Consecuencia?

Que así hacemos un backup y también una restauración. Y si al restaurar ocurre algún error entonces lo sabremos al instante y podremos corregirlo.

Conclusión:

En el Firebird hay varios métodos para hacer backups, usar el programa GBAK.EXE es uno de esos métodos. Como todo, tiene algunas ventajas y algunas desventajas. Nunca jamás hay que confiar en que el backup está correcto y sin errores porque a veces sí tiene errores. Esos errores solamente pueden descubrirse cuando se está restaurando el backup, es el único momento en que se puede saber si el backup está correcto o no. Por lo tanto, una muy buena política administrativa es apenas terminado el backup intentar la restauración. Si el backup no se puede restaurar es inservible e inútil.

Artículos relacionados:

Los métodos para hacer backup

Backup y restauración al mismo tiempo

Backup y restore a una versión más nueva del Firebird

Entendiendo los identificadores de las transacciones

Entendiendo sweep y garbage collection

La Next Transaction después de un ciclo backup/restore

El ciclo backup/restore usando GBAK

El índice del blog Firebird21

El foro del blog Firebird21

Aumentando la velocidad de NBACKUP

2 comentarios

Como recordarás, Firebird viene con dos programas que te permiten hacer backups de las bases de datos:

  • GBAK.EXE
  • NBACKUP.EXE

Ambos tienen sus ventajas y sus desventajas, y es por eso que existen dos. Si uno de ellos fuera mejor en todo entonces el otro no existiría, no tendría razón de ser.

Cuando se hace el backup con el programa NBACKUP.EXE se puede usar el parámetro -D para aumentar la velocidad en que se realiza el backup.

¿Qué significado tiene el parámetro -D?

Habilita o deshabilita la copia directa, es decir sin la intervención del caché del sistema de archivos del sistema operativo.

A veces, escribiendo -D ON se consigue una mayor velocidad y a veces es escribiendo -D OFF se consigue una mayor velocidad.

¿Qué se debe escribir?

NBACKUP -U SYSDBA -P masterkey -B 0 MiBaseDatos.FDB MiBackup.NBK -D ON

Reemplazando por supuesto el ON por el OFF para probar la forma alternativa

¿Cómo saber cuál opción es mejor?

Probando de ambas formas y midiendo los tiempos empleados en realizar los respectivos backups.

En unas pruebas que hizo el autor de este blog con una Base de Datos de 580 Mb, los resultados fueron:

  • con el parámetro -D ON, 27 segundos
  • con el parámetro -D OFF, 12 segundos

En ese caso evidentemente -D OFF fue mejor, pero no siempre será así, dependiendo de tu Sistema Operativo y del tamaño de tu Base de Datos eso podría variar. Entonces, hay que probar.

Conclusión:

Si haces backups por intermedio del programa NBACKUP.EXE entonces deberías probar con el parámetro -D para descubrir si poniéndolo en ON o en OFF se obtienen mejores resultados.

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

 

El ciclo BACKUP/RESTORE usando GBAK

11 comentarios

Si trabajas en Informática desde hace meses o años seguramente sabes muy bien la importancia de tener backups actualizados y confiables de todas tus bases de datos, no será necesario repetírtelo.

En Firebird hay varias maneras de hacer backup:

  • Usando el programa GBAK
  • Usando el programa NBACKUP
  • Usando un programa de administración gráfica (como el EMS SQL Manager, IBExpert, FlameRobin, etc)
  • Copiando el archivo (con el Explorador del Windows, por ejemplo)

De todas ellas la más recomendable es usar el programa GBAK

¿Por qué?

Porque GBAK no solamente hace un backup, también mejora el rendimiento de la Base de Datos restaurada. O sea que al ejecutar GBAK:

  1. Realizas el backup

Al restaurar tu backup, también usando para ello el programa GBAK obtienes:

  1. Una Base de Datos sin basura
  2. Unos índices perfectos
  3. Un menor tamaño de la Base de Datos
  4. Mayor velocidad

Cuando realizas el backup, en ese backup no se guarda la basura que tenía la Base de Datos original, o sea que el backup nunca tiene basura. Tampoco se guardan los índices (sí la definición de los índices, pero no el contenido) y así esos índices son reconstruídos al restaurar el backup y por lo tanto al finalizar la restauración su selectividad es perfecta. Además, como en el backup no se guardó la basura cuando lo restauras te encuentras con un archivo .FDB de menor tamaño que el original. Y como no hay basura y los índices están perfectos, entonces la velocidad en que se ejecutan todas las operaciones (INSERT, UPDATE, DELETE, SELECT) es mayor.

Por todos estos motivos  es que periódicamente debes realizar el ciclo backup/restore usando el programa GBAK. Estos beneficios no los obtendrás si realizas el backup mediante algunos de los otros métodos, solamente los obtendrás si usas el programa GBAK.

Pero … nunca debes confiar que el backup obtenido se encuentra en perfectas condiciones. A veces, por diversas circunstancias, puedes descubrir que el backup no se realizó correctamente y que el archivo está dañado e inservible.

¿Qué implica eso?

Que siempre después de realizar el backup debes restaurarlo para verificar que está todo ok. Si no lo haces entonces puedes encontrarte con una sorpresa muy desagradable cuando quieras usarlo.

De nada te servirá tener 40 backups si cuando quieres restaurar uno de ellos descubres que está dañado, quieres restaurar el segundo y también está dañado, quieres restaurar el tercero y también está dañado y así sucesivamente. Desperdiciaste tiempo y espacio en disco porque ninguno de esos backups te resultó útil cuando lo necesitaste.

Por lo tanto, la regla de oro es la siguiente:

Siempre inmediatamente después de hacer un backup se debe restaurarlo para verificar que el backup está ok

Fíjate que la regla dice “inmediatamente”. No dice una hora después, un día después, una semana después, o algún día cuando se te ocurra. Dice “inmediatamente”, lo cual significa que apenas terminó el backup ya debe empezar la restauración.

Desde luego que si la restauración falló (sea por el motivo que sea) inmediatamente tendrás que hacer otro backup y otra restauración. Y así sucesivamente, hasta que estés 100% seguro de que puedes restaurar el backup exitosamente.

Dependiendo de las actividades de la Empresa y del tamaño de la Base de Datos puedes programar hacer el backup con GBAK cada día, cada dos días, cada semana, cada quincena, etc. pero debes realizar el ciclo backup/restore sí o sí.

No es algo opcional, es algo obligatorio si quieres tener la tranquilidad y la seguridad de que está todo ok.

Artículos relacionados:

Los métodos para hacer backup

El índice del blog Firebird21

 

Mejorando el rendimiento de las bases de datos (3)

1 comentario

En artículos previos ya habíamos visto algunos métodos que podemos usar para mejorar el rendimiento de nuestras bases de datos ya que lo usual es que deseemos obtener más velocidad para todas las operaciones (inserciones, actualizaciones, borrados, consultas).

En cuando al Sistema Operativo a usar podemos leerlo en este enlace:

https://firebird21.wordpress.com/2013/08/15/cual-sistema-operativo-usar-en-el-servidor/

Administración:

En este apartado veremos lo que puede hacer el Administrador de la Base de Datos para que ésta funcione mejor. Una de las tantas cosas buenas que tiene Firebird es que no necesita de un Administrador dedicado exclusivamente a su tarea, como sí es el caso de Oracle o de SQL Server. Las bases de datos de Firebird requieren de un mantenimiento mínimo, pero de todas maneras requieren de mantenimiento, aunque sea de vez en cuando. Las tareas básicas del Administrador son:

  1. Detectar y eliminar las transacciones que demoran mucho en finalizar
  2. Hacer un barrido manual
  3. Hacer un backup y verificar que funcione
  4. Verificar los identificadores de las transacciones
  5. Verificar las estadísticas de los índices y reconstruirlos si es necesario

1. Detectando y eliminando transacciones que demoran mucho en finalizar

Lo que más puede degradar el rendimiento de las bases de datos es que se actualicen o se borren filas y que la transacción que actualizó o borró esas filas no termine con un COMMIT o con un ROLLBACK.

Una transacción que no terminó ni con un COMMIT ni con un ROLLBACK para el Firebird continúa activa, aunque hayan pasado días, semanas, o meses. Y continúa activa porque el Firebird no puede saber, no puede adivinar, si la transacción no finalizó porque el Desarrollador no quiere que finalice aún o porque el Desarrollador se olvidó de escribir un COMMIT o un ROLLBACK. Como el Firebird no es adivino entonces por las dudas mantiene a la transacción abierta, no la cierra por su propia cuenta ya que cerrar la transacción es competencia exclusiva del Desarrollador, no del Firebird.

Entonces, una de las tareas del Administrador de la Base de Datos es verificar si hay transacciones que están activas desde hace mucho tiempo. En una aplicación bien programada ninguna transacción debería tardar más de unos cientos de milisegundos en finalizar. Si una transacción tarda más de un segundo eso ya debería llamar la atención a cualquier Administrador competente. Y ni que hablar si hace horas o días que está activa. Para saber como detectar y eliminar las transacciones que están activas desde hace mucho tiempo puedes leer estos artículos:

https://firebird21.wordpress.com/2013/03/02/detectando-aplicaciones-y-usuarios-que-mantienen-las-transacciones-abiertas-durante-mucho-tiempo/

https://firebird21.wordpress.com/2013/05/07/detectando-una-consulta-que-esta-tardando-mucho/

Aunque el título del último artículo dice “detectando una consulta” en realidad se refiere a transacciones.

Después de detectar y eliminar la transacción problemática hay que buscar y encontrar el motivo. ¿Por qué esa transacción demoró tanto? ¿Cuál es el programa que inició esa transacción? ¿por qué no finalizó ni con un COMMIT ni con un ROLLBACK?

Aquí, el Administrador debe comunicarse con el Desarrollador para informarle del problema que encontró y pedirle que lo solucione a la brevedad posible.

2. Haciendo un barrido manual

El barrido (sweep, en inglés) debe hacerse sí o sí cuando la diferencia entre la OST y la OAT es grande. Aquí, la palabra “grande” depende del contexto. Por defecto el Firebird inicia el sweep cuando esa diferencia es mayor que 20.000 pero ese número puede ser cambiado si se lo desea. Lo importante a recordar es que el sweep es un proceso que consume muchísimos recursos y en consecuencia todas las operaciones con la Base de Datos pueden volverse lentísimas. Es por ese motivo que la mayoría de los Administradores ponen el intervalo del sweep en 0 (cero) para realizarlo de forma manual, porque si se inicia de forma automática entorpecerá las actividades normales de los usuarios desde que empieza hasta que finaliza (según la conocida Ley de Murphy empezará en el peor momento posible, cuando más velocidad necesitan los usuarios), lo cual puede demorar horas en una Base de Datos muy grande y con mucha basura acumulada. Es por eso que muchos Administradores hacen el sweep en horarios en que nadie está usando la Base de Datos (y si eso no es posible, entonces en un día y hora en que muy pocas personas la están usando).

Puedes leer más sobre el sweep en este artículo:

https://firebird21.wordpress.com/2013/09/11/entendiendo-sweep-y-garbage-collection/

Resumiendo:

a) Si no se hace el sweep y la diferencia entre la OST y la OAT es grande entonces todas las operaciones se volverán muy lentas.

b) Mientras se está haciendo el sweep todas las operaciones se vuelven muy lentas

Recomendación:

Hacer el sweep cuando nadie está usando la Base de Datos o cuando muy pocas personas la están usando.

3. Haciendo un backup y verificando que funcione

Tener backups actualizados es algo tan elemental que supongo que no es necesario abundar sobre ese tema. Ningún profesional de la Informática tiene la menor duda al respecto.

Pero la tarea del Administrador no se limita a hacer backups, también debe verificar que ese backup pueda ser restaurado exitosamente. ¿Por qué? porque no hay algo peor que creer que se tiene un backup actualizado y a la hora de restaurarlo se descubre que no es posible lograrlo, que está dañado y es inútil e inservible.

Una regla muy conveniente para seguir es la siguiente:

    • Se hace un backup
    • Se lo restaura para asegurarse de que funciona
    • Se copia el backup en otro dispositivo y se lo lleva lejos de la computadora donde se encuentra el Servidor

De lo anterior se deduce que siempre tendremos al menos dos backups idénticos. Uno de ellos se mantendrá cerca del Servidor para poder restaurar rápidamente la Base de Datos en caso de ésta tener algún problema. El otro backup se mantendrá lejos del Servidor (en otro edificio o inclusive en otra localidad) para poder restaurar la Base de Datos en caso de catástrofe (terremoto, incendio, inundación, explosión de una bomba, robo de la computadora, etc). También es muy conveniente tener una copia en Internet. En esta época hay muchos sitios que permiten almacenar archivos grandes (MediaFire, Mega, RapidShare, DropBox, etc.) y tener el backup guardado en ellos es muy conveniente porque permiten que ese backup sea recuperado aún en el caso de ocurrir una catástrofe.

Si el backup se hace con el programa GBAK.EXE se tienen además otras ventajas:

    • El backup no tiene basura porque la basura no se  guarda en el backup
    • Cuando se restaura el backup se reconstruyen los índices así que al finalizar la restauración los índices estarán perfectos

4. Verificando los identificadores de las transacciones

Todo buen Administrador debe verificar periódicamente los identificadores de las transacciones porque como sabemos así se puede detectar si la Base de Datos tiene mucha basura. Puedes leer más en este artículo:

https://firebird21.wordpress.com/2013/09/08/entendiendo-los-identificadores-de-las-transacciones/

5. Verificando las estadísticas de los índices y reconstruyéndolos

Los índices pueden ir degradándose, eso ocurre frecuentemente cuando en una tabla se actualizaron o se borraron muchas filas. Por ese motivo es conveniente reconstruirlos de vez en cuando, puedes leer más en estos artículos:

https://firebird21.wordpress.com/2013/03/02/mantenimiento-de-indices/

https://firebird21.wordpress.com/2013/03/03/recreando-los-indices-de-las-tablas/

https://firebird21.wordpress.com/2013/03/09/selectividad-de-los-indices/

https://firebird21.wordpress.com/2013/08/24/usando-indices-en-firebird/

Conclusión:

Aunque afortunadamente Firebird no requiere que una persona trabaje exclusivamente como Administrador de las Bases de Datos, sí hay tareas que deben realizarse de vez en cuando para asegurarse de que las bases de datos se encuentren en un buen estado operativo, de lo contrario se irán degradando y el rendimiento decaerá. Si todo se realiza de la forma correcta, la tarea del Administrador no demorará más que unos cuantos minutos cada día e inclusive si la empresa u organización no es muy grande el trabajo podría ser de unos cuantos minutos a la semana o al mes.

Si todas las transacciones son cortas, todas las transacciones finalizan con un COMMIT o con un ROLLBACK, se hacen backups y restauraciones diarios, entonces nunca deberías tener problemas y todo debería funcionar de maravillas.

Pero no te olvides que tú o alguien más debe dedicarle un poco de tiempo a la tarea de Administrar la Base de Datos, solamente el ojo humano puede detectar fallas, eso es algo que no se puede automatizar.

Artículos relacionados:

¿Cual Sistema Operativo usar en el Servidor?

Detectando aplicaciones y usuarios que mantienen las transacciones abiertas durante mucho tiempo

Detectando una consulta que está tardando mucho

Entendiendo sweep y garbage collection

Entendiendo los identificadores de las transacciones

Mantenimiento de índices

Recreando los índices de las tablas

Recreando todos los índices de todas las tablas

Recreando índices y calculando estadísticas

Selectividad de los índices

Usando índices en Firebird

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

Entendiendo sweep y garbage collection

9 comentarios

Como habíamos visto en este artículo:

https://firebird21.wordpress.com/2013/06/14/la-arquitectura-mga/

cuando se actualiza (UPDATE) o se borra (DELETE) un registro el Firebird guarda en la Base de Datos la versión anterior de ese registro. ¿Para qué hace eso? Para poder revertir al registro original cuando se hace un ROLLBACK.

Un ROLLBACK se hace si ocurrió un error o si el usuario cambió de idea y no quiere guardar lo último que hizo, o si se cerró anormalmente la conexión.

Por lo tanto, cada comando UPDATE y cada comando DELETE le agrega un registro a la tabla respectiva (en el caso del DELETE el nuevo registro solamente tiene un marca que le indica al Firebird que ese registro está “borrado”).

Veamos un ejemplo de UPDATE:

El precio de “Televisor Toshiba de 20 pulgadas” es de 120 dólares. Como se está vendiendo poco ya que la mayoría de la gente ahora prefiere televisores de más pulgadas se decidió disminuir su precio a 100 dólares, tratando de conseguir que aumenten las ventas al disminuir el precio.

Entonces, en nuestra tabla de PRODUCTOS, luego del correspondiente UPDATE, tendríamos:

SWEEP1

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

Ahora hay dos posibilidades:

  1. Que la transacción termine con un COMMIT exitoso
  2. Que la transacción termine con un ROLLBACK

Si la transacción terminó con un COMMIT exitoso entonces el registro antiguo, el que tiene el TID 143 ya no sirve, es inútil. Pero el Firebird no lo elimina de la Base de Datos, lo deja ahí. Y eso implica que está ocupando espacio inútilmente.

Si la transacción terminó con un ROLLBACK entonces el registro nuevo, el que tiene el TID 279 ya no sirve, es inútil. Pero el Firebird no lo elimina de la Base de Datos, lo deja ahí. Y eso implica que está ocupando espacio inútilmente.

De lo anterior se deduce que cada vez que escribes el comando UPDATE dejas un registro inservible dentro de la Base de Datos. O el original queda inservible o el actualizado queda inservible.

Hay por lo tanto dos tipos de registros inservibles:

  • Los dejados por los COMMIT
  • Los dejados por los ROLLBACK

¿Hay diferencia si el registro inservible fue dejado por un COMMIT o por un ROLLBACK?

Sí, la diferencia es que los registros inservibles dejados por los COMMIT pueden ser eliminados automáticamente durante la recolección de la basura (ver más abajo), en cambio los dejados inservibles por los ROLLBACK nunca son eliminados automáticamente.

¿Qué es la “basura”?

Esos registros inservibles, inútiles, que fueron dejados por los UPDATE o por los DELETE siguen ocupando espacio dentro de la Base de Datos, pero como ya son inservibles y totalmente inútiles se les llama “basura”.

¿Cuál es el problema con la basura?

Que ocupa espacio inútilmente dentro de la Base de Datos y por lo tanto ésta es más grande de lo que debería ser y además se vuelve cada vez más lenta.

¿Qué significa “garbage collection”?

En castellano: recolección de la basura. Cuando se recolecta la basura todos esos registros inservibles dejados por los COMMIT son eliminados permanentemente y definitivamente de la Base de Datos. Como consecuencia de ello, la Base de Datos queda con espacio reutilizable y además las operaciones dentro de ella (INSERT, UPDATE, DELETE, FETCH, SELECT) se realizan más rápidamente.

¿Cuándo se realiza la “garbage collection”?

Cada vez que un registro es “tocado” por un SELECT toda la basura relacionada con ese registro como consecuencia de los COMMIT es eliminada. En otras palabras, si al escribir un SELECT un registro está en el resultado obtenido entonces toda la basura relacionada con ese registro, producida por los  COMMIT, es eliminada.

Fíjate que solamente el SELECT elimina a la basura, los demás comandos: INSERT, UPDATE, DELETE, no la eliminan, la dejan así mismo como estaba.

¿Cuál es la forma más rápida de eliminar toda la basura de una tabla?

Escribir el comando:

SELECT
   COUNT(*)
FROM
   MiTabla

Lo que hace ese comando es contar la cantidad de registros que tiene la tabla pero para hacerlo debe recorrer la tabla desde el primer registro hasta el último registro porque el Firebird no guarda en alguna parte la cantidad de registros de la tabla. Por lo tanto, todos los registros de esa tabla están involucrados en el SELECT y por consiguiente en todos esos registros es recolectada la basura. Si la tabla tiene 12.000 registros entonces SELECT COUNT(*) recorre los 12.000 registros y el “garbage collection” elimina toda la basura que haya encontrado en cualquiera de esos 12.000 registros.

Recuerda que esta forma de eliminar a la basura solamente elimina a la basura que dejaron los COMMIT, la basura dejada por los ROLLBACK no se puede eliminar así.

¿Cuál es el problema con recolectar la basura usando SELECT?

Que para recolectar la basura de todas las tablas debes hacer SELECT COUNT(*) en todas las tablas o esperar que algún SELECT involucre a los registros que tienen basura. A veces, puede ocurrir que se hizo el UPDATE de un registro pero nunca se hizo un SELECT que involucre a ese registro y por lo tanto la basura que dejó el UPDATE permanece dentro de la Base de Datos.

Además, no te olvides que cuando se ejecuta un SELECT solamente se recolecta la basura que dejaron los COMMIT, la basura dejada por los ROLLBACK continúa allí.

¿Qué es el sweep?

El sweep (en castellano: barrido, de barrer con una escoba) es un proceso que recorre toda la Base de Datos y elimina toda la basura que se encuentra en ella, tanto la proveniente de los COMMIT como la proveniente de los ROLLBACK. Cuando el sweep finaliza la Base de Datos está bien limpia, sin basura.

¿Cuándo se realiza el sweep?

El sweep se puede realizar automáticamente o manualmente. Automáticamente es cuando lo inicia el propio Firebird y manualmente es cuando lo inicia un programa (por ejemplo: GFIX y GBAK pueden iniciar el sweep).

Sweep automático

Cada Base de Datos tiene una entrada denominada “sweep interval” o sea intervalo del sweep. Es un número de tipo INTEGER  y por lo tanto su valor puede estar entre 0 y 2.147.483.647. Por defecto su valor es 20.000.

Cuando la diferencia entre la OST y la OAT es mayor que el intervalo del sweep, se inicia el sweep. Por ejemplo:

OST = 45.201

OAT = 25.200

Sweep interval = 20.000

Diferencia = OST – OAT = 45.201 – 25.200 = 20.001

Como la diferencia es mayor que el intervalo del sweep, se inicia el sweep automático.

Si no se quiere realizar un sweep automático entonces el intervalo del sweep debe ser 0 (cero)

¿Cuál es el problema con el sweep?

Que este proceso de recorrer toda la Base de Datos y de eliminar toda la basura que hay en ella es lento, en algunos casos extremadamente lento y los usuarios se quejan de que todas las operaciones (INSERT, UPDATE, DELETE, FETCH, SELECT) se realizan muy despaciosamente. Y por supuesto podría ocurrir que el sweep automático se inicie cuando los usuarios están más apurados, más impacientes y por culpa del sweep todas sus transacciones son más lentas que una tortuga con tres patas. Es por lo tanto normal que el DBA (Administrador de la Base de Datos) ponga el intervalo del sweep en 0 (cero) y de esa manera realizará el sweep manualmente, en momentos en que nadie está usando la Base de Datos (o cuando muy pocos usuarios la están usando).

Pero …. a veces el DBA se olvida de que dejó el intervalo del sweep en cero y la Base de Datos se va volviendo cada vez más grande y más lenta por toda la basura que tiene acumulada.

En otras palabras, se necesita un DBA con cerebro, algo que no siempre se consigue.

Aprovechar el backup para hacer el sweep

Cuando haces un backup usando el programa GBAK tienes la opción de que también se haga el sweep de la Base de Datos. Esa es la opción por defecto y la recomendable. Así, cuando finaliza el programa GBAK puedes estar seguro de que el archivo de backup generado no tiene basura. Recuerda: la Base de Datos original continúa con toda la basura que tenía, el backup generado es el que no tiene basura.

Usando el programa GFIX para hacer el sweep

Una de las opciones de este programa nos permite pedirle que haga el sweep:

GFIX -sweep -user SYSDBA -password masterkey MiBaseDatos

Un pequeño “defecto” que tiene el programa GFIX es que no te avisa que finalizó exitosamente y eso confunde a los principiantes. O sea, si termina sin ningún mensaje significa que todo estuvo ok, si ocurrió algún problema entonces termina con un mensaje de error.

Conclusión:

El uso normal de la Base de Datos va dejando basura dentro de ella. Esa basura debe ser eliminada en algún momento porque de no eliminarse solamente causará que la Base de Datos tenga un tamaño mayor que el necesario y además que todas las transacciones sean más lentas de lo que deberían. La eliminación de la basura puede hacerse en forma automática (cuando el intervalo del sweep es mayor que cero y la diferencia entre la OST y la OAT es mayor que ese intervalo) o en forma manual (cuando el intervalo del sweep es cero y en ese caso hay que ejecutar el programa GFIX). También se elimina la basura cuando se hace un backup usando el programa GBAK y no se especifica la opción -garbage collection.

Artículos relacionados:

La arquitectura MGA

Entendiendo a las transacciones

Entendiendo a los identificadores de las transacciones

El índice del blog Firebird21

Un archivo de lotes para mantenimiento de la Base de Datos

2 comentarios

Por el uso (y abuso) diario las bases de datos normalmente van perdiendo performance, volviéndose más lentas todas las operaciones que se realizan en ellas. Una forma de mantener a la Base de Datos saludable es a través del siguiente archivo .BAT

CLS

@ECHO OFF

ECHO IMPORTANTE: El nombre de la Base de Datos NO DEBE TENER LA EXTENSION para que este archivo .BAT funcione bien.

@ECHO ON

SET ISC_USER=SYSDBA

SET ISC_PASSWORD=masterkey

SET CarpetaFirebird=C:\Program Files\Firebird\Firebird_2_5\bin\

SET CarpetaBaseDatos=E:\SQL\DATABASES\

SET CarpetaBackup=E:\SQL\BACKUPS\

SET NombreBaseDatos=INTEGRAL

C:

CD "%CarpetaFirebird%"

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -shut single -force 0

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -validate -full -ignore

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -mend -ignore

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -online

IF EXIST "%CarpetaBackup%%NombreBaseDatos%_GBAK.LOG" DEL "%CarpetaBackup%%NombreBaseDatos%_GBAK.LOG"

GBAK "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" "%CarpetaBackup%%NombreBaseDatos%.FBK" -e -g -ig -l -nt -b -v -y "%CarpetaBackup%%NombreBaseDatos%_GBAK.LOG"

IF EXIST "%CarpetaBackup%%NombreBaseDatos%_GBAK2.LOG" DEL "%CarpetaBackup%%NombreBaseDatos%_GBAK2.LOG"

IF EXIST "%CarpetaBaseDatos%%NombreBaseDatos%_NEW.FDB" DEL "%CarpetaBaseDatos%%NombreBaseDatos%_NEW.FDB"

GBAK "%CarpetaBackup%%NombreBaseDatos%.FBK" "%CarpetaBaseDatos%%NombreBaseDatos%_NEW.FDB" -o -r -v -REP -y "%CarpetaBackup%%NombreBaseDatos%_GBAK2.LOG"

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -shut -force 0

E:

IF EXIST "%NombreBaseDatos%_ANTERIOR.FDB" DEL "%NombreBaseDatos%_ANTERIOR.FDB"

RENAME "%NombreBaseDatos%.FDB" "%NombreBaseDatos%_ANTERIOR.FDB"

IF EXIST "%NombreBaseDatos%.FDB" DEL "%NombreBaseDatos%.FDB"

RENAME "%NombreBaseDatos%_NEW.FDB" "%NombreBaseDatos%.FDB"

C:

GFIX "%CarpetaBaseDatos%%NombreBaseDatos%.FDB" -online

@PAUSE

Como seguramente ya sabes, los archivos .BAT son los archivos de lotes (batch, en inglés) del antiguo Sistema Operativo D.O.S. y que el Windows ha heredado. En estos archivos .BAT puedes escribir varios comandos, los cuales se ejecutarán en el mismo orden establecido.

Este archivo .BAT realiza las siguientes tareas:

  1. Borra la pantalla
  2. Muestra un mensaje al usuario
  3. Establece las variables de entorno. Son todas las que empiezan con la palabra SET. Fíjate que para no estar escribiendo el nombre del usuario y su password en cada comando GFIX y GBAK que hay más abajo, se asignaron sus valores a dos variables. No es obligatorio hacer así, pero se escribe menos.
  4. El nombre de la Base de Datos debe escribirse sin la extensión (o sea, sin el .FDB). Por eso, aunque el nombre real de la Base de Datos usada en este ejemplo es INTEGRAL.FDB en la variable se escribió solamente INTEGRAL
  5. El comando GFIX -shut single -force 0 permite que solamente el usuario SYSDBA pueda estar conectado a la Base de Datos, nadie más. El -force 0 cerrará inmediatamente todas las conexiones. ¿Qué implica eso? Que este archivo .BAT solamente debe ejecutarse cuando nadie está usando la Base de Datos. De lo contrario, los usuarios que estén conectados perderán la conexión y posiblemente el trabajo que estaban haciendo.
  6. Los siguientes dos comandos GFIX sirven para validar y corregir errores en la Base de Datos
  7. El cuarto comando GFIX vuelve a permitir que otros usuarios se conecten a la Base de Datos
  8. Antes de realizar el backup se verifica si existe el archivo LOG (en los archivos de LOG se guarda información con respecto a la ejecución de un comando). Si existe, se lo borra
  9. Se realiza el backup y las tareas que realizó se guardan en un archivo de LOG, que es un archivo de texto que puede ser revisado en cualquier momento
  10. Idénticamente, antes de restaurar el backup se verifica si existen su archivo de LOG y un archivo con el mismo nombre del que será restaurado. Si existen, se los borra
  11. Se realiza la restauración del backup
  12. Nuevamente se desconecta a todos los usuarios. Esto es necesario para que el nombre de la Base de Datos pueda ser cambiado, si alguien la estuviera usando, su nombre no podría cambiarse
  13. Se cambian los nombres de dos archivos
  14. Y finalmente, se vuelve a permitir que todos los usuarios puedan conectarse a la Base de Datos

Si en el punto 14. obtienes un error, no te preocupes, significa que todos ya podían conectarse y le volviste a pedir que todos se pudieran conectar.

Algunos puntos importantes a recordar:

  1. Este archivo .BAT debe estar en la computadora del Servidor, no funcionará remotamente
  2. Debes crear un archivo de texto con la extensión .BAT para que funcione. Para mayor facilidad, puedes colocar un acceso directo en el escritorio.
  3. Si ejecutas este archivo .BAT periódicamente, te asegurarás que tu Base de Datos siempre se encuentre en buen estado y que todas las operaciones en ella sean lo más rápidas posibles
  4. Debes ejecutarlo solamente cuando estás seguro que nadie está conectado a la Base de Datos, porque este archivo .BAT desconectará automáticamente a todos quienes estén conectados y eso les podría ocasionar pérdida de sus trabajos
  5. La carpeta BACKUPS debe existir, si no existe obtendrás un mensaje de error y este .BAT no cumplirá su misión
  6. Debes establecer los valores de las variables de entorno (las que empiezan con SET) acordemente a tu situación particular. Las que ves aquí son solamente un ejemplo
  7. Antes de renombrar los archivos (casi al final del .BAT) se cambia a la unidad E:, porque en esa unidad tengo yo mis bases de datos. En tu caso, debes colocar allí la letra que corresponda (C:, D:, E:, F:, la que sea)

Artículo relacionado:

El índice del blog Firebird21

Older Entries