Entendiendo a GSTAT (1)

Deja un comentario

GSTAT es una herramienta que se usa desde la línea de comandos y su misión es mostrarnos estadísticas sobre una Base de Datos. Deber ser ejecutado en la misma computadora donde se encuentra el Servidor del Firebird y solamente puede ser ejecutado por el usuario SYSDBA o por el usuario que creó la Base de Datos. Como el tema es bastante largo, lo trataremos en varios artículos.

Se lo invoca de la siguiente manera:

GSTAT [opciones] MiBaseDatos

donde MiBaseDatos debe constar de la ruta completa y las opciones disponibles son las siguientes (se pueden abreviar con las letras dentro de los paréntesis):

-(a)ll       Analiza las páginas de datos y las páginas de índices
-(d)ata      Analiza solamente las páginas de datos
-(h)eader    Analiza solamente la página cabecera
-(i)ndex     Analiza solamente las páginas de índices
-(s)ystem    Como -(a)ll pero también incluye estadísticas sobre las tablas internas
-(u)ser      Nombre del usuario
-(p)assword  Contraseña del usuario
-(f)etch     Extrae la contraseña de un archivo de texto
-(r)ecord    Muestra el tamaño y estadísticas de la versión
-(t)able     Solamente analiza las tablas que se especifican aquí
-(tr)usted   Usa autentificación de confianza
-(z)         Muestra la versión de GSTAT

Como la información que muestra GSTAT puede ser muy larga, y ocupar inclusive cientos o miles de líneas, lo recomendable es enviar esa información a un archivo de texto para poder analizarla con mayor facilidad.

Entonces, la forma correcta de invocarlo es así:

gstat01

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

Donde hemos usado > NombreArchivo para indicarle que envíe su salida a un archivo de texto.

En nuestro ejemplo ese archivo de texto se llama TRANSC.TXT, y usamos el Bloc de Notas del Windows para ver su contenido.

gstat02

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

En la Captura 2. se ven solamente las primeras líneas del archivo TRANSC.TXT, en realidad ese archivo es muchísimo más grande, tiene varios cientos de líneas.

Veamos ahora con mayor detenimiento el significado y utilidad de cada una de las opciones que tenemos disponibles:

Opción -header

Podemos abreviarla como -h

gstat03

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

En la Captura 3. invocamos a GSTAT con la opción -h para que nos muestre la información que se encuentra en la cabecera de esta Base de Datos.

gstat04

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

Flags (Banderas)

Este número es siempre cero.

Checksum (Suma de comprobación)

Es siempre 12345 y sirve para comprobar si hay algún error físico en el disco duro. Cuando la página de cabecera es guardada en el disco y más tarde leída el checksum de la página de cabecera es comparado con 12345 y si son distintos, entonces un error de checksum es mostrado.

Generation (Generación)

Es un contador que se incrementa cada vez que se escribe algún dato en la página de cabecera.

Page size (tamaño de la página)

Es el tamaño que tiene cada una de las páginas de la Base de Datos, en bytes.

ODS version (versión de on-disk-structure)

El número de versión de on-disk-structure, sirve para conocer con cual versión del Firebird se creó la Base de Datos.

10.0 = 1.0
10.1 = 1.5
11.0 = 2.0
11.1 = 2.1
11.2 = 2.5
12.0 = 3.0

Oldest transaction (la transacción más antigua)

El identificador de la más antigua transacción “interesante”. Una transacción es “interesante” cuando no ha finalizado con un COMMIT. Se le abrevia como OIT.

Oldest active (la más antigua transacción activa)

El identificador de la más antigua transacción activa. Una transacción está activa cuando no ha finalizado ni con un COMMIT ni con un ROLLBACK y no está en el limbo. Se la abrevia como OAT.

Oldest snapshot (la más antigua transacción instantánea)

El identificador de la más antigua transacción cuya basura no puede ser recolectada. La basura no será recolectada de esta transacción ni de las transacciones que tengan un identificador mayor. Se la abrevia como OST. La diferencia entre la Oldest snapshot y la Oldest active determina cuando un sweep automático ocurre. El valor por defecto es 20000.

Next transaction (siguiente transacción)

El identificador que se le asignará a la siguiente transacción. Se la abrevia como NT.

Bumped transaction (transacción superada)

 Está obsoleta, ya no se usa. Siempre es 1.

Sequence number (número de secuencia)

Número de secuencia de la página de cabecera. Está obsoleta, ya no se usa. Siempre es 0.

Next attachment ID (siguiente identificador de conexión)

El identificador de la siguiente conexión a esta Base de Datos. Indica cuantas veces se han conectado a esta Base de Datos. Cada vez que una aplicación (cualquier aplicación) se conecta a esta Base de Datos este número aumenta en 1. (La excepción es GSTAT, porque GSTAT no se conecta de la forma normal).

Implementation ID (Identificador de la implementación)

Cuando la Base de Datos fue creada, pudo haber sido creada en una computadora que tenía diferente hardware y sistema operativo que la computadora en la cual se encuentra ahora. El Implementation ID muestra un número que identifica al hardware en el cual la Base de Datos fue creada.

Shadow count (cuenta de espejo)

Aunque en realidad shadow significa sombra, aquí se lo traduce como espejo. Muestra la cantidad de archivos adjuntos a esta Base de Datos o disponibles para ser usados por esta Base de Datos. Este número a veces es incorrecto, por eso es preferible escribir SHOW DATABASE en el programa ISQL para tener la información exacta.

Page buffers (buffers de página)

Es la cantidad de páginas que se pueden almacenar en la memoria caché. Un valor 0 significa que se usa el valor predeterminado, que por defecto es 2048 en SuperServer, y 75 en Classic y en SuperClassic. Se puede cambiar ese valor en el archivo FIREBIRD.CONF, en la entrada DefaultDbCachePages. También puede cambiarse con el programa GFIX.

Next header page (siguiente página de cabecera)

El número de página que tiene la siguiente página de cabecera. En general todas las bases de datos tienen una sola página de cabecera y por lo tanto este número es casi siempre 0.

Database dialect (dialecto de la Base de Datos)

Es siempre 3 en las nuevas versiones de Firebird. Anteriormente también podía ser 1, pero el dialecto 1 ya está obsoleto.

Creation date (fecha de la creación)

La fecha en la cual esta Base de Datos fue creada originalmente o la fecha en la cual fue restaurada por el programa GBAK.

Attributes (atributos)

Atributos que puede tener la Base de Datos.

no reserve. Todas las páginas son rellenadas al 100%, no se deja espacio libre en las páginas para INSERT, UPDATE, o DELETE. Es útil solamente en las bases de datos que son de sólo lectura.

force write. Los datos son escritos en el disco duro en el momento en que se solicita, no se guardan en la memoria caché sino que son directamente escritos en el disco. Esto es más lento que guardar los datos en la memoria caché pero es mucho más seguro, sobre todo en Windows.

shutdown. La Base de Datos ha sido cerrada y no puede ser utilizada.

read only. La Base de Datos es de sólo lectura, nada se puede escribir en ella.

multi-user maintenance. La Base de Datos está cerrada para realizar mantenimiento en ella. Solamente puede ser abierta por el usuario SYSDBA o por el creador de la Base de Datos o por ambos.

single-user maintenance. La Base de Datos está cerrada para realizar mantenimiento en ella. Puede ser abierta o por el usuario SYSDA o por el creador de la Base de Datos, pero solamente por uno de ellos, no por ambos.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird2

Anuncios

Error con IN AUTONOMOUS TRANSACTION

2 comentarios

Como sabes, IN AUTONOMOUS TRANSACTION puede llegar a ser muy útil algunas veces porque todo lo que escribamos dentro de esa construcción finalizará con un COMMIT, sin importar como finalice la transacción principal (con un COMMIT o con un ROLLBACK)

Sin embargo … lastimosamente no es perfecta, tiene un problema que puede llegar a ser muy grave:

Dentro de un trigger de la Base de Datos relacionado con una transacción entra en un ciclo infinito.

Lo entenderemos mejor viendo el siguiente código:

CREATE TRIGGER TRANSACCION_INICIA
   ACTIVE ON TRANSACTION START
   POSITION 0
AS
BEGIN
   
   IN AUTONOMOUS TRANSACTION DO BEGIN

   END

END;

No importa lo que escribamos dentro del BEGIN … END de la transacción autónoma, y aún si nada escribimos como en este ejemplo, la Base de Datos se “colgará”. También se colgará si escribimos una sentencia simple (es decir, sin el BEGIN … END)

Los triggers de la Base de Datos en los cuales NUNCA JAMÁS debemos escribir IN AUTONOMOUS TRANSACTION son:

  • TRANSACTION START
  • TRANSACTION COMMIT
  • TRANSACTION ROLLBACK

En cualquiera de ellos, IN AUTONOMOUS TRANSACTION entrará en un ciclo infinito (no me preguntes el motivo, es así y ya. Evidentemente se trata de un “bug”).

Sin embargo, sí es posible usar IN AUTONOMOUS TRANSACTION con los triggers de conexión a la Base de Datos, con ellos no hay problema, es decir que puedes con toda tranquilidad escribirla en:

  • CONNECT
  • DISCONNECT

El siguiente código, sí funcionará, sin problemas:

CREATE TRIGGER CONEXION_INICIA
   ACTIVE ON CONNECT
   POSITION 0
AS
BEGIN
    
   IN AUTONOMOUS TRANSACTION DO BEGIN
    
   END
 
END;

Aquí funciona porque es un trigger de la Base de Datos relacionado con la conexión, con los que no funciona es con los relacionados a la transacción.

Artículos relacionados:

Registrando errores en una tabla de LOG

Otro ejemplo del uso de la tabla de LOG

El índice del blog Firebird21

El foro del blog Firebird21

Evitando actualizaciones concurrentes del mismo registro

2 comentarios

Como ya hemos visto, hay técnicas para evitar conflictos entre transacciones, esos conflictos ocurren cuando dos o más de ellas quieren actualizar o borrar el mismo registro al mismo tiempo.

Evitando conflictos en las transacciones

Pero a veces no podemos usar esas técnicas porque debemos estar actualizando a los mismos registros concurrentemente, sí o sí. ¿Cómo resolvemos el problema en ese caso?

Bien, primero veamos de manera simplificada cuales son las tareas que realiza el motor del Firebird cuando una transacción READ WRITE READ COMMITTED quiere actualizar un registro:

  1. Lee el registro
  2. Evalúa los datos que se guardarán en el nuevo registro
  3. Escribe el nuevo registro en una página de datos

Recuerda que en Firebird cada vez que se usa el comando UPDATE o el comando DELETE se le está agregando un nuevo registro a la Base de Datos. Si la transacción finaliza con un COMMIT entonces el nuevo registro será el que vale, el que sirve, el que se usará de ahí en adelante y el registro viejo será basura. En cambio, si la transacción finaliza con un ROLLBACK el registro anterior seguirá siendo usado y el nuevo pasará a engrosar la basura. Como ves, en ambos casos se genera basura, y ese es el motivo por el cual periódicamente hay que eliminarla.

¿Y cuál es el problema con esta forma de proceder del Firebird?

Una transacción que se inició con los parámetros anteriores, en el paso 1. lee el último registro confirmado (o sea, que finalizó con un COMMIT) y al llegar al paso 3. vuelve a leerlo para asegurarse que se trata del mismo registro. Si no lo hiciera entonces podría estar silenciosamente sobreescribiendo el trabajo de otra persona.

Si el registro que leyó en el paso 1. es distinto del registro que leyó en el paso 3. entonces lanzará una excepción que nos informará que hay un error en la actualización. Un deadlock. Un bloqueo mortal. La actualización falló.

El tiempo que el Firebird demora en completar los pasos del 1. al 3. es pequeñísimo, se mide en milisegundos, así que usualmente no tendremos problemas con eso … salvo cuando varios usuarios estén actualizando a muchísimos registros al mismo tiempo, pues allí sí tales circunstancias podrían darse.

El Firebird solamente “bloquea” a un registro cuando lo está actualizando, mientras no lo esté actualizando el registro está desbloqueado. Esto significa que si queremos bloquear a un registro, debemos actualizarlo, aunque sea escribiendo en él lo mismo que ya tenía escrito.

Y eso es lo que hace el comando SELECT … WITH LOCK.

Y es ese comando el que deberíamos usar cuando queremos ejecutar un proceso de actualización y queremos tener la seguridad de que no tendremos conflictos con otras transacciones. Esta es una forma de transacción pesimista, la cual aunque no es recomendada en Firebird a veces puede ser necesario usar y por ese motivo es que existe.

El algoritmo entonces sería el siguiente:

SET TRANSACTION 
READ WRITE 
WAIT 
READ COMMITTED 
NO RECORD_VERSION 
LOCK TIMEOUT 5 ;
SELECT MisColumnas FROM MiTabla WHERE MiCondición WITH LOCK ;
UPDATE MiTabla SET MisColumnas = MisNuevosValores WHERE MiCondición ;

¿Qué se hizo aquí?

Primero: se establecieron los parámetros de la transacción:

READ WRITE: La transacción puede leer y también puede escribir en los registros

WAIT: Si otra transacción está actualizando el registro, esta transacción esperará

READ COMMITTED: Leerá la última versión confirmada del registro, sin importar cuando ese registro fue confirmado. Si antes de que esta transacción empezara, o después.

NO RECORD_VERSION: No podrá leer un registro que otra transacción está actualizando

LOCK TIMEOUT 5: Esperará un máximo de 5 segundos hasta que la otra transacción que está actualizando al registro finalice con un COMMIT o con un ROLLBACK. Desde luego que podrías poner más o menos segundos, como te parezca.

Segundo: se consultaron y se bloquearon los registros. Al usar la cláusula WITH LOCK le estamos diciendo que también haga un UPDATE silencioso, para que ninguna otra transacción pueda actualizar a este registro antes de que nosotros lo actualicemos. Fíjate que este segundo paso puede fallar, fallará si ya otra transacción tiene bloqueado a cualquiera de los registros de MiTabla que cumplen con MiCondición.

Tercero: se actualizaron los registros. Si el segundo paso finalizó con éxito entonces este tercer paso también finalizará con éxito. Para eso justamente sirve el SELECT … WITH LOCK, para asegurarnos de que el UPDATE finalizará con éxito.

Observaciones:

Este método es muy efectivo, aunque raramente necesario. En Firebird lo normal y lo correcto es que las transacciones sean optimistas y este es un ejemplo de transacción pesimista. Por ello lo recomendable es que los registros que son bloqueados por el SELECT … WITH LOCK sean muy pocos, idealmente solamente un registro y no más de uno.

La ventaja de este método es que si el SELECT … WITH LOCK finalizó con éxito entonces tendremos una seguridad del 100% de que el UPDATE también finalizará con éxito. Desde luego que para que eso sea verdad, MiCondición debe ser la misma tanto en el SELECT como en el UPDATE. Si ponemos condiciones distintas, nada podremos asegurar.

Conclusión:

En general, y como regla, deberíamos evitar usar los comandos UPDATE y DELETE ya que los conflictos entre transacciones solamente pueden ocurrir cuando se usan esos comandos.

Sin embargo, a veces es necesario usar esos comandos, no podemos evitarlo. En esos casos casi siempre es preferible que nuestras transacciones sean optimistas, porque el Firebird está optimizado para usar transacciones optimistas. Solamente cuando no tenemos alternativa deberíamos usar transacciones pesimistas, y en este artículo se vio una técnica de ello.

Artículos relacionados:

Entendiendo a las transacciones

Modos de bloqueo de las transacciones

Transacciones optimistas y transacciones pesimistas

Algo más sobre transacciones optimistas y transacciones pesimistas

¿Por qué en Firebird es preferible que las transacciones sean optimistas?

Evitando conflictos en las transacciones

Entendiendo las páginas de la Base de Datos

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

 

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

Entendiendo las páginas de la Base de Datos

Deja un comentario

El Firebird guarda todos los datos en “páginas”. Nada hay dentro de una Base de Datos que no esté dentro de una página.

¿Qué es una página?

Es una cantidad predefinida y fija de bytes que son tratados como una unidad.

 ¿Cuál es el tamaño en bytes de una página?

Es el tamaño que se definió cuando se creó la Base de Datos. Si no se especificó un tamaño entonces tendrá el valor por defecto que en Firebird 2.5 es de 4096 bytes. Los tamaños posibles son los siguientes:

  • 4096 bytes
  • 8192 bytes
  • 16384 bytes

¿Se puede cambiar el tamaño en bytes de las páginas?

Sí, se puede, para eso se debe usar el programa GBAK. Al restaurar un backup se puede especificar el tamaño que tendrán las páginas de la Base de Datos restaurada. La opción para ello es -page_size [tamaño], por ejemplo: -page_size 8192

Recuerda que el tamaño de las páginas de la Base de Datos original no cambia, el que cambia es el tamaño de las páginas de la Base de Datos restaurada.

¿Y qué ocurre si especifico un tamaño que no sea ninguno de los anteriores?

Entonces el Firebird usará uno de los anteriores. Si el tamaño que especificaste es menor que 4096, usará 4096. Si es mayor que 4096, usará el tamaño predefinido que sea menor al que especificaste. Por ejemplo, si especificaste 16000, usará 8192 porque 8192 es menor que el tamaño que especificaste.

 ¿Y cómo puedo saber el tamaño de las páginas de mi Base de Datos?

Hay dos formas:

1. Usando el programa GSTAT con la opción -h, como vemos a continuación:

PAGES01

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

El número que verás a continuación de “Page size” siempre será uno de los siguientes: 4096, 8192, 16384

2. Haciendo un SELECT a la tabla MON$DATABASE

SELECT
   MON$PAGE_SIZE
FROM
   MON$DATABASE

NOTA: Versiones antiguas de Firebird también permitían 1024 y 2048, pero ahora esos tamaños ya son obsoletos.

¿Cuántas clases de páginas distintas hay?

Aunque todas las páginas tienen exactamente el mismo tamaño, se las utiliza para distintas cosas. Para saber en que se utiliza cada página tienen un número hexadecimal que las identifica al cual se le llama “tipo de página”.

  • 0x01. Es la Header Page (página de cabecera) y solamente hay una. En ella se guardan datos tales como: el tamaño de las páginas, la versión del ODS, la transacción más antigua, la última transacción activa, la siguiente transacción, etc.
  • 0x02. Es una Page Inventory Page (página de inventario). Puede haber varias. Su sigla es PIP. Siempre la primera PIP está a continuación de la Header Page. Se usa para saber cuales son las páginas que tiene actualmente la Base de Datos y si están libres para ser usadas (o sea, “disponibles”) o no.
  • 0x03. Es una Transaction Inventory Page (página de inventario de las transacciones). Siempre hay al menos una. Aquí se guardan el número de las transacciones y su estado (activa, limbo, confirmada, desechada). El mayor número posible de transacción es 2.147.483.647, cuando una Base de Datos alcanzó a ese número de transacciones se debe hacer un ciclo backup/restore para que el número de la transacción regrese a 1.
  • 0x04. Es una Pointer Page (página de punteros). Hay al menos una por cada tabla (de metadatos o del usuario) que tiene la Base de Datos. En la Pointer Page se guardan los números todas las páginas de datos que pertenecen a una sola tabla. Eso significa que en una página de datos solamente puede haber filas de una sola tabla, nunca se mezclan filas de una tabla con las de otra tabla en una página de datos. Las tablas grandes tienen muchas Pointer Page.
  • 0x05. Es una Data Page (página de datos). Hay al menos una por cada tabla que tiene filas (tanto sean metadatos como del usuario). Todos los datos de esta página corresponden a una sola tabla.
  • 0x06. Es una Index Root Page (página del índice raíz). Cada tabla de la Base de Datos tiene una Index Root Page, la cual describe los índices que tiene esa tabla. Aunque una tabla no tenga índices igual tiene una Index Root Page.
  • 0x07. Es una Index B-Tree Page (página de índice B-Tree). Si una tabla no tiene índices, no tendrá una página de tipo 0x07. Todos los datos de una página Index B-Tree corresponden a un solo índice de una sola tabla.
  • 0x08. Es una BLOB Data Page (página de datos para columnas de tipo BLOB). Solamente existen para tablas que tienen al menos una columna de tipo BLOB. En esta página se guarda el contenido de esas columnas. Todos los datos corresponden a una sola columna de una sola tabla.
  • 0x09. Es una Generator Page (página de generadores). Hay al menos una por cada Base de Datos, aunque ningún generador (también llamado “secuencia”) haya sido definido.
  • 0x0A. Es una Write Ahead Log Page (página de escribir por delante el log). Hay al menos una por cada Base de Datos, pero actualmente no se la está usando, es un desperdicio de espacio, y probablemente ya no exista en Firebird 3.0

¿Qué sucede con una página de datos cuando las filas que guardaba son eliminadas?

Supongamos que en una página se encuentran las filas de la tabla VENTAS y escribes DELETE FROM VENTAS borrando así a todas esas filas. ¿Qué pasa con la página, se la elimina de la Base de Datos? No, permanece ahí, pero en la PIP (Page Inventory Page) se la marca como “disponible”. O sea que puede ser usada nuevamente, y cuando el Firebird necesite una nueva página usará a una de las “disponibles”. ¿Por qué eso? Porque para el Firebird es mucho más rápido usar una página “disponible” (es decir, libre, que nadie la está usando) que alojar una nueva página en el disco duro.

De la misma manera, cuando se hace una “recolección de basura” pueden quedar muchas páginas “disponibles”. Eso es debido a que la “recolección de basura” no elimina a esas páginas de la Base de Datos, sino que las marca como “disponibles”.

Por supuesto que esto implica que si hay muchas páginas “disponibles” hay mucho espacio dentro de la Base de Datos que no está siendo usado para algo útil. Si quieres disminuir el tamaño de la Base de Datos puedes hacer un ciclo backup/restore para que todas esas páginas “disponibles” desaparezcan físicamente.

Resumiendo:

Todo dentro de una Base de Datos de Firebird se guarda dentro de una página, nada está afuera de una página. Todas las páginas tienen el mismo tamaño, aunque se las use para cosas distintas. Ese tamaño se puede especificar al crear la Base de Datos o puede ser cambiado cuando se restaura un backup con el programa GBAK. Se puede usar el programa GSTAT con la opción -h o un SELECT a la tabla MON$DATABASE para conocer el tamaño de las páginas. Cada página dentro de la Base de Datos tiene un número hexadecimal que la identifica y al cual se conoce como el “tipo de página”. Todos los datos dentro de una página corresponden a la misma cosa, nunca se mezclan. Por ejemplo, si una página se usa para guardar las filas de la tabla VENTAS en esa página solamente habrá filas de la tabla VENTAS, jamás habrá en esa página filas de la tabla EMPLEADOS. Cuando todo el contenido de una página de datos es eliminado a esa página se la marca como “disponible” y puede ser reutilizada; si se desea eliminar a todas las páginas “disponibles” hay que hacer un ciclo backup/restore.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

Un formulario para mostrar la transacción actual

Deja un comentario

Como conocer los datos de la transacción actual puede ser muy útil cuando estamos en la etapa de crear y depurar aplicaciones hice un pequeño formulario para que muestre esos datos.

Esta es una captura de pantalla del formulario cuando está en ejecución.

FORMULARIO1

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

Como puedes ver en la Captura 1, toda la información relevante se encuentra ahí. Además, colocando el cursor del mouse sobre cualquiera de los campos se muestra un corto mensaje explicativo, digamos que es un “ayuda memoria”.

Puedes descargar el formulario desde este enlace:

http://www.mediafire.com/download/566t3p6eryburfv/MOSTRAR_TRANSACCION.ZIP

NOTA: Debes reemplazar la llamada a la función SQL_Ejecutar() por una llamada a la función SQLEXEC() porque SQL_Ejecutar() es una función mía que aumenta la potencia de SQLEXEC()

Artículos relacionados:

Una vista para verificar la transacción actual

El índice del blog Firebird21

Older Entries