Especificando el archivo FIREBIRD.MSG que queremos usar

Deja un comentario

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

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

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

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

can't format message...

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

¿Qué significa eso?

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

¿Cómo lo resolvemos?

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

MSG1

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

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

Alternativa:

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

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

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

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

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

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

4 comentarios

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

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

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

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

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

Entonces, nuestra tarea de mantenimiento tiene 2 partes:

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

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

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

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

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

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

Artículos relacionados:

La arquitectura MGA

Entendiendo sweep y garbage collection

El índice del blog Firebird21

El foro del blog Firebird21

 

Pasos a seguir para actualizar la versión de Firebird

7 comentarios

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

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

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

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

Paso 2. Backup con la versión vieja

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

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

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

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

Paso 4. Detener el Servidor del Firebird

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

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

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

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

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

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

Paso 6. Restaurar las bases de datos

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

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

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

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

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

Conclusión:

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

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

Artículo relacionado:

El índice del blog Firebird21

 

Mejorando el rendimiento de las bases de datos (4)

Deja un comentario

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

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

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

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

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

¿Por qué?

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

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

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

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

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

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

Artículos relacionados:

Mejorando el rendimiento de las bases de datos (1)

Mejorando el rendimiento de las bases de datos (2)

Mejorando el rendimiento de las bases de datos (3)

El índice del blog Firebird21

 

 

 

 

 

Manteniendo la Base de Datos en buen estado

2 comentarios

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

La corrupción puede deberse a:

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

Problemas de hardware

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

Problemas de software

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

Problemas de mantenimiento

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

Detectando problemas

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

¿Qué significa esto?

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

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

Solucionando problemas

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusión:

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

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

Artículo relacionado:

El índice del blog Firebird21

Usando dos servidores para aumentar la velocidad de las operaciones

Deja un comentario

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

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

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

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

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

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

Usar dos servidores.

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

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

Entonces:

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

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

¿Entonces, qué conseguimos con esto?

Que todos estén felices.

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

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

Artículos relacionados:

Modelos de ejecución del Firebird y sus diferencias

Comparando las arquitecturas

Diferencias entre SuperServer, Classic y SuperClassic

El índice del blog Firebird21

Averiguando el tamaño en bytes de una tabla

Deja un comentario

¿Cuántos bytes ocupa en el disco duro una tabla?

Para responder a esta pregunta podemos hacer uso del programa GSTAT.EXE que viene incluido en la instalación del Firebird y que lo encontrarás en su carpeta \BIN

Hay que ejecutar el programa GSTAT con la opción -t y el nombre de la tabla que nos interesa.

Ejemplo:

Queremos averiguar cuantos bytes ocupa en el disco duro la tabla PROVEEDORES, para ello ejecutamos el programa GSTAT con la opción -t PROVEEDORES:

TAMANO1

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

Page size nos indica cual es el tamaño de cada página de la Base de Datos, en bytes. Todas las páginas tienen el mismo tamaño. En este ejemplo el tamaño de cada página es 4096 bytes como podemos ver en (1)

Data pages nos indica cuantas páginas ocupa la tabla, en este ejemplo la tabla se llama PROVEEDORES y ocupa 4 páginas, como podemos ver en (2)

Entonces, para saber cuantos bytes está ocupando en el disco la tabla PROVEEDORES simplemente multiplicamos el tamaño de cada página por la cantidad de páginas (4096 * 4) y obtenemos como  resultado 16384 bytes.

Artículo relacionado:

El índice del blog Firebird21

 

Creando y usando tablas temporales

2 comentarios

En ocasiones necesitamos guardar datos en forma temporal, esos datos solamente nos son útiles durante un rato y luego ya son desechables. Para esas ocasiones es que podemos usar las tablas temporales.

¿Y por qué no usar una tabla normal y escribir un “DELETE FROM MiTabla” antes de insertarle datos? De esa manera obtendríamos los mismos resultados que usando una tabla temporal, ¿verdad?

Sí y no.

Si un solo usuario necesita de esos datos entonces sí, usar una tabla temporal o usar una tabla normal a la cual le borramos todas las filas antes de empezar el proceso sería exactamente lo mismo.

Pero la cuestión se complica cuando son dos o más los usuarios que necesitan usar esa tabla, por ejemplo si usamos tablas normales podría ocurrir algo como esto:

  • El usuario 1 borró todas las filas de la tabla
  • El usuario 1 le insertó algunas filas a la tabla
  • El usuario 1 hizo un COMMIT
  • El usuario 2 borró todas las filas de la tabla
  • El usuario 2 le insertó algunas filas a la tabla
  • El usuario 2 hizo un COMMIT
  • El usuario 1 quiere consultar las filas de la tabla …. y no encuentra las filas que él insertó, sino las filas que insertó el usuario 2

En cambio, si se usan tablas temporales algo como lo anterior jamás podría ocurrir porque cada usuario tiene su propia versión de la tabla temporal. Es decir que lo que hace el usuario 1 es totalmente independiente de lo que hace el usuario 2. El usuario 1 puede hacer lo que se le antoje en la tabla temporal que el usuario 2 jamás se enterará. Y viceversa.

A las tablas temporales en Firebird se las conoce como GTT (Global Temporary Table) y pueden ser de dos clases:

  • Confinadas a la transacción
  • Confinadas a la conexión

“Confinadas a la transacción” significa que la tabla temporal solamente puede tener filas mientras está siendo usada en una transacción. Cuando la transacción termina todas esas filas son automáticamente borradas definitivamente, sin importar como haya finalizado la transacción (con un COMMIT o con un ROLLBACK) porque en ambos casos todas las filas de la tabla temporal son borradas.

“Confinadas a la conexión” significa que la tabla temporal solamente puede tener filas mientras dure la conexión actual. Cuando la actual conexión con la Base de Datos termina, todas las filas de la tabla temporal son borradas definitivamente.

¿Cómo se crea una tabla temporal?

Escribiendo el comando “CREATE GLOBAL TEMPORARY TABLE MiTabla”, definiendo las columnas y luego finalizando con la cláusula “ON COMMIT DELETE ROWS” (si queremos una tabla temporal confinada a la transacción) o con la cláusula “ON COMMIT PRESERVE ROWS” (si queremos una tabla temporal confinada a la conexión).

¿Las tablas temporales pueden tener Primary Key?

¿Las tablas temporales pueden tener Foreign Key?

Sí, pero limitadamente. Una tabla temporal no puede referenciar a una tabla normal. Tampoco una tabla temporal confinada a la conexión puede referenciar a una tabla temporal confinada a la transacción, por lo tanto las Foreign Keys posibles son:

  • De una tabla temporal confinada a la transacción a una tabla temporal confinada a la transacción
  • De una tabla temporal confinada a la conexión a una tabla temporal confinada a la conexión
  • De una tabla temporal confinada a la transacción a una tabla temporal confinada a la conexión

¿Las tablas temporales pueden tener Unique Key?

¿Las tablas temporales pueden tener índices?

 Sí

Ejemplo 1:

CREATE GLOBAL TEMPORARY TABLE TEMP (
   TEM_IDENTI D_IDENTIFICADOR NOT NULL,
   TEM_NOMBRE D_NOMBRE40)
ON COMMIT DELETE ROWS;

ALTER TABLE TEMP ADD CONSTRAINT PK_TEMP PRIMARY KEY (TEM_IDENTI);

Aquí, creamos una tabla temporal llamada TEMP la cual estará confinada a la transacción. O sea que cuando la transacción finalice con un COMMIT o con un ROLLBACK todas las filas de esta tabla desaparecerán. También le agregamos una Primary Key.

Ejemplo 2:

CREATE GLOBAL TEMPORARY TABLE TEMP2 (
   TEM_IDENTI D_IDENTIFICADOR NOT NULL,
   TEM_NOMBRE D_NOMBRE40)
ON COMMIT PRESERVE ROWS;

ALTER TABLE TEMP2 ADD CONSTRAINT PK_TEMP2 PRIMARY KEY (TEM_IDENTI);

Aquí, creamos una tabla temporal llamada TEMP2, la cual estará confinada a la conexión. O sea que cuando la conexión con la Base de Datos finalice todas las filas de la tabla TEMP2 serán eliminadas.

Verificando que las filas de las tablas temporales confinadas a la transacción son eliminadas

Para verificar que tanto un COMMIT como un ROLLBACK eliminan a todas las filas de la tabla temporal confinada a la transacción escribimos lo siguiente:

GTT1

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

Como puedes ver, el primer SELECT mostró todas las filas insertadas pero el segundo SELECT no, ¿por qué? porque se escribió un COMMIT antes de él y con eso se finalizó la transacción. O sea que el segundo SELECT ya está en otra transacción.

GTT2

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

En este caso se escribió un ROLLBACK antes del segundo SELECT y el resultado fue el mismo que obtuvimos al escribir el COMMIT, o sea: ninguna fila mostrada. Lo cual significa que tanto si la transacción finaliza con un COMMIT o con un ROLLBACK todas las filas de la tabla temporal son eliminadas. El segundo SELECT ya está en otra transacción porque la transacción anterior finalizó con el ROLLBACK.

¿En qué casos es recomendable usar tablas temporales?

Cuando te facilitan la vida. El caso típico es cuando debes realizar una consulta que involucra a varias tablas normales pero esa consulta es demasiado complicada, tiene un montón de condiciones en el WHERE o en el HAVING, y muchos JOINs o UNIONs y te cuesta llegar al resultado deseado porque tu SELECT nunca te muestra lo que te debería mostrar, por más que lo intentas y lo intentas, nunca obtienes lo que deberías obtener y ya te da dolor de cabeza. Entonces, en lugar de estar lidiando con un SELECT inmenso, que te marea de solo mirarlo, es mucho más conveniente filtrar el contenido de las tablas involucradas, colocarlos en algunas tablas temporales y luego con unos pocos JOINs obtienes lo que buscabas.

Al usar tablas temporales seguramente escribirás más, pero todo lo que escribas será fácilmente entendible y entonces obtener las filas deseadas será muy rápido.

Entonces ¿tu SELECT involucra a varias tablas normales, las condiciones del WHERE o del HAVING son muchas y no obtienes lo que deseas? Empieza a pensar en usar tablas temporales.

Artículo relacionado:

El índice del blog Firebird21

Usando ISQL.EXE para extraer los metadatos

Deja un comentario

Como seguramente sabes, en cada instalación de Firebird viene incluido un programa llamado ISQL.EXE (Interactive SQL) con el cual puedes realizar todas las operaciones posibles en una Base de Datos (crearla, conectarte a ella, agregarle dominios, tablas, índices triggers, stored procedures, insertar filas, modificar filas, borrar filas, etc., etc. etc.)

También podemos usar ese programa para extraer los metadatos y guardarlos en un archivo de texto plano ¿para qué necesitaríamos hacer algo así? por muchas razones, por ejemplo:

  • Verificar que todos los metadatos son los correctos
  • Verificar que no esté sobrando algún dominio
  • Cambiarle el nombre a una tabla

No es necesario usar ISQL.EXE para estas tareas, las mismas puedes también realizarlas con cualquier administrador gráfico como el EMS SQL Manager, el IBExpert, el Flame Robin, etc., pero la ventaja de hacerlas con ISQL.EXE es que este programa está siempre disponible, siempre lo tenemos a nuestra disposición, en cambio podría darse el caso que no contemos con los otros programas.

Enviar los metadatos a un archivo de texto plano tiene la gran ventaja de que muy rápidamente podemos encontrar la información que necesitamos, por ejemplo:

  • ¿Hay algún índice descendente?
  • ¿Hay alguna tabla sin Primary Key?
  • ¿Los nombres de todas las tablas son los correctos?
  • ¿Todas las tablas hijas tienen Foreign Keys a sus tablas padres?
  • ¿Hay algún dominio que no se esté usando?
  • ¿Todas las tablas que deberían tener columnas calculadas, tienen columnas calculadas?
  • Y un largo etcétera

¿Cómo enviamos los metadatos a un archivo de texto usando ISQL.EXE?

  1. Abriendo la ventanita “Símbolo del sistema” del Windows
  2. Ubicándonos en la carpeta donde se encuentra el programa ISQL.EXE
  3. Escribiendo: ISQL -extract MiBaseDatos > MiArchivoTexto

Donde “MiBaseDatos” puede ser la ruta y el nombre completos de la Base de Datos o simplemente un alias que hayamos especificado en el archivo ALIASES.CONF

ISQL1

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

En este ejemplo, el alias de la Base de Datos es ERP2000 (se lo definió en el archivo ALIASES.CONF) y el nombre del archivo de texto es ERP2000.SQL (el nombre y la extensión pueden ser cualesquiera, en el caso de la extensión la que más se usa es .SQL) y el símbolo “mayor que” es el utilizado por el DOS para redirigir la salida a un archivo.

Luego de unos segundos, cuando el programa ISQL.EXE finalice su tarea tendremos un archivo de texto llamado ERP2000.SQL conteniendo los metadatos de ERP2000.FDB

Podemos ver el contenido de ese archivo de texto con cualquier programa que permita leer archivos de texto, por ejemplo con el Bloc de Notas del Windows.

ISQL2

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

En la Captura 2 puedes ver los primeros metadatos.

Ahora, ya es muy fácil revisar el archivo de texto y encontrar cualquier inconsistencia que tenga la Base de Datos.

Artículo relacionado:

El índice del blog Firebird21

 

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

1 Comentario

Lo correcto es que cuando definimos la estructura de una tabla todas sus columnas referencien a un dominio. ¿Pero qué pasa si luego queremos cambiar el dominio de una columna?

Supongamos que en muchas tablas tenemos columnas que referencian al dominio D_NOMBRE25 (que es un VARCHAR(25)) y luego queremos usar D_NOMBRE30 (que es un VARCHAR(30)). En ese caso, ningún problema, porque pasamos de un número menor (25 en este ejemplo) a un número mayor (30 en este ejemplo).

O tenemos columnas que usan un dominio D_INTEGER que es un INTEGER y queremos pasarlas a D_BIGINT que es un BIGINT. Ningún problema tampoco, ya que pasamos de INTEGER a BIGINT, de menor a mayor, está todo ok.

Sin embargo encontraremos un problema cuando queremos hacer al revés: pasar de un número mayor a un número menor. Si queremos pasar de VARCHAR(30) a VARCHAR(25) el Firebird no lo permitirá. Tampoco permitirá pasar de BIGINT a INTEGER.

¿Por qué no permite?

Porque se puede perder precisión.

Pero yo estoy seguro que los datos cabrán bien.

No importa eso. Supongamos que quieres pasar de VARCHAR(30) a VARCHAR(25) y tú estás completamente seguro que todos los datos que tienes caben en un VARCHAR(25), que ninguno necesita más caracteres. Puedes tener razón, pero el Firebird no verifica eso. Él simplemente no permite pasar de una precisión mayor a una precisión menor. Aunque el mayor número que se guarde en una columna sea el 12, tampoco te permitirá cambiar de INTEGER a SMALLINT, por ejemplo.

¿Y cómo lo soluciono si necesito hacer esos cambios?

Tienes tres formas, dos largas y una corta.

Una forma larga es revisar todas las dependencias de cada columna, eliminar o poner comentarios en las columnas relacionadas, borrar la columna problemática y luego volver a insertarla, ya con el nuevo tipo de datos. Una vez que está insertada, recrear o quitar los comentarios de todas las dependencias.

Otra forma larga es agregar una columna adicional, con el nuevo tipo de datos, copiar todos los datos de la columna original a la nueva columna, cambiar todas las referencias a la columna original por referencias a la nueva columna y finalmente borrar la columna original.

En ambos casos, si no se trata solamente de una o dos columnas sino de decenas o de centenas de columnas, el trabajo será laborioso y demandará bastante tiempo.

Hay una forma más práctica: crear una nueva Base de Datos con los cambios deseados.

Ejemplo: Cambiar el dominio D_IDENTIFICADOR que es un BIGINT a INTEGER

DOMINIOS1

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

DOMINIOS2

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

DOMINIOS3

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

despues “Next”, “Next”, “Next”, “Finish” y “Close”.

Al finalizar el proceso, tendrás un script con el contenido de tu Base de Datos. Ahora ya es simplemente cuestión de buscar a D_IDENTIFICADOR y  cambiar su tipo de BIGINT a INTEGER.

DOMINIOS4

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

Una vez hecho eso, se ejecuta el script y listo, asunto solucionado.

DOMINIOS5

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

entonces, sin importar si el dominio D_IDENTIFICADOR había sido usado 40 veces, 70 veces, o lo que fuera, al crear una nueva Base de Datos su tipo de datos es el tipo de datos que queríamos que tuviera. Realizar todos estos pasos no tarda más de uno o dos minutos, una ganancia considerable de tiempo comparado con los otros dos métodos.

Advertencia:

Para asegurarte que todos los metadatos se hayan copiado, siempre es importante que hagas esa verificación.

DOMINIOS6

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

O sea, si la Base de Datos original tiene 44 dominios, la Base de Datos nueva también debe tener 44 dominios. Si la original tiene 80 tablas la nueva también debe tener 80 tablas, etc.

Artículo relacionado:

El índice del blog Firebird21

Older Entries

Seguir

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

Únete a otros 170 seguidores