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

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