Usando Database Comparer en línea de comandos

4 comentarios

En el artículo:

https://firebird21.wordpress.com/2013/06/10/database-comparer-de-clever-components/

ya habíamos hablado sobre un programa muy bueno para comparar bases de datos llamado Database Comparer, de la empresa Clever Components.

Pues bien, ese programa además de permitirnos interactuar con él por medio del GUI (Graphical User Interface) también nos permite ejecutarlo a través de la línea de comandos, como veremos ahora.

¿Y para qué nos serviría ejecutarlo a través de la línea de comandos?

La utilidad más normal de esta característica es que podemos automatizar el proceso en nuestra aplicación (o sea, en el archivo .EXE que nosotros creamos y que los usuarios ejecutan).

En nuestro .EXE podemos hacer que la comparación (y actualización, si es necesaria) se haga en forma automática o cuando el usuario haga clic sobre algún botón.

Veamos la situación:

Estamos desarrollando un sistema de contabilidad que será usado por muchos estudios contables. Un estudio contable normalmente lleva la contabilidad de muchos clientes. Como sabemos que no es bueno tener en una sola Base de Datos a todos los clientes del estudio contable sino que lo recomendable es que cada uno de sus clientes tenga su propia Base de Datos nos encontramos con un problema.

¿Cuál es el problema?

Que la estructura de una Base de Datos (es decir, sus metadatos) no es fija, por mucho que la hayamos analizado siempre cabe la posibilidad de que alguna vez debamos crear una tabla, o modificar una existente, agregarle índices, vistas, stored procedures, triggers, etc.

Si el estudio contable solamente tuviera uno o dos clientes sería muy sencillo. Con la GUI de Database Comparer en un ratito actualizaríamos las bases de datos y listo, a otra cosa.

Pero lo normal es que los estudios contables tengan decenas o centenas de clientes, y allí la actualización manual ya se vuelve muy impráctica, demora mucho tiempo, y existe la gran posibilidad de no actualizar todas las bases de datos o hacerlo de manera equivocada (actualizando al revés), con la consecuencia de que podrían perderse muchos datos y todos los trastornos que eso ocasionaría.

El comportamiento adecuado

Ante una situación como la antedicha, ¿qué es lo mejor?

  1. Creamos una Base de Datos vacía, modelo, que solamente tiene los metadatos. Por ejemplo la llamamos MASTER.FDB
  2. Por cada cliente del estudio contable tenemos una Base de Datos que cuando se agregó ese cliente simplemente se copió físicamente a MASTER.FDB para tener la Base de Datos del cliente. Así podríamos tener ALICIA.FDBGRACIELA.FDB, SUSANA.FDB, etc., las cuales inicialmente eran una simple copia de MASTER.FDB y después se les fueron agregando los datos que les correspondían.
  3. Cuando debemos cambiar algo en la Base de Datos, la única Base de Datos que tocamos, la única con la cual trabajamos es MASTER.FDB
  4. Cuando el usuario abre una Base de Datos, nuestro programa .EXE compara la versión de MASTER.FDB con la versión de la Base de Datos que él abrió. Por ejemplo, si abrió GRACIELA.FDB se compara a MASTER.FDB con GRACIELA.FDB
  5. Para comparar a ambas bases de datos lo mejor es que tengan una tabla, por ejemplo llamada VERSION con una columna llamada por ejemplo VER_NUMERO. Si el número de versión de MASTER.FDB es más nuevo que el número de versión de GRACIELA.FDB entonces estamos seguros de que GRACIELA.FDB debe ser actualizada
  6. Si descubrimos que GRACIELA.FDB debe ser actualizada, entonces nuestro programa .EXE ejecuta a Database Comparer con sus parámetros de la línea de comandos
  7. De esta manera, no importa si el estudio contable tiene cientos de bases de datos, cada vez que el usuario abra una de esas bases de datos se la comparará con MASTER.FDB y en el caso de que la versión de MASTER.FDB sea más nueva entonces se actualizará la Base de Datos que el usuario abrió.
  8. Y estaremos seguros de que sea cual sea la Base de Datos que el usuario abra, y aunque hayan pasado meses o años desde la última vez que la abrió, siempre estará correctamente actualizada.
  9. Lo único que debemos recordar es que cada vez que cambiamos algo en MASTER.FDB debemos actualizar la columna VER_NUMERO de la tabla VERSION, escribiendo un número que sea mayor que el que existía ahí.

La interfaz de línea de comandos de Database Comparer

Si abrimos una ventanita “Símbolo del sistema”, nos ubicamos en una carpeta donde se encuentre el programa DBCOMPARER.EXE y lo ejecutamos con la opción /? veremos las opciones disponibles.

DBCOMPARER

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

Ejemplo de uso

Al programa DBCOMPARER.EXE podemos copiarlo en cualquier carpeta, no es necesario ni obligatorio ejecutarlo en la carpeta donde fue instalado. Lo mejor generalmente es copiar a DBCOMPARER.EXE y al archivo IBDB_CMP.CFG (donde se guardan los alias, las ubicaciones de las bases de datos, etc.) a la misma carpeta donde se encuentra nuestro programa .EXE

DBCOMPARER2

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

Al escribir el comando anterior lo que hacemos es decirle a DBCOMPARER que compare a la Base de Datos cuyo alias en ese programa es MASTER con la Base de Datos cuyo alias en ese programa es PRUEBA1. Si hay diferencias entonces PRUEBA1 cambiará para que sus metadatos sean idénticos a los metadatos de MASTER.

Cuando el programa finalice, estaremos seguros de que ambas bases de datos tienen exactamente la misma estructura.

Conclusión:

Database Comparer es una muy buena aplicación para comparar las estructuras de las bases de datos y para hacer que sean idénticas en caso de que tengan diferencias.

Si las bases de datos a comparar son pocas, el proceso puede ser realizado manualmente, es muy sencillo, nada complicado.

Pero si las bases de datos son muchas, entonces hacerlo manualmente demorará mucho tiempo y además se corre el riesgo de no compararlas a todas o de compararlas en el sentido erróneo. Por lo tanto es mucho mejor automatizar ese proceso.

La interfaz de línea de comandos justamente nos permite automatizar la comparación y actualización. Por eso, es conveniente usarla.

Enlaces:

http://www.clevercomponents.com/products/dbcomparer/index.asp

http://www.clevercomponents.com/products/index.asp

http://www.clevercomponents.com/downloads/index.asp

Artículos relacionados:

Database Comparer de Clever Components

El índice del blog Firebird21

El foro del blog Firebird21

Ejemplos de dominios

Deja un comentario

Los dominios nos ayudan a evitar que entre basura en una Base de Datos. Como seguramente ya sabes, se le llama basura a los datos que están pero que no deberían estar.

Usando dominios podemos determinar claramente cuales datos son permitidos dentro de una columna.

Como mucha gente aún no los conoce, o no los conoce bien, a continuación hay unos cuantos ejemplos con sus respectivas explicaciones. Al autor de este blog le gusta que todos los nombres de dominios empiecen con D_ para que sea muy fácil saber que se trata de un dominio pero no es obligación que sea así, es cuestión de gustos.

Ejemplo 1. Valores booleanos

Para las columnas que solamente admiten dos posibilidades: verdadero o falso, podríamos tener un dominio como el siguiente:


CREATE DOMAIN D_BOOLEAN AS
CHAR(1)
CHECK (VALUE = 'F' OR VALUE = 'V');

El dominio D_BOOLEAN solamente admitirá una letra ‘F’ mayúscula o una letra ‘V’ mayúscula, cualquier otro carácter que se quiera introducir será rechazado. Podríamos usarlo para saber si un cheque fue impreso o no, si una Factura está anulada o no, etc.

Ejemplo 2. Cantidades mayores o iguales que cero

Para las columnas donde se guarda la cantidad actual en existencia de un producto (o artículo) podríamos tener un dominio como el siguiente:


CREATE DOMAIN D_CANTIDAD1 AS
INTEGER
CHECK (VALUE >= 0);

El dominio D_CANTIDAD1 solamente admitirá números enteros (o sea, sin decimales) y que sean iguales o mayores que cero y menores o iguales que 2.147.483.647, ¿porqué ese valor? porque el tipo de datos INTEGER admite números desde -2.147.483.648 hasta 2.147.483.647

Ejemplo 3. Cantidades mayores que cero

Para la columna donde se guarda la cantidad comprada o vendida de un producto (o artículo) se podría tener un dominio como el siguiente:


CREATE DOMAIN D_CANTIDAD2 AS
INTEGER
CHECK (VALUE > 0);

El dominio D_CANTIDAD2 solamente admitirá números que sean enteros (o sea, sin decimales) y mayores que cero y menores o iguales que 2.147.483.647

Si se compra o se vende algo, la cantidad siempre es mayor que cero, y el dominio D_CANTIDAD2 justamente nos ayuda con esa restricción.

Ejemplo 4. Sexo de una persona

Para la columna donde se guarda el sexo de una persona (femenino o masculino) podríamos tener un dominio así:

CREATE DOMAIN D_SEXO AS
CHAR(1)
CHECK (VALUE = 'F' OR VALUE = 'M');

El dominio D_SEXO solamente permitirá que en una columna se ingrese una ‘F’ mayúscula o una ‘M’ mayúscula.

Ejemplo 5. Estado civil de una persona

Para las columnas donde se guarda el estado civil podríamos tener un dominio como este:


CREATE DOMAIN D_ESTADO_CIVIL AS
CHAR(1)
CHECK (VALUE IN ('S', 'C', 'E', 'D', 'V'));

El dominio D_ESTADO_CIVIL admitirá una sola letra mayúscula, la cual puede ser ‘S’ (soltero), ‘C’ (casado), ‘E’ (separado), ‘D’ (divorciado), o ‘V’ (viudo).

Ejemplo 6. Fechas del año 2013 o posteriores

Para aceptar solamente fechas correspondientes al año 2013 o posteriores, podríamos tener un dominio así:


CREATE DOMAIN D_FECHA2013 AS
DATE
CHECK (VALUE >= '01.01.2013');

De esta manera, ninguna fecha anterior será permitida en las columnas que tengan este dominio.

Ejemplo 7. Fotografías o imágenes

Para que en una columna podamos guardar archivos de cualquier tamaño (por ejemplo fotografías, pero también podrían ser archivos, planillas Excel, documentos Word, etc.) podríamos definir este dominio:


CREATE DOMAIN D_FOTOGRAFIA AS
BLOB SUB_TYPE 1;

Ejemplo 8. Nombres de hasta 20 caracteres

Para los textos que tendrán un máximo de 20 caracteres (nombres, apellidos, etc.) podríamos definir un dominio:


CREATE DOMAIN D_NOMBRE20 AS
VARCHAR(20);

El dominio D_NOMBRE20 admite un máximo de 20 caracteres, esos caracteres pueden ser cualesquiera pero no pueden ser más que 20.

Ejemplo 9. Nombres de hasta 60 caracteres

Para los textos que tendrán un máximo de 60 caracteres (direcciones, nombres de productos, etc.) podríamos definir un dominio:

CREATE DOMAIN D_NOMBRE60 AS
VARCHAR(60);

El dominio D_NOMBRE60 admite un máximo de 60 caracteres, esos caracteres pueden ser cualesquiera pero no pueden ser más que 60.

Ejemplo 10. Precios de productos o servicios

Para las columnas donde se guardará el precio de compra o de venta de un producto o de un servicio, podríamos tener un dominio como este:


CREATE DOMAIN D_PRECIO AS
NUMERIC(18, 4)
CHECK (VALUE > 0);

El dominio D_PRECIO admite decimales pero todos sus valores deben ser sí o sí mayores que cero.

Conclusión:

Los dominios son una de las herramientas con las cuales contamos en Firebird para disminuir la probabilidad de que entre basura en nuestras bases de datos. Es muy conveniente utilizarlos y aquí hemos visto varios ejemplos para que se pueda entender bien como crearlos y la utilidad que tienen.

Artículos relacionados:

Entendiendo a los dominios

Un stored procedure para obtener el contenido de los dominios

¿Cómo Firebird trata a los cambios de dominio?

La forma más fácil de cambiar un dominio

El índice del blog Firebird21

El foro del blog Firebird21

¿Cómo Firebird trata a los cambios de dominio?

3 comentarios

Supongamos que tienes un dominio y decides cambiarlo. Ese dominio quizás está siendo usado en muchas tablas, algunas de las cuales pueden tener millones y millones de filas.

No puedes cambiar un dominio para que guarde menos datos que antes, pero sí puedes cambiarlo para que guarde más datos que antes. Cambiar de INTEGER a SMALLINT no está permitido. Cambiar de SMALLINT a INTEGER sí está permitido. Cambiar de CHAR(10) a CHAR(2) no está permitido. Cambiar de CHAR(2) a CHAR(10) sí está permitido.

Así que veamos lo que ocurrirá cuando quieres cambiar un dominio y está permitido hacerlo.

Ejemplos:

D_PRECIO1 DECIMAL(9, 2) quieres cambiar a D_PRECIO1 DECIMAL(18, 2)

D_APELLIDOS VARCHAR(20) quieres cambiar a D_APELLIDOS VARCHAR(25)

¿Cómo actuará el Firebird en una situación así?

Cambiar cada fila de cada tabla que usa el dominio no es práctico, es totalmente improductivo, porque algunas tablas pueden tener millones y millones de filas y estar siendo usadas por cientos o miles de usuarios. Hacer algo así demoraría mucho tiempo y además podría causar un sinfín de problemas.

Por lo tanto, lo que el Firebird hace es lo siguiente:

  1. Cuando se cambia un dominio, no altera a ninguna columna de ninguna tabla. Todo sigue igual en las tablas que creó el desarrollador.
  2. Los que sí cambian son los metadatos, las estructuras de las tablas que usan ese dominio son cambiadas.
  3. Cuando se hace un INSERT, usa el nuevo dominio en la fila insertada
  4. Cuando se hace un UPDATE, usa el nuevo dominio en la fila actualizada (recuerda que cada UPDATE crea una nueva fila. Y en esa nueva fila se usará el nuevo dominio). La fila original no se toca, queda como estaba.
  5. Cuando se hace un SELECT, las filas que tienen el dominio viejo serán cambiadas en memoria para que tengan el dominio nuevo, así que al ver las filas obtenidas se las verá con el dominio nuevo. Las filas no son cambiadas en la Base de Datos, el cambio se hace solamente en la memoria RAM de la computadora del Servidor.

¿Es posible conseguir que todas las columnas de todas las tablas utilicen el nuevo dominio?

Sí. Usando GBAK para hacer un ciclo backup/restore la Base de Datos restaurada tendrá todas las columnas con el nuevo dominio.

GBAK hará que todas las columnas de todas las filas de todas las tablas estén estructuradas con los últimos dominios definidos.

Recuerda que la Base de Datos original no se cambia, queda como estaba, la que se cambia es la Base de Datos restaurada.

Conclusión:

El Firebird permite cambiar la definición de un dominio, si el nuevo dominio permitirá guardar más datos que el viejo dominio.

Cuando se cambia un dominio, se cambia la estructura de las tablas que usan ese dominio (es decir, los metadatos) pero no se cambian las filas que insertaron los usuarios. Esas filas quedan igual, no se tocan.

Cambiar las filas que insertaron los usuarios demoraría mucho tiempo y podría causar muchos problemas, sería una idea muy mala, por lo tanto el Firebird hace lo más inteligente:

Cuando se hace un INSERT, se usa el nuevo dominio. Cuando se hace un UPDATE, en la fila actualizada se usa el nuevo dominio. Cuando se hace un SELECT, las filas que tenían el dominio viejo se cambian en memoria para que tengan el dominio nuevo y así los usuarios puedan ver esas columnas con el dominio nuevo.

Si se desea que todas las columnas usen físicamente el nuevo dominio, hay que hacer un ciclo backup/restore usando el programa GBAK. Así, la Base de Datos restaurada tendrá a todas sus columnas estructuradas con los últimos dominios definidos.

Artículos relacionados:

Entendiendo a los metadatos del programador

Entendiendo a los dominios

La forma más fácil de cambiar un dominio

El índice del blog Firebird21

El foro del blog Firebird21

Error: database file appears corrupt

8 comentarios

Como seguramente sabes, debes revisar constantemente el archivo FIREBIRD.LOG que encontrarás en la carpeta donde instalaste al Firebird para descubrir cualquier error que haya ocurrido.

¿Qué significa el error: “database file appears corrupt“?

Que el archivo de la Base de Datos (el cual usualmente tiene la extensión .FDB) está dañado.

¿Por qué se dañó la Base de Datos?

La causa más común es porque hubo un corte de la energía eléctrica en la computadora donde se encuentra el Servidor mientras se estaba realizando una operación de INSERT, UPDATE, o DELETE.

A veces también podría ocurrir si hay una súbita alta tensión. O si algún descerebrado apagó el Servidor mientras la Base de Datos estaba siendo usada.

Entonces, el problema fue causado por dos motivos:

  1. Se estaba realizando una operación de INSERT, UPDATE, DELETE
  2. En ese instante se detuvo el Servidor del Firebird

Otra causa, tal como señaló Yván Acosta en la sección de comentarios, es que usando el Explorador de Windows o algún programa similar, se haya copiado la Base de Datos. Hay varios métodos seguros para realizar backups de las bases de datos, y alguno de esos métodos seguros hay que usar.

¿Cuál es la solución?

Usar el programa FirstAID (primera ayuda) de IBSurgeon, que encontrarás en www.ib-aid.com

¿Cómo evitar que el problema vuelva a ocurrir?

  1. Primero y elemental, colocarle una UPS (uninterruptible power supply) de buena capacidad a la computadora donde se encuentra el Servidor
  2. Verificar, al menos una vez a la semana que la UPS esté funcionando correctamente. Para ello, cuando nadie esté conectado a la Base de Datos, desenchufar la UPS del tomacorriente y anotar el tiempo que mantiene a la computadora encendida. Las UPS van disminuyendo el tiempo en que sus baterías proveen de carga eléctrica. Jamás hay que creer que una UPS que se instaló hace un año sigue funcionando como cuando era nueva. En la gran mayoría de los casos, eso es falso.
  3. Evitar que la computadora donde se encuentra el Servidor sea apagada.
  4. Evitar que el Servidor sea detenido, manualmente o por algún otro programa.

Con relación al punto 3. tengo una anécdota. En una empresa grande, que tiene decenas de computadoras, súbitamente todo el mundo se desconectó de la Base de Datos, había energía eléctrica, las luces estaban encendidas, las computadoras también, pero no había conexión a la Base de Datos, caos total. ¿Qué había ocurrido? Que la señora de la limpieza, con su escoba había desenchufado al Servidor, y siguió limpiando como si nada, no le importó lo más mínimo porque ni siquiera sabía la importancia de que ese cable estuviera enchufado. Al salir, cerró la puerta de la habitación y como se encuentra alejada de la Administración nadie se percató que unos minutos después la UPS empezó a chillar como loca. Se aprendió la lección, ahora el Servidor está en una habitación aparte y la puerta siempre se mantiene cerrada con llave, por las dudas. Y duplicados de esa llave solamente tienen las personas adecuadas, ninguna “señora de la limpieza” puede entrar.

Con relación al punto 4. hay que tener cuidado con los antivirus u otros programas similares porque podrían detener al Servidor. Es por ese motivo que fuertemente se aconseja que en la computadora donde se encuentra el Servidor del Firebird no se esté ejecutando ningún otro programa, ninguno, ni siquiera un antivirus.

Conclusión:

Una Base de Datos puede corromperse si el Servidor deja de funcionar mientras estaba realizando una operación de INSERT, UPDATE, o DELETE.

El problema puede solucionarse con el programa FirstAID de IBSurgeon, pero lo más conveniente es evitar que el problema ocurra. Para ello, jamás debe detenerse el Servidor si alguien está conectado a la Base de Datos.

Artículos relacionados:

FirstAID de IBSurgeon

Reparación de una Base de Datos corrupta

Manteniendo la Base de Datos en buen estado

Los métodos para hacer backup

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