Entendiendo a GSTAT (4)

Deja un comentario

Entender como funciona el programa GSTAT es bastante largo. Ya hemos visto algo sobre él en estos artículos:

Entendiendo a GSTAT (1)

Entendiendo a GSTAT (2)

Entendiendo a GSTAT (3)

ahora, continuamos.

Opción -index

Esta es la opción que debemos elegir cuando solamente nos interesan los índices de nuestras tablas.

gstat01

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

Como es lo usual, la contraseña la extraemos de un archivo de texto y la salida del programa GSTAT la enviamos a otro archivo de texto. Esto último es para facilitarnos la tarea.

gstat02

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

En la Captura 2. vemos una parte del contenido del archivo de texto que nos muestra información sobre nuestros índices. Los nombres de los índices siempre aparecen ordenados alfabéticamente.

¿Cuál es el significado de lo que estamos viendo?

ASIENTOSCAB es el nombre de la tabla

131 es el identificador que la tabla ASIENTOSCAB tiene dentro de la tabla del sistema RDB$RELATIONS. Es en RDB$RELATIONS donde se  guardan los nombres de todas las tablas de la Base de Datos.

ASC01, ASC02, ASC03, y PK_ASIENTOSCAB son los nombres de los índices

0, 1, 2, 3, los números entre paréntesis que vemos después de los nombres de los índices son los identificadores de los índices menos 1 y nos indican el orden en el cual fueron creados, siendo 0 el primer índice que creamos, 1 el segundo índice que creamos, 2 el tercer índice que creamos y así sucesivamente. Si se creó un índice y luego se lo eliminó, el número que tenía no aparecerá en la lista.

Listado 1.

SELECT
   RDB$INDEX_ID,
   RDB$RELATION_NAME,
   RDB$INDEX_NAME
FROM
   RDB$INDICES
WHERE
   RDB$RELATION_NAME = 'ASIENTOSCAB'
ORDER BY
   RDB$INDEX_ID

gstat03

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

¿Por qué en la Captura 2. no muestra los verdaderos identificadores sino los identificadores menos 1? Es un verdadero misterio, quizás haya alguna razón valedera para ello pero es dudoso que exista. Probablemente sólo sea por costumbre.

Depth es la cantidad de indirecciones o desviaciones que hay en el árbol B-tree del índice. Lo ideal es que ese número sea como máximo 3. Si es mayor que 3 entonces el índice no será tan eficiente como podría ser ¿cómo lo solucionamos? aumentando el tamaño de la página de nuestra Base de Datos. Si por ejemplo el tamaño de la página es 4096 lo aumentamos a 8192 y volvemos a ejecutar a GSTAT con la opción -index para comprobar si Depth ahora es 1, 2, ó 3 (esos son los mejores valores que puede tener Depth). Si sigue siendo mayor que 3 entonces volvemos a aumentar el tamaño de la página de nuestra Base de Datos y ahora lo ponemos en 16384.

Leaf buckets es la cantidad de páginas que están en el nivel más bajo del árbol B-tree. Es en estas páginas donde se guardan los punteros a las filas de la tabla. En las demás páginas de índice se guardan los enlaces a otras páginas de índice.

Nodes es la cantidad total de filas en la tabla que han sido indexadas. Sin embargo, este número puede ser erróneo porque podrían aparecer filas que han sido borradas con DELETE y aún su basura no ha sido recolectada o también porque las columnas del índice cambiaron de valor. Por eso, es conveniente ejecutar a GSTAT con la opción -index solamente después de un sweep o de un ciclo backup/restore.

Average data length es el tamaño en bytes promedio de los datos de la columna (o columnas) que se indexaron. Como Firebird comprime esos datos antes de grabarlos en una página de índices, el average data length será siempre menor a la suma del tamaño de las columnas de la tabla.

Total dup es la cantidad total de duplicados que tiene un índice. Los índices que se utilizan en las restricciones Primary Key y Unique Key no admiten duplicados, pero los otros índices sí los admiten. Cuantos más duplicados haya, peor es el índice.

 Listado 2.

SELECT
   ASC_ANOEJE,
   ASC_CODSUC,
   ASC_NUMERO,
   COUNT(*)
FROM
   ASIENTOSCAB
GROUP BY
   ASC_ANOEJE,
   ASC_CODSUC,
   ASC_NUMERO

gstat05

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

gstat04

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

En la Captura 4. vemos que al ejecutar el Listado 2. se usó el índice ASC01, y en la Captura 5. vemos la cantidad de veces que los valores de ese índice aparecieron. En este caso no hay duplicados, ya que COUNT siempre nos muestra el número 1 pero en otros índices sí podría haber duplicados. El Listado 2. nos ayudará a conocer cuantos duplicados tiene nuestro índice. Recuerda que Total dup puede mostrarte una cantidad incorrecta de duplicados si no has hecho previamente un ciclo backup/restore.

Max dup es la cantidad máxima de valores duplicados que tiene un índice.

Fill distribution es una tabla de frecuencias y seguramente te recordarás de ellas si alguna vez estudiaste Estadísticas. Hay 5 filas, yendo de 20% en 20%, cada fila indicando la cantidad de páginas de índices que están completadas hasta ese porcentaje.

gstat02

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

En la Captura 6. vemos que hay 8 páginas de índices que están llenas entre un 20% y un 39%. Y hay 3 páginas de índices que están llenas entre un 40% y un 59%. La suma de 8 + 3 es 11, y siempre debe coincidir con leaf buckets.

Esta distribución es mala, estamos usando más páginas que las necesarias. ¿Cómo sabemos eso? porque no hay páginas rellenas entre un 80% y un 99%. En una buena distribución el número mayor debería estar siempre en la última fila, (es decir, en 80% a 99%). ¿Cómo conseguimos eso? Con un ciclo backup/restore y luego usando el backup restaurado.

Artículos relacionados:

Entendiendo a GSTAT (1)

Entendiendo a GSTAT (2)

Entendiendo a GSTAT (3)

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Almacenamiento de las columnas de tipo BLOB

Deja un comentario

En Firebird tenemos la posibilidad de almacenar (guardar) archivos dentro de las bases de datos. Podemos usar esta característica para guardar documentos de texto, hojas de cálculo, gráficos, fotografías, canciones, vídeos, etc.

Para ello, declaramos a la columna como de tipo BLOB (Binary Large OBjets), o sea: “objetos binarios de gran tamaño”.

¿Dónde se guardan esos objetos binarios de gran tamaño?

Si declaramos a una columna como siendo de tipo CHAR, VARCHAR, SMALLINT, INTEGER, etc., es en esa misma columna donde se guardan sus valores. Pero con las columnas de tipo BLOB no sucede así. En este caso en la columna se guarda un puntero (un número que indica una dirección) a la ubicación física del archivo BLOB.

(Algo similar ocurre en los xBase: dBase, Visual FoxPro, etc., allí se les llama “campos memo” y se guardan en archivos distintos a las tablas .DBF)

Firebird hace lo siguiente:

  • Si el archivo BLOB cabe en la misma página que su fila (registro), se guarda en esa página. Recuerda que los tamaños de página pueden ser de 4.096, 8.192, 16.384 bytes. Como en general los archivos BLOB tienen un tamaño mayor a 16.384 bytes entonces es muy raro que sean guardados en la misma página que su fila respectiva.
  • Si el archivo BLOB no cabe en la misma página que su fila (registro) entonces se guarda en otra o en otras páginas. Estas páginas son del tipo “overflow”. Recordarás que todo en Firebird se guarda dentro de páginas. Los archivos BLOB no son la excepción. Esas “páginas de overflow” siempre están relacionadas con una tabla y por lo tanto son localizadas a través de las filas (registros) de esa tabla. El Firebird sabe a cual tabla pertenece cada “página de overflow” porque en la cabecera de la “página de overflow” coloca ese dato, así también como la fila (registro) que le corresponde y la secuencia en que se encuentra (si un archivo BLOB ocupa varias páginas el Firebird debe poder saber cual es la primera página, cual la segunda, cual la tercera, etc.)

Conclusión:

Las columnas de tipo BLOB normalmente se utilizan para guardar archivos dentro de ellas. Esos archivos como todo en Firebird se guardan dentro de páginas de la Base de Datos. Si el archivo BLOB es pequeño entonces podría guardarse en la misma página que su fila respectiva, pero lo normal es que el archivo BLOB sea más grande que el tamaño de una página y en ese caso se guarda en páginas llamadas de “overflow”. En la cabecera de las páginas de overflow se encuentran los datos que permiten saber a cual  tabla pertenecen, a cual fila de esa tabla, y la posición de esa página con relación a las demás páginas de ese archivo BLOB.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

Precauciones al usar Firebird Embedded

4 comentarios

Como seguramente ya sabes, puedes usar Firebird con 4 arquitecturas diferentes:

  • Classic
  • SuperClassic
  • SuperServer
  • Embedded

Las tres primeras normalmente tienen al Servidor en una computadora y al Cliente en cada una de las computadoras que necesitan acceder a la/s base/s de dato/s. Una de esas tres primeras arquitecturas debemos usar cuando queremos que varios usuarios estén conectados al mismo tiempo a la misma Base de Datos, este es el caso más frecuente cuando usamos Firebird. Colocamos a las bases de datos en una carpeta no compartida que se encuentra en la misma computadora donde se encuentra el Servidor y éste es quien se encarga de acceder a esas bases de datos cuando los Clientes se lo soliciten. Eso está muy bien y funciona perfectamente.

La arquitectura Embedded en cambio la usaríamos cuando siempre será una sola persona quien se conectará a la Base de Datos, como sería en el caso de una aplicación monousuario.

¿Y qué ocurrirá si ponemos a la Base de Datos en una carpeta compartida y permitimos que accedan a ella desde varias computadoras de la red usando Embedded?

Que ocurrirá una catástrofe y se destrozará y volverá inservible a la Base de Datos.

¿Por qué eso?

 Porque Embedded puede manejar varias conexiones, pero con la condición de que todas esas conexiones correspondan a un mismo proceso. Siendo así, él administrará los cambios a las páginas correctamente, evitando que una conexión sobre-escriba los cambios hechos por otra conexión.

Sin embargo, si desde varias computadoras se está accediendo mediante Embedded a una Base de Datos que se encuentra en una carpeta compartida se terminará con esa Base de Datos destruida.

 Eso es debido a que cada Embedded cree que tiene acceso exclusivo a la Base de Datos y realiza en ella los cambios que necesita, pero otros Embedded pueden estar realizando otros cambios en las mismas páginas.

Ejemplo:

Un proceso Embedded necesita una nueva página para guardar en ella los datos de la tabla PRODUCTOS, esa nueva página tiene el número 5.000

Otro proceso Embedded necesita una nueva página para guardar en ella los índices de la tabla VENTAS, esa nueva página también tiene el número 5.000

No olvides que cada proceso cree que tiene acceso exclusivo a la Base de Datos y por lo tanto desconoce lo que otros procesos le están haciendo a esa Base de Datos. Un Embedded no tiene forma de saber que otro Embedded está accediendo a la misma Base de Datos.

En algún momento el problema se vuelve catastrófico, cuando una página TIP se convierte en una página de cualquier otra cosa y se perdió el acceso a todos los datos.

Desastre total.

Conclusión:

Si más de un usuario accederá a una Base de Datos de Firebird al mismo tiempo, entonces debemos usar una arquitectura Classic, SuperClassic, o SuperServer para ello.

Podemos usar Embedded cuando estamos 100% seguros de que solamente un usuario se conectará y jamás, por ningún motivo, se conectará más de un usuario.

Si ponemos a una Base de Datos en una carpeta compartida de la red y permitimos que accedan a ella usando Embedded es seguro que en algún momento esa Base de Datos se volverá totalmente inservible.

Artículos relacionados:

Entendiendo a las páginas de la Base de Datos

El índice del blog Firebird21

El foro del blog Firebird21

 

 

Eligiendo el tamaño adecuado de las páginas de la Base de Datos

Deja un comentario

En este artículo ya hemos visto lo que son las páginas de la Base de Datos:

Entendiendo las páginas de la Base de Datos

y sabemos que esas páginas pueden tener 3 tamaños posibles:

  • 4096 bytes
  • 8192 bytes
  • 16384 bytes

¿hay alguna diferencia en el rendimiento si la Base de Datos tiene alguno de esos tamaños de página?

Sí, si tiene el tamaño adecuado entonces todas las operaciones serán más rápidas (a veces, bastante más rápidas) que si tiene un tamaño inadecuado. Las operaciones que realiza el Firebird (INSERT, UPDATE, DELETE, SELECT, FETCH) siempre afectan a una o más páginas de la Base de Datos, por lo tanto utilizar el tamaño de página adecuado es importante

entonces la pregunta ahora es ¿cuál de esos tres tamaños es el más adecuado para mi Base de Datos?

 Pues bien, la respuesta más simple es “prueba y error”. O sea, pruebas con un tamaño, luego pruebas con otro, y luego pruebas con el tercero. Comparas los desempeños y eliges el que te pareció mejor.

Desde luego que “prueba y error” es una posibilidad. Como hay solamente 3 tamaños distintos entonces es factible de realizar. Sin embargo, podemos mejorar un poco nuestro análisis para determinar el tamaño más conveniente.

  1. Tamaño de la Base de Datos. Si alguna tabla tiene o tendrá más de 100.000.000 de filas entonces elige un tamaño de página de 16384 bytes porque en tablas tan grandes los índices también serán gigantescos y por lo tanto tendrán mucha profundidad (el Firebird usa índices B-Tree, y en tales índices una profundidad mayor que 3 empieza a ser problemática).
  2. El tamaño del caché que usa la Base de Datos. Las bases de datos de Firebird tienen una memoria caché, es decir usan una porción de la memoria RAM para realizar sus procesos. Un error frecuente de los principiantes es pensar “cuanto más grande el caché, mejor”. Bien, eso no es tan así. Si fuera tan sencillo entonces el Firebird por su propia cuenta se asignaría el caché más grande posible. En un Sistema Operativo de 32 bits la mayor cantidad de memoria que puede ser direccionada es de 4 Gb (o sea, 2 elevado a la 32), pero el Windows limita esa cantidad, para que un solo proceso no esté usando toda la memoria. Por defecto, un proceso puede usar como máximo 2 Gb aunque en el archivo CONFIG.INI puede cambiarse hasta 3 Gb. Si usamos SuperServer y en el archivo FIREBIRD.CONF ponemos en la entrada DefaultDbCachePages el número 100000 y el tamaño de nuestras páginas es de 16384 bytes entonces el caché de cada Base de Datos consumirá 1.6 Gb. Lo cual implica que podremos tener abierta una sola Base de Datos, porque 1.6 Gb por 2 es 3.2 Gb, que sobrepasa el máximo de 3 Gb que el Sistema Operativo nos permite direccionar. Pero lo peor es que un caché tan gigantesco tampoco nos asegura que nuestras operaciones serán rapidísimas ¿por qué? porque el propio Sistema Operativo usa su propio caché en operaciones repetitivas de lectura en disco y por lo tanto no se usará el caché del Firebird, ocupará mucha memoria pero no se lo usará ¿Y entonces? bueno, en general un tamaño de página de 16384 bytes y un tamaño de caché moderado (o sea, alrededor de 20000) es lo más adecuado.
  3. Cantidad de filas por página. A mayor tamaño de la página, mayor cantidad de filas se pueden guardar en ella y por lo tanto la Base de Datos necesita de menos páginas. Lo normal es que si una Base de Datos tiene pocas páginas sea menos propensa a corromperse que si tiene muchas páginas. En consecuencia, un tamaño de página de 16384 bytes es preferible porque será más difícil que la Base de Datos se corrompa.
  4. Tamaño del clúster. Cuando se formatea un disco duro se debe elegir el tamaño del clúster, el cual en NTFS es de 512 bytes por defecto pero puede ser cambiado.

Si el tamaño de la página es mayor que el del clúster entonces cuando se quiere leer una página se debe leer más de un clúster desde el disco duro y eso es lento. Por ejemplo:

Tamaño de la página = 4096 bytes

Tamaño del clúster = 512 bytes

implica que leer una sola página de la Base de Datos requiere leer 8 clústers en el disco duro (ya que 512 * 8 = 4096). Lo mismo cuando se quiere escribir en una página, se requerirá escribir en 8 clústers. Y si los clústers no están contiguos eso hará aún más lenta a la operación (nosotros no podemos saber si estarán contínuos o no, porque eso es de incumbencia del Sistema Operativo).

 Si el tamaño de la página es menor que el tamaño del clúster a veces puede ser beneficioso cuando se lee, sin embargo cuando se escribe se tardará más. Por ejemplo:

Tamaño de la página = 4096 bytes

Tamaño del clúster = 8192 bytes

Como el Sistema Operativo no puede leer menos que un clúster, un clúster es lo mínimo que puede leer desde el disco duro, cada vez que lea un clúster estará trayendo 2 páginas. Eso puede ser bueno si necesitaremos luego los datos que están en la segunda página pero si no es así entonces se leyeron 4096 bytes inútiles ¿por qué? porque los primeros 4096 bytes sí los usamos, esos fueron los que pedimos, pero los siguientes 4096 nunca los usamos y por lo tanto fueron leídos inutilmente. A su vez, cuando necesitemos escribir lo haremos por duplicado porque cuando escribamos en la primera página escribiremos en el clúster y cuando escribamos la segunda página también escribiremos en el clúster.

¿Lo mejor?

Que el tamaño de la página y el tamaño del clúster sean iguales.

El tamaño adecuado puede cambiar con el tiempo

Un punto muy, pero muy importante a tener en cuenta es el siguiente: el mejor tamaño de página hoy puede no ser el mejor dentro de un mes o dentro de un año.

¿Por qué?

Porque las bases de datos son dinámicas, no son estáticas, constantemente se les están insertando, actualizando, y borrando filas. Un tamaño de página excelente cuando la Base de Datos tenía una tamaño de 50 Mb puede ser horrible cuando creció hasta tener un tamaño de 2 Gb.

Así que debemos recordar que a veces cambiar el tamaño de las páginas puede ser una muy buena alternativa para que todas las operaciones se realicen más rápidamente.

Conclusión:

Si nuestra Base de Datos tiene un tamaño de página adecuado entonces todas las operaciones que se realicen en ella (INSERT, UPDATE, DELETE, SELECT, FETCH) serán rápidas. Pero si no es así, entonces esas operaciones serán más lentas de lo que deberían.

Como hay solamente 3 tamaños de página posibles entonces es muy fácil realizar tests de “prueba y error”. Sin embargo, también podemos tener en cuenta algunos parámetros para hallar el tamaño de página más adecuado y arriba se detallan esos parámetros.

Algo importante a tener en cuenta es que el tamaño del clúster del disco duro debe ser igual al tamaño de la página de la Base de Datos, para conseguir el máximo rendimiento posible.

Artículos relacionados:

Entendiendo las páginas de la Base de Datos

El índice del blog Firebird21

El foro del blog Firebird21

Paginando un SELECT

2 comentarios

En ocasiones el conjunto resultado de un SELECT se utiliza para imprimir informes. Por ejemplo, un informe de ventas, o un informe de cobranzas, los cuales el usuario quiere tener impresos en papel.

También puede ocurrir que al usuario le interese imprimir solamente alguna página en especial. Por ejemplo, cayó café sobre la página número cinco, se hizo un desastre, y por eso el usuario quiere volver a imprimir solamente la página cinco; las demás no, porque las demás no se mancharon con café.

Si sabemos cuantas filas del conjunto resultado se imprimen en cada página entonces es muy fácil obtener las filas que nos interesan.

Ejemplo 1:

  • En cada página se imprimen 40 filas
  • Queremos re-imprimir la página número 5
SELECT
   MiColumna1,
   MiColumna2
FROM
   MiTabla
ROWS
   (5 - 1) * 40 + 1 TO 5 * 40

En este ejemplo se obtendrán las filas 161 a 200, o sea todas las filas que corresponden a la página número 5, ya que cada página tiene 40 filas.

Ejemplo 2:

  • En cada página se imprimen 40 filas
  • Queremos re-imprimir las páginas números 5 y 6
SELECT
   MiColumna1,
   MiColumna2
FROM
   MiTabla
ROWS
   (5 - 1) * 40 + 1 TO (5 + 1) * 40

En este ejemplo se obtendrán las filas 161 a 240, o sea todas las filas que corresponden a la página número 5 ó a la página número 6.

Forma general

La forma general, para usarla con cualquier números de página, cualquier cantidad de páginas y con cualquier cantidad de filas, es:

SELECT
   MiColumna1,
   MiColumna2
FROM
   MiTabla
ROWS
   (nPaginaNro - 1) * nCantidadFilas + 1 TO (nPaginaNro + (nCantidadPaginas - 1)) * nCantidadFilas

En esta fórmula hay que reemplazar a nPaginaNro por el número de la primera página que queremos imprimir (en nuestro ejemplo sería 5). Hay que reemplazar a nCantidadFilas por la cantidad de filas que tiene cada página (en nuestro ejemplo sería 40). Hay que reemplazar a nCantidadPaginas por la cantidad de páginas que queremos imprimir (en nuestro último ejemplo sería 2).

Artículo relacionado:

El índice del blog Firebird21

 

Backup y restore a una versión más nueva del Firebird

3 comentarios

A veces puedes necesitar que una Base de Datos creada con una versión anterior del Firebird sea usada con una versión más reciente.

Si no necesitas las características adicionales que introdujo la versión más reciente entonces te puedes conectar a esa Base de Datos sin problema.

Sin embargo, a veces necesitas de las características adicionales y en ese caso debes efectuar un ciclo backup/restore

Ejemplo:

MiBaseDatos.fdb fue creada con la versión 1.5 y ahora queremos usarla con la versión 2.5

Caso 1. No necesitamos de las nuevas características introducidas por la versión 2.5

Nos conectamos a la Base de Datos desde la versión 2.5 y podremos usarla sin problemas

Caso 2. Necesitamos algunas de las características introducidas por la versión 2.5 (que es el caso más común)

Aquí, debemos hacer un ciclo backup/restore para agregarle a la Base de Datos toda la funcionalidad de la versión 2.5

Primero, usando el Servidor del Firebird 1.5, en la ventana “Símbolo del sistema” del Windows escribimos:

SET ISC_USER=SYSDBA

SET ISC_PASSWORD=masterkey

GFIX -validate -full MiBaseDatos.fdb

GFIX -mend -full -ignore MiBaseDatos.fdb

GFIX -sweep MiBaseDatos.fdb

GBAK -backup -verbose -ignore -garbage MiBaseDatos.fdb MiBackup.fbk

Los dos SET (ISC_USER e ISC_PASSWORD) sirven para decirle al Windows que queremos usar esas variables y en consecuencia en los comandos GFIX y GBAK no necesitaremos estar introduciendo el usuario ni la contraseña. Es opcional, si prefieres escribir el usuario y la contraseña en cada comando GFIX y GBAK, entonces puedes obviar los dos SET

Si no usas un alias entonces debes escribir la ruta completa a tu Base de Datos, por ejemplo: D:\DATABASES\MiBaseDatos.fdb

Si usas un alias, entonces puedes escribir solamente el alias, por ejemplo: CONTA

El nombre del archivo de backup debe ser escrito con la ruta completa, por ejemplo: D:\BACKUPS\MiBackup.fbk

La opción -validate busca errores en la Base de Datos, los muestra y los repara

La opción -full se usa con la opción -validate para examinar todas las páginas y todos los registros y para liberar fragmentos de registro que no están asignados

La opción -mend marca a los registros corruptos para que al hacer el backup no sean copiados. De esta manera solamente los registros que están en buen estado son enviados al archivo de backup

La opción -ignore ignora los errores de checksum

La opción -sweep realiza el sweep inmediatamente

La opción -backup es opcional, sirve para aclarar (a nosotros, los humanos) que se quiere hacer un backup y no un restore

La opción -verbose muestra lo que está haciendo el programa GBAK

La opción -garbage no realiza la recolección de basura durante el backup y por lo tanto el backup terminará más rápido. Se la usa cuando tienes planeado hacer el restore o el sweep después del backup

 Ahora que nos aseguramos que nuestra Base de Datos está en buen estado y que hemos creado el archivo de backup pasamos al siguiente paso: restaurar el archivo de backup en una versión más reciente del Firebird

Para eso, usando la versión más reciente, escribimos:

GBAK -create -verbose -page_size 16384 MiBackp.fbk MiBaseDatos.fdb

La opción -create creará el archivo MiBaseDatos.fdb y éste no debe existir.

La opción -verbose muestra lo que está haciendo el programa GBAK

La opción -page_size cambia el tamaño de la página. Debes tener en cuenta que si aumentas el tamaño de la página (por ejemplo: la Base de Datos original tenía un tamaño de página de 4096 y se la restaura con un tamaño de página de 16384) aumentará también el tamaño de tu Base de Datos restaurada.

Al finalizar la restauración ya tendremos una nueva Base de Datos, completamente funcional y con todas las características de la versión más reciente del Firebird.

Artículo relacionado:

El índice del blog Firebird21