Aporte para traducir la documentación de Firebird

11 comentarios

La documentación oficial sobre Firebird 2.5 ha sido liberada … pero en ruso. ¿Por qué en ruso y no en inglés? Porque dos grandes empresas rusas han patrocinado esa documentación. Se la puede traducir al inglés, por supuesto, pero eso tiene un costo ya que no es gratis contratar a traductores profesionales.

Entonces, ya que usas Firebird podrías colaborar para que se pueda realizar esa tarea de traducción. Por supuesto que no se te pide que colabores con los 7.000 dólares, no, claro que no. Puedes colaborar con 1 dólar si quieres, que ya ayudará, cualquier contribución tuya será un aporte valioso para tener esa documentación traducida.

Luego, pasarla al castellano ya será muy fácil…pero la necesitamos en inglés.

No creas que si tú no colaboras otro lo hará. Con esa mentalidad pasaremos años y años esperando la traducción.

Ya que usas Firebird, colabora con el proyecto. Unos pocos dólares no te harán más pobre y habrás hecho un aporte significativo. Y cuanto antes tengamos la documentación en inglés más dinero podrás ganar porque aprenderás cosas nuevas que te harán ahorrar tiempo.

Para hacer la donación, puedes entrar en:

http://www.firebirdsql.org/en/donate/

Y recuerda que cualquier dólar que envíes será de gran ayuda.

Saludos.

Walter.

La noticia original (en inglés) se muestra a continuación:

“Firebird Project is pleased to announce that «Firebird 2.5 Language Reference» in Russian language is released. It is available onFirebird SQL Documentation page.
Why it is only in Russian and how to get it in English? The answer is the following: Moscow Exchange, one of the biggest Firebird users in the world, and IBSurgeon (tools and service for Firebird) have sponsored documentation development in Russian. Several Russian-speaking core developers of Firebird Project participated in documentation creation to ensure its quality.

The next step is extending this documentation to cover Firebird 3 new features: authors and editors are already working on it. However, the resulted documentation for Firebird 3 will be also in Russian.

In order to translate Firebird documentation into English, Firebird Project needs additional funds.

We need US$7000 to translate almost 500 pages of Firebird documentation into English using professional translation service, which will ensure the quality of translation.

So, if you would like to have Firebird 2.5 and 3.0 Language Reference in English in the first quarter of 2015, please help Firebird Project now with your donations (please use PayPal option): http://www.firebirdsql.org/en/donate/

Please don’t think that somebody else will pay for Firebird documentation!

Collected money will go to translation of Firebird documentation and, if USD$ 7000 threshold will be exceeded, for further development of next volumes: «Firebird Operations Guide» and others.”

 

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

Firebird 3: campaña de lanzamiento

5 comentarios

Ya falta muy poco para que el tan esperado Firebird 3 haga su aparición en escena, se tiene previsto que ese hecho acontezca en los primeros meses del año 2015. Mientras tanto, ya se ha lanzado la campaña oficial de lanzamiento, más datos puedes encontrar aquí (en inglés):

http://www.firebird3.com/

Para que sea lanzado más rápido y con mejor calidad puedes ayudar como beta tester, es decir probando la versión actual y reportando cualquier error que hayas encontrado. En un producto gratuito como lo es Firebird la ayuda de la comunidad es muy apreciada y muy necesaria. Si pocos o nadie colaboran entonces los desarrolladores tardarán muchísimo más tiempo en terminar sus tareas porque ellos además de programar también tendrán que dedicarse a hacer las pruebas, evidentemente eso les restará tiempo para lo más importante que es desarrollar un producto muy bueno y de muy alta calidad. Es por eso que necesitamos que también participes y te involucres.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

 

El problema con ASCII_CHAR(0)

4 comentarios

En el Lenguaje C y sus derivados una cadena alfanumérica finaliza cuando se encuentra un carácter cuyo código ASCII es cero.

Firebird está escrito en el Lenguaje C++ que es un derivado del Lenguaje C entonces también para él una cadena finaliza cuando se encuentra un carácter cuyo código ASCII es cero.

Ejemplo:

INSERT INTO BANCOS
           (BAN_IDENTI, BAN_NOMBRE)
    VALUES (0, 'BANCO CENTRAL')

INSERT INTO BANCOS
           (BAN_IDENTI, BAN_NOMBRE)
    VALUES (0, 'BANCO ' || ASCII_CHAR(0) || ' NACIONAL')

Si ahora terminamos la transacción con un COMMIT y luego consultamos la tabla BANCOS esto es lo que veremos:

ASCII1

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

La primera fila está correcta, pero la segunda fila no. Como entre las palabras ‘BANCO’ y ‘NACIONAL’ se introdujo un carácter ASCII con el código cero entonces no se puede ver lo que se escribió a continuación de la palabra ‘BANCO’.

Para verificar que el problema lo tenemos porque hay un carácter que tiene el código ASCII cero, escribimos esta consulta:

SELECT
   *
FROM
   BANCOS
WHERE
   BAN_NOMBRE CONTAINING ASCII_CHAR(0)

Y este es el resultado que obtenemos:

ASCII2

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

 Donde como puedes ver nos muestra que en la columna BAN_NOMBRE de la segunda fila hay al menos un carácter con el código ASCII de cero.

Solucionando el problema

Afortunadamente este problema tiene una solución muy sencilla y es escribir un comando similar al siguiente:

UPDATE
   BANCOS
SET
   BAN_NOMBRE = REPLACE(BAN_NOMBRE, ASCII_CHAR(0), '')

Donde lo que hacemos es reemplazar el carácter problemático por otro carácter; en este caso por un carácter vacío.

Para verificar que nuestra actualización haya funcionado escribimos esta consulta:

SELECT
   *
FROM
   BANCOS

Y este es el resultado que obtenemos:

ASCII3

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

Y sí, funcionó. ¡¡¡Perfecto!!!

Ahora sí vemos los nombres completos de los dos Bancos.

El problema con los índices

Como ya hemos visto, si hay un carácter que tiene el código ASCII cero entonces eso impide que veamos los caracteres que se encuentran a continuación, pero ese no es el único problema que podemos tener.

Otro problema es que los índices que creemos en una columna que tiene caracteres ASCII cuyo código es cero, se corromperán.

Por lo tanto, si descubres que un índice está corrupto y no sabes el motivo, lo que puedes hacer es verificar si en esa columna hay algunos caracteres que tienen código ASCII cero. Si ese llegara a ser el caso entonces deberás eliminar todos esos caracteres problemáticos, de la forma mostrada más arriba. Así se solucionará el problema.

Un truco de protección:

Si queremos proteger el contenido de nuestras columnas y no queremos encriptarlas entonces podemos usar este truco: colocamos un carácter cuyo código ASCII es cero en alguna parte de la columna y todo lo que esté a continuación no será mostrado en los SELECTs. Es una protección sencilla pero muy efectiva ante quienes no dominan Firebird ni son hackers profesionales.

Conclusión:

Si no vemos todo el contenido de una columna puede ser que el problema se deba a que tiene insertados algunos caracteres cuyo código ASCII es cero. Esto es mucho más probable que ocurra cuando el contenido de esas columnas proviene de fuentes externas, por ejemplo de tablas .DBF, archivos de texto, tablas de Access, etc.

La solución es reemplazar a esos caracteres que tienen código ASCII cero con algún otro carácter, por ejemplo con el espacio vacío que se obtiene escribiendo dos apóstrofos, uno a continuación del otro.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

Usando Firebird durante 24/7/365

5 comentarios

Algunas aplicaciones requieren acceso a las bases de datos durante 24/7/365, o sea durante las 24 horas del día, los 7 días de la semana y los 365 días del año. En otras palabras: sin interrupción, por ningún motivo.

Algunos ejemplos típicos son:

  • Sanatorios, hospitales, centros de salud
  • Farmacias que trabajan las 24 horas
  • Estaciones de servicio (expendio de combustibles)
  • Policía
  • Fuerzas Armadas
  • etc.

Una aplicación desarrollada para ser utilizada por ellos tiene la obligación de poder funcionar sin interrupción en cualquier momento del día. No le puedes decir al Director de un hospital que entre las 22:00 y las 23:00 no pueden registrarse los datos de los pacientes porque hay que hacerle un mantenimiento a la Base de Datos. Ni decirle a un General que si mañana el país es atacado por el enemigo entre las 02:00 y las 03:00 entonces no podrá usar la Base de Datos porque ya tiene mucha basura y que hiciste un proceso para que elimine esa basura pero requieres que nadie esté conectado a la Base de Datos.

¿Y cuál es el problema?

El problema radica en que a las bases de datos de Firebird debe hacérsele una tarea de mantenimiento llamada sweep de vez en cuando. El sweep (barrido, en castellano) tiene como finalidad eliminar a todas las versiones inútiles de las filas que fueron modificadas o borradas. Cada vez que una fila es modificada o borrada se crea una versión de esa fila llamada delta. La parte positiva de esto es que puede realizarse un ROLLBACK y dejar a la fila como se encontraba anteriormente si el usuario cambió de idea. La parte negativa es que se va acumulando basura y todas las operaciones se van volviendo más lentas y por lo tanto esa basura debe ser eliminada alguna vez.

 Y el sweep puede demorar mucho tiempo.

¿Cuándo se inicia el sweep?

El sweep puede iniciarse automáticamente (que es su valor por defecto) cuando la diferencia entre la OST (Oldest Snapshot Transaction) y la OAT (Oldest Active Transaction) es mayor que el intervalo predefinido del sweep. Ese intervalo es de 20.000 por defecto pero puede modificarse.

Si el intervalo del sweep es de 0, entonces el sweep nunca se iniciará automáticamente. Eso implica que hay que iniciarlo manualmente. Para ello se usa el programa GFIX con la opción –sweep. En este caso lo recomendable es que nadie esté usando la Base de Datos mientras se realiza el sweep.

 ¿Qué ocurre cuándo se inicia el sweep?

Que la transacción que hizo iniciar al sweep no empezará hasta que el sweep finalice. Supongamos que el intervalo del sweep es de 20.000, entonces el desafortunado usuario que quiso iniciar una transacción cuando OST – OAT fue de 20.001 tendrá que esperar hasta que finalice el sweep antes de que su transacción pueda empezar. A quienes iniciaron sus transacciones antes que él no les afectará, pero a él sí. Y si justo es un General de muy malas pulgas, entonces…

 ¿Se puede evitar que se inicie el sweep sin perjudicar el rendimiento de la Base de Datos?

Sí.

La buena noticia es que si las aplicaciones que usan la Base de Datos están correctamente diseñadas entonces nunca será necesario realizar el sweep.

La basura que se encuentra dentro de una Base de Datos puede deberse a los siguientes motivos:

  • Una operación de UPDATE que finalizó con un COMMIT
  • Una operación de DELETE que finalizó con un COMMIT
  • Una operación de UPDATE que finalizó con un ROLLBACK
  • Una operación de DELETE que finalizó con un ROLLBACK

La basura dejada por las transacciones que finalizaron con un COMMIT es recolectada (garbage collection) automáticamente cuando se hace un SELECT a esas filas. Por lo tanto, para eliminar toda la basura de una tabla que fue dejada por los COMMIT se puede escribir un simple comando: SELECT * FROM MiTabla y listo: esa tabla ya no tendrá basura dejada por los COMMIT.

La basura dejada por el ROLLBACK sin embargo, solamente puede ser eliminada con un sweep.

Por lo tanto la solución es muy simple y muy sencilla: No usar ROLLBACK.

¿Y cómo se puede evitar usar ROLLBACK?

Hay varias alternativas posibles, una posible solución sería esta:

  • Haces un SELECT a la fila que te interesa, por supuesto finalizando ese SELECT con un COMMIT. El resultado de ese SELECT lo guardas en una tabla temporal que no es de Firebird, por ejemplo en una tabla .DBF
  • Le muestras la fila de la tabla .DBF al usuario
  • Le permites que cambie los campos o que borre la fila
  • Si decide Guardar los cambios, entonces haces un UPDATE a la tabla de Firebird con los valores que se ven en la pantalla y luego el COMMIT correspondiente
  • Si decide Cancelar los cambios, entonces allí termina todo, no tocas la tabla de Firebird para nada

Como ves, en estos casos se trabaja un poco más pero te aseguras que todas las transacciones terminen con un COMMIT.

Recolectando la basura

Adicionalmente, en tu aplicación deberías tener un proceso que se encargue de hacer un SELECT * a todas las tablas de tu Base de Datos. Cuando el usuario ejecuta ese proceso entonces se hace un SELECT * FROM MiTabla1, SELECT * FROM MiTabla2, SELECT * FROM MiTabla3, etc.

Recordatorio:

La técnica mostrada en este artículo es necesaria solamente para las bases de datos que deben estar activas durante 24/7/365. En los demás casos se puede seguir el procedimiento normal de hacer el sweep automáticamente o manualmente.

Conclusión:

Las bases de datos de Firebird pueden perfectamente ser usadas en entornos que las requieren abiertas durante las 24 horas, los 7 días de la semana y los 365 días del año. Lo que debemos tener en cuenta en esos casos es que deberíamos evitar el sweep porque el sweep puede demorar mucho tiempo en bases de datos muy grandes. La forma de evitar el sweep es nunca terminar las transacciones con ROLLBACK porque las transacciones que terminan con ROLLBACK dejan basura que solamente puede ser eliminada con un sweep, en cambio la basura dejada por las transacciones que terminan con un COMMIT puede ser eliminada con un comando SELECT * FROM MiTabla.

 Entonces, el problema es causado por la forma en que Firebird actúa cuando se hace un UPDATE o un DELETE que finalizaron con un ROLLBACK pero puede ser solucionado si la aplicación finaliza todas las transacciones con un COMMIT.

Artículos relacionados:

La arquitectura MGA

Entendiendo a las transacciones

Entendiendo a los identificadores de las transacciones

Entendiendo sweep y garbage collection

El índice del blog Firebird21

El foro del blog Firebird21

 

Usando Firebird con WiFi

2 comentarios

En esta época es muy común que haya conexiones WiFi en todas partes, tanto en los hogares como  en las oficinas e inclusive en lugares públicos. Entonces la pregunta es: ¿qué tan eficiente es usar Firebird con WiFi?

Primero, hay que decir que es perfectamente posible pero … pueden ocurrir problemas. Veamos:

Pérdidas de señal

En una red WiFi casi siempre en un momento o en otro ocurren pérdidas de señales, si haces una búsqueda con Google verás que hay millones de personas quejándose de eso. La culpa de la pérdida de señal puede ser del hardware o del software. Pero vayamos a lo nuestro:

El Servidor del Firebird no sabe si te has conectado a la Base de Datos por medio de una red cableada o por medio de WiFi. Eso implica que lo importante es la calidad de tu red, no de si es cableada o WiFi.

Si la culpa de la pérdida de señal es del hardware, entonces hay que reemplazarlo. No pretendas conectar a ochopotocientas computadoras con un router WiFi barato, de esos que cuestan casi lo mismo que una docena de caramelos. Si la conexión será por WiFi entonces el router debe ser de una marca bien conocida, de muy buena calidad. Esto se lo debes aclarar muy bien a tu cliente, y por escrito, para que luego no te echen la culpa de la lentitud o del tiempo perdido. Desde luego que esto se aplica a todo tipo de redes, sean cableadas o WiFi: si tu cliente quiere buena velocidad entonces debe invertir en hardware de buena calidad, no puedes garantizar ni velocidad ni confiabilidad si no es así. Aunque en una red cableada con hardware de mala calidad podrías obtener un resultado aceptable con redes WiFi nunca es así: hardware malo implica rendimientos miserables con bases de datos.

Si la culpa de la pérdida de señal es del software entonces eso significa que no está bien configurado. Y aquí hay varios puntos que tener en cuenta:

  1. El Windows puede desconectarse del router para ahorrar energía. Puedes verificarlo entrando en Panel de Control | Administrador de dispositivos | Adaptadores de red | Nombre_de_tu_router | Propiedades | Administración de energía. Si está marcada la opción “Permitir que el equipo apague este dispositivo para ahorrar energía”, quítale la marca.
  2. En el archivo FIREBIRD.CONF que se encuentra en la carpeta donde instalaste el Firebird hay una entrada llamada DummyPacketInterval que sirve para indicarle al Servidor del Firebird cuantos segundos debe esperar antes de enviarle un paquete vacío de reconocimiento al Cliente. ¿Qué significa esto? Que si el Cliente no está enviando solicitudes al Servidor (un comando INSERT, UPDATE, DELETE, SELECT, etc., por ejemplo) el Servidor no puede saber si el Cliente continúa conectado o si se ha desconectado. La forma de verificar que continúa conectado es enviándole un paquete vacío que solamente sirve para reconocimiento. Si el Cliente le envía una respuesta al Servidor entonces el Servidor sabe que el Cliente continúa conectado. Si el Cliente no le envía una respuesta entonces evidentemente se murió la conexión. La entrada DummyPacketInterval sirve justamente para eso: para decirle al Servidor cada cuantos segundos debe verificar que el Cliente está conectado.
  3. En el punto 1. hemos visto como pedirle al Servidor que verifique la conexión pero … ¿y si queremos que sea el Cliente quien la verifique? Esto siempre es importante, antes de enviarle un comando (INSERT, UPDATE, DELETE, SELECT, EXECUTE PROCEDURE, etc.) al Servidor queremos verificar que hay una conexión activa. La forma más sencilla y rápida de conseguirlo es pidiéndole al Servidor que nos devuelva algún dato, por ejemplo la fecha de hoy. Para ello le podemos enviar un comando como: SELECT CURRENT_DATE FROM RDB$DATABASE y si como resultado obtenemos una fecha entonces estamos seguros de que la conexión está activa (se le dice “viva” en muchos documentos sobre redes). El Cliente solamente necesita saber si la conexión está activa cuando envía una solicitud, para que ésta no rebote; en los demás momentos no le importa.
  4. El Windows puede ayudarnos a mantener la conexión activa. Si se lo pedimos puede enviar paquetes de reconocimiento cada “x” segundos. Los datos en el protocolo TCP/IP viajan en grupos conocidos como paquetes, los cuales están compuestos por una cabecera, los datos del usuario, y la cola. Si en un paquete no se envían datos del usuario entonces puede usarse para saber si una conexión está activa o no. IMPORTANTE: Estas instrucciones son solamente para usuarios avanzados, si no es tu caso ni lo intentes o podrías dejar a tu Windows inservible. No lo olvides: no lo intentes si no sabes muy bien lo que estás haciendo. El Windows viene con un programa llamado REGEDIT el cual nos permite modificar el Registro, también podríamos modificarlo con un archivo que tenga la extensión .REG o con algunos otros programas utilitarios. En el Registro del Windows hay una clave llamada “Parameters” que encontrarás en HKEY_LOCAL_MACHINE | System | CurrentControlSet | Services | Tcpip. A esa clave le puedes agregar los siguientes valores DWORD: KeepAliveInterval, que determina la frecuencia con la cual el Windows repite transmisiones “keepalive” (mantener viva) cuando no recibe respuesta, puedes ponerle 1, lo cual significa que enviará paquetes cada 1 segundo; KeepAliveTime, que determina los segundos que esperará el Windows desde que se terminó la última conexión o intento de reconocimiento para enviar reconocimiento, si por ejemplo le pones 60 eso significa que esperará que hayan transcurrido 60 segundos después de la última conexión o intento de reconocimiento antes de verificar si está activa; TcpMaxDataRetransmissiones, que determina cuantas veces como máximo se enviará un paquete antes de decidir que la conexión está muerta, su valor por defecto es de 5.

Múltiples dispositivos usando la red WiFi

Además del problema que podemos tener con las pérdidas de señal hay otro problema que inclusive puede llegar a ser peor: los usuarios querrán usar la red WiFi para conectar no solamente las computadoras que accederán a las bases de datos sino también tabletas, teléfonos celulares smart, televisores smart, relojes smart, y cualquier otro dispositivo habido o por haber que pueda conectarse a una red WiFi.

Entonces, no podrás evitar que a algún “genio” se le ocurra ver una película on-line mientras otros usuarios necesitan una red rápida. Es muy difícil evitar esas conexiones piratas y siempre tendrán algún muy buen motivo para hacerlas … y lo que conseguirán será que los tiempos de respuesta de las solicitudes a las bases de datos sean paupérrimos.

Conclusión:

 Es posible conectarse a bases de datos de Firebird a través de redes WiFi, pero si se desea un buen tiempo de respuesta el hardware debe ser de buena calidad y el software debe estar bien configurado.

Sin embargo, una buena red cableada siempre será mejor que una buena red WiFi.

Para deslindar responsabilidades siempre es una muy buena idea hacerle firmar un documento a tu cliente que diga algo como: “Para trabajar con bases de datos son preferibles las redes cableadas, las redes WiFi solamente tienen un buen desempeño cuando el hardware es de muy buena calidad y el software está correctamente configurado, en otro caso es una mala opción usarlas. Pero aún con una buena red WiFi siempre la red cableada será más rápida y más confiable. Mi recomendación por lo tanto es usar una red cableada.”

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

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

Deja un comentario

Como recordarás, al Firebird hay unas cuantas transacciones que le interesan, ellas son:

  • Oldest Transaction, representada por las letras OIT que significan Oldest Interesting Transaction
  • Oldest Active Transaction, representada por las letras OAT
  • Oldest Snapshot Transaction, representada por las letras OST
  • Next Transaction, representada por las letras NT

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

Entendiendo los identificadores de las transacciones

Los números de las transacciones siempre van en aumento, hasta que se realiza un ciclo backup/restore.

¿Qué sucede cuándo se realiza un ciclo backup/restore?

 Que en la Base de Datos restaurada (no en la original, sino en la restaurada), el identificador de todas las transacciones que finalizaron con un COMMIT es puesto en 1.

¿Y por qué el número de la Next Transaction no es 2, ó 3, ó un número muy cercano a ellos?

Después de todo, podrías pensar que si todas las transacciones que finalizaron con un COMMIT tienen el identificador 1, la Next Transaction debería tener el número 2. O si el programa GBAK abre alguna transacción más, entonces un número muy cercano al 2. Pero no es así, la Next Transaction puede estar muy alejada del número 2.

La respuesta es que el programa GBAK puede abrir muchas transacciones cuando restaura una Base de Datos.

Ejemplo:

En la ventanita “Símbolo del sistema” escribimos el comando GSTAT -h para conocer los identificadores de las transacciones de una Base de Datos.

NT1

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

Se hace el ciclo backup/restore con la opción -v[erbose] y luego se ejecuta el comando GSTAT -h en la Base de Datos restaurada, obteniendo estos valores:

NT2

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

En la Captura 1. podemos ver los identificadores originales de las transacciones y en la Captura 2. podemos ver los valores de los identificadores en la Base de Datos restaurada. Y lo que llama la atención es que la Next Transaction es 304, un número aparentemente muy alto, muy alejado del 3 que uno podría esperar. ¿Por qué?

Porque el programa GBAK abre varias transacciones:

  • Al iniciar la restauración de la Base de Datos, la Next Transaction es puesta en 1
  • Luego, para restaurar los metadatos puede abrir nuevas transacciones
  • Si se usó la opción -o[nce] se iniciará una transacción por cada tabla restaurada
  • Si se usó la opción -v[erbose] se iniciará una transacción por cada índice restaurado

Entonces, ahora sí ya tiene sentido del por qué la Next Transaction está tan alejada del número 1. Es que el programa GBAK abre varias transacciones al restaurar un backup.

Fíjate en un detalle interesante. Como la Base de Datos restaurada aún no ha sido utilizada entonces no importa que los identificadores de las otras transacciones (OIT, OAT, OST) estén desfasados. En este momento nada significan y por lo tanto el número que tengan es irrelevante.

Sin embargo, si te conectas a la Base de Datos e inicias una transacción cuando te desconectes esos números sí ya estarán actualizados. Por ejemplo:

NT3

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

Aquí, usando el programa ISQL nos conectamos a la Base de Datos restaurada, salimos con un EXIT (al salir con un EXIT de ISQL se ejecuta automáticamente un COMMIT, si se sale con un QUIT entonces se ejecuta automáticamente un ROLLBACK) y volvemos a verificar los identificadores de las transacciones ¿y con qué nos encontramos?

Conque los identificadores OIT, OAT y OST se han actualizado.

Estos nuevos valores sí son los correctos. Los anteriores no tenían importancia porque aún no se había usado la Base de Datos, entonces eran irrelevantes sus valores.

Para verificar que la opción -v[erbose] realmente inicia varias transacciones se restauró la misma Base de Datos pero sin esa opción, y este fue el resultado obtenido:

NT4

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

Como puedes ver ahora la Next Transaction es solamente 84, entonces se comprobó que usando la opción -v[erbose] el programa GBAK inicia varias transacciones. Usando esa opción, Next Transaction fue 304, sin usarla fue 84. Desde luego que esos números variarán en tu caso porque dependen de la cantidad de índices que hayas definido.

Conclusión:

Al hacer un ciclo backup/restore con el programa GBAK, en la nueva Base de Datos el valor de la Next Transaction empieza con 1 pero como el programa GBAK abre varias transacciones para poder realizar sus tareas, entonces al finalizar la restauración el valor de la Next Transaction puede estar bastante alejado del 1, dependiendo de la cantidad de transacciones que el programa GBAK tuvo que abrir.

No importa cuales son los valores de los identificadores OIT, OAT, y OST al finalizar la restauración porque aún no han sido utilizados. Solamente después de finalizar la primera transacción sus valores serán actualizados y estarán muy próximos al de la Next Transaction.

Artículos relacionados:

Entendiendo los identificadores de las transacciones

El índice del blog Firebird21

El foro del blog Firebird21

Los archivos temporales del Firebird

Deja un comentario

El Firebird a veces necesita crear archivos temporales, eso generalmente ocurre cuando en un comando SELECT se usa la cláusula ORDER BY y no existe un índice que pueda ser usado, o cuando ya no hay espacio disponible en la porción de memoria RAM que utiliza para los ordenamientos, o cuando se crean tablas temporales (o sea: tablas GTT) de gran tamaño.

Si el Servidor del Firebird recibe la orden de ejecutar un SELECT que contiene la cláusula ORDER BY y no hay un índice que pueda utilizar entonces evidentemente debe ordenar esas filas en algún lado para poder mostrarlas ordenadas.

¿Dónde se realiza ese ordenamiento?

El Firebird usa una porción de la memoria RAM a la cual llama Sort Buffer para realizar en ella los ordenamientos. Sin embargo, el espacio del Sort Buffer es limitado y en ocasiones puede ser insuficiente.

¿Qué sucede cuando no hay espacio suficiente en el Sort Buffer para realizar allí el ordenamiento?

Que el Firebird crea archivos temporales. Como no dispone de memoria RAM (la cual es rapidísima) para ordenar el resultado de la consulta entonces crea en el disco duro archivos temporales. Esto es mucho más lento que usar la memoria RAM pero funciona y no hay otra alternativa: hay que crear archivos temporales sí o sí.

¿Cuáles son los nombres de esos archivos temporales?

Todos los archivos temporales creados por el Firebird empiezan con los caracteres FB_ y dependiendo de su contenido serán los siguientes caracteres, por ejemplo si empieza con:

FB_QUERY_  significa que es un archivo temporal creado porque se usó la cláusula ORDER BY sin tener un índice disponible

FB_TABLE_ significa que se creó una tabla temporal (una tabla GTT)

¿Cómo puedo especificar dónde se crearán esos archivos temporales?

Por defecto, si el Firebird es iniciado como un servicio entonces los archivos temporales son creados en la carpeta temporal del Windows, normalmente en C:\WINDOWS\TEMP\ pero si se quiere crearlos en otras carpetas hay dos formas de hacerlo:

  1. Especificando las variables de entorno FIREBIRD_TMP, TEMP, TMP
  2. Cambiando la entrada TempDirectories del archivo FIREBIRD.CONF que se encuentra en la carpeta donde instalaste el Firebird

TEMP1

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

En la Captura 1. podemos ver como especificar una carpeta donde guardar los archivos temporales del Firebird que no sea la que utiliza el Windows. Por supuesto que la carpeta especificada (en este caso: E:\FIREBIRD_ARCHIVOS_TEMPORALES) debe existir y el nombre de la carpeta puede ser cualquiera, el nombre mostrado en la Captura 1. es solamente un ejemplo.

TEMP2

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

En la Captura 2. podemos ver como especificar cual será la carpeta temporal en el archivo FIREBIRD.CONF, recordando que debemos borrar el símbolo de numeral que se encuentra a la izquierda de la entrada TempDirectories ya que el símbolo # indica que lo que sigue a continuación es un comentario.

El autor de este blog recomienda que se especifique la carpeta de los archivos temporales en la entrada TempDirectories y que de ser posible se utilice un disco RAM para ese propósito.

¿Puedo tener más de una carpeta para guardar los archivos temporales?

Sí, sin problema, lo único que debes hacer es separarlas con un punto y coma, por ejemplo:

TempDirectories=E:\FIREBIRD_TEMP;F:\ARCHIVOS_TEMP_FIREBIRD;G:\FIREBIRD_TEMP

¿Puedo especificar el tamaño de las carpetas dónde se guardarán los archivos temporales?

Sí, si lo deseas puedes especificar inclusive el tamaño en bytes que se usará en cada carpeta, por ejemplo:

TempDirectories=E:\FIREBIRD_ARCHIVOS_TEMPORALES 100000000

o

TempDirectories=E:\FIREBIRD_TEMP 250000000;F:\TEMP_FILES 300000000;G:\MIS_TEMPORALES 100000000

¿Por qué los archivos temporales del Firebird a veces tienen un tamaño muy grande?

Porque el Firebird expande las columnas CHAR y VARCHAR a su tamaño especificado en la definición de la tabla. Muchos programadores saben que el Firebird no guarda en el disco duro el tamaño especificado en la tabla sino que guarda el contenido de esas columnas comprimido. Entonces saben que pueden especificar un tamaño mucho mayor al necesario sin problema. Por ejemplo, supongamos que la mayor longitud que necesitamos en una columna es de 850 bytes pero en la definición de la tabla usamos 1.000 bytes, 4.000 bytes ó 12.500 bytes; estará todo bien, porque el Firebird nunca guardará más de 850 bytes en el disco duro, sin importar como se definió la columna. Eso en general es algo muy bueno.

Sin embargo, al hacer un SORT a esa columna la cosa cambia, porque allí sí el Firebird utiliza el tamaño usado en la definición de la columna.

De esta manera, inclusive a veces podríamos encontrarnos que tenemos un archivo temporal … cuyo tamaño es mayor al tamaño de la Base de Datos.

Así que, a no exagerar con el tamaño de las columnas CHAR y VARCHAR si existe la posibilidad de que alguna vez sean usadas en la cláusula ORDER BY de un comando SELECT.

¿Puedo borrar los archivos temporales?

Sí, si el Firebird no los está usando. El Windows no permite que se borre un archivo si algún programa lo está usando, esa es una muy buena medida de precaución.

Entonces, puedes intentar borrar cualquier archivo temporal. Si tuviste éxito eso significa que ningún programa lo estaba usando. Si no pudiste borrarlo entonces tendrás que esperar hasta que deje de ser usado.

Conclusión:

A veces el Firebird necesita crear archivos temporales en el disco duro. Nosotros podemos decirle cuales carpetas debe utilizar para eso e inclusive la cantidad de bytes que puede usar en cada carpeta.

Para aumentar la velocidad de los ordenamientos lo recomendable es usar un disco RAM, si eso no es posible entonces lo recomendable es que los archivos temporales se guarden en un disco duro distinto al usado para guardar las bases de datos.

Artículos relacionados:

Creando y usando tablas temporales

Usando un disco RAM para aumentar la velocidad

Acelerando los SORT

Configurando al Firebird

¿En cuál carpeta tener las bases de datos?

El índice del blog Firebird21

El foro del blog Firebird21

Older Entries