Un stored procedure para conocer el tamaño total de los BLOB

2 comentarios

En una Base de Datos puedes tener muchas columnas de tipo BLOB (Binary Large OBject) y usarlas para guardar en ellas textos largos, fotografías, canciones, vídeos, etc.

Esto está muy bien y para eso se usan. Pero supongamos que ahora te interesa conocer el tamaño total en bytes que todas esas columnas de tipo BLOB ocupan en tu Base de Datos. ¿Cómo puedes tener esa información?

El siguiente stored procedure te lo dirá.

Listado 1.

CREATE PROCEDURE TAMANO_BLOBS
   RETURNS(
      ftnTamanoTotal BIGINT)
AS
   DECLARE VARIABLE lcNombreTabla   CHAR(31);
   DECLARE VARIABLE lcNombreColumna CHAR(31);
   DECLARE VARIABLE lcComando       VARCHAR(1024);
   DECLARE VARIABLE lnTamanoBlob    BIGINT;
BEGIN

   ftnTamanoTotal = 0;

   FOR SELECT
      R.RDB$RELATION_NAME,
      R.RDB$FIELD_NAME
   FROM
      RDB$RELATION_FIELDS R
   JOIN
      RDB$FIELDS F
         ON R.RDB$FIELD_SOURCE = F.RDB$FIELD_NAME
   WHERE
      F.RDB$FIELD_TYPE = 261
   INTO
      :lcNombreTabla,
      :lcNombreColumna
   DO BEGIN
      lcComando = 'SELECT 
                      SUM(OCTET_LENGTH(' || :lcNombreColumna || ')) 
                   FROM ' || 
                     :lcNombreTabla || '
                   WHERE 
                      NOT ' || :lcNombreColumna || ' IS NULL ' ;
      EXECUTE STATEMENT (:lcComando ) INTO :lnTamanoBLOB;
      ftnTamanoTotal = ftnTamanoTotal + Coalesce(lnTamanoBLOB, 0);
   END

END;

Explicación:

El FOR SELECT obtiene el nombre de todas las tablas que tienen al menos una columna cuyo tipo de campo es 261 (es decir, BLOB) y además obtiene el nombre de esa/s columna/s.

El EXECUTE STATEMENT obtiene el tamaño en bytes de cada una de esas columnas de tipo BLOB.

Luego, simplemente se acumulan esos tamaños en la variable de salida ftnTamanoTotal.

El tamaño en bytes de una sola columna de una tabla

¿Y si te interesa conocer solamente el tamaño en bytes que ocupa una columna de tipo BLOB de una tabla?

Listado 2.

SELECT
   SUM(OCTET_LENGTH(MiColumnaBLOB))
FROM
   MiTabla
WHERE
   MiColumnaBLOB IS NOT NULL

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

Máxima cantidad de columnas en una tabla

3 comentarios

Si te preguntan ¿cuántas columnas puede tener una tabla de Firebird? tu respuesta debe ser: “depende de los tipos de datos de las columnas”

¿Por qué eso?

Porque en Firebird no hay una cantidad máxima de columnas, como sí hay en Visual FoxPro, en Access y en otros lenguajes o motores de bases de datos. En los dos anteriormente nombrados el límite es de 255 columnas, pero en Firebird no existe tal cosa.

¿Por qué no?

Porque en Firebird una fila puede tener un máximo de 65.536 bytes y por lo tanto la cantidad máxima de columnas que puede tener una tabla varía entre 1 y 65.536

 Veamos esto más detalladamente:

Algunos tipos de datos ocupan una cierta cantidad predeterminada de bytes. Por ejemplo, SMALLINT ocupa siempre 2 bytes, INTEGER ocupa siempre 4 bytes, BLOB ocupa siempre 4 bytes, etc.

Pero tenemos dos casos especiales, que son CHAR y VARCHAR, la cantidad de bytes que ellos ocupan dependen del CHARACTER SET usado. Si no especificamos un CHARACTER SET o especificamos uno de los llamados “occidentales” entonces 1 carácter ocupará siempre 1 byte. Para nosotros que escribimos en castellano, portugués, francés, inglés, u otros idiomas occidentales eso es lo normal. Pero para quienes escriben en árabe, hebreo, chino, japonés, coreano, vietnamita, etc., eso ya no es cierto. Entonces, si el CHARACTER SET de la columna es por ejemplo ISO8859_1 (el recomendado para guardar texto escrito en castellano) una columna definida como CHAR(20) se cuenta como 20 bytes pero si el CHARACTER SET de la columna es UTF8 entonces una columna definida como CHAR(20) se cuenta como 40 bytes, ya que cada carácter ocupa 2 bytes cuando se usa UTF8.

¿Qué implica todo esto?

Que solamente tendremos problemas si la suma de los bytes ocupados por todas las columnas supera la cantidad de 65.536, si es igual o menos que eso estará todo bien.

Como vimos anteriormente, es muy fácil hacer esa suma.

Ejemplo 1:

Evidentemente, cada caso es distinto, depende de la estructura de la tabla para saber cuantas columnas como máximo puede tener pero supongamos lo siguiente para este ejemplo:

La cantidad de bytes que ocupa cada columna de una tabla es en promedio de 20. Por lo tanto, dividiendo 65.536 por 20 obtenemos como resultado 3.276 y para esa tabla en particular podríamos tener hasta 3.276 columnas.

Como vemos, mucho más que las 255 columnas del Visual FoxPro o del Access

De todas maneras, si necesitas una tabla que tenga tantas columnas lo más probable es que tu diseño esté muy mal y tendrías que ver la forma de mejorarlo.

Ejemplo 2:

En una tabla solamente necesitamos guardar números enteros y como cada columna de tipo INTEGER ocupa 4 bytes entonces podríamos tener un máximo de 65.536 / 4 columnas lo cual nos da como resultado 16.384 columnas.

Ejemplo 3:

En una tabla necesitamos guardar una columna de tipo SMALLINT, tres columnas de tipo INTEGER, y el resto serán columnas de tipo CHAR(60). Entonces tenemos: 65.536 – 2 – 3 * 4 = 65.522, y como 65.522 / 60 es igual a 1.092, podríamos tener hasta 1.096 columnas en esa tabla (1 columna SMALLINT, 3 columnas INTEGER, y 1.092 columnas CHAR(60)).

Conclusión:

En Firebird no hay una cantidad máxima de columnas que puede tener una fila de una tabla, lo que sí hay es una cantidad máxima de bytes que puede tener una fila de una tabla. Ese número es 65.536 bytes y es muchísimo más que suficiente para todas las necesidades que podamos tener. Si llegamos a necesitar más que 65.536 bytes entonces es seguro que nuestra Base de Datos está mal diseñada y deberíamos preocuparnos por mejorar eso.

Artículos relacionados:

Entendiendo a los conjuntos de caracteres

Algo más sobre los conjuntos de caracteres

Funciones útiles con los conjuntos de caracteres

Cantidad de columnas de una tabla

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

¿Cómo las bases de datos de Firebird aumentan de tamaño?

2 comentarios

El tamaño que ocupan en el disco duro las Bases de Datos de Firebird no es tan sencillo de conocer como a primera vista se podría uno imaginar.

Cuando creas una Base de Datos de Firebird ésta no está vacía sino que ya tiene dentro suyo muchas tablas que luego serán usadas durante las tareas que se realicen en esa Base de Datos. A esas tablas internas se las conoce como “metadatos“.

Entonces, lo primero que notarás después de crear una Base de Datos si miras su tamaño es que éste es de cientos de kilobytes. Eso es debido a los metadatos. Está ok, así tiene que ser.

Luego, tú o los usuarios empiezan a realizar operaciones de manipulación de datos (inserciones, modificaciones, borrados) y allí puedes notar algo curioso: el tamaño de la Base de Datos parece ser muy grande para la cantidad de filas que hay en las tablas.

¿Por qué?

Porque cuando el Firebird necesita que la Base de Datos tenga más espacio para las filas que estás insertando, modificando o borrando no aloja espacio solamente para esa fila en particular sino que aloja mucho más espacio.

¿Y por qué hace eso, por qué no aloja solamente el espacio en disco exactamente necesario?

Por tres motivos:

  1.  Porque la tarea de alojar más espacio lleva tiempo, no es instantánea. Si cada vez que se inserta una nueva fila tendría que estar alojando espacio en el disco duro para esa fila entonces esas inserciones demorarían demasiado tiempo en bases de datos donde hay muchas inserciones concurrentes y los usuarios se quejarían de la extrema lentitud
  2. Porque como el Firebird aloja el espacio en páginas esos continuos alojamientos fragmentarían excesivamente al disco duro
  3. Porque si el disco duro se queda sin espacio entonces hay una gran posibilidad de que la Base de Datos aún tenga suficiente espacio libre previamente alojado para que pueda terminar todas las operaciones que se estaban realizando en ella, sin corrupción.

Entonces, alojar más espacio del necesario, para tener bastante espacio libre disponible tiene tres grandes ventajas: a) se consigue una gran rapidez en todas las operaciones de inserción, modificación, borrado, porque el espacio ya está disponible, b) no se fragmenta excesivamente el disco duro y c) si el disco duro se queda sin espacio libre es muy probable que la Base de Datos no se corrompa porque los datos que faltaban grabarse se grabarán en el espacio previamente alojado.

Claro que esto también tiene sus desventajas. Estas son: a) cada vez que hay que alojar más espacio ocurre una demora, y b) la Base de Datos puede estar ocupando en el disco duro mucho espacio y si la cantidad libre en el disco duro es escasa eso afectará a los otros programas.

Claro que la desventaja b) es muy improbable que ocurra en esta época en que los discos duros son gigantescos y muy baratos, además si se cuenta con un Administrador que verifique el espacio libre en el disco duro nunca debería ocurrir algo así.

Un gráfico que ilustra el concepto

En este gráfico podemos ver como se aloja el espacio en una Base de Datos de Firebird.

ESTRUCTURA1

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

El espacio en C) está libre, nada hay ahí pero ya está asignado a la Base de Datos y para el Sistema Operativo es espacio ocupado por la Base de Datos y por ese motivo no puede ser usado por otros archivos. Cuando los usuarios insertan, modifican, o borran filas, esas inserciones, modificaciones, o borrados ocurren en C) y cuando el espacio en C) ya es pequeño se aloja más espacio a la Base de Datos, para que siempre tenga espacio libre a su disposición. Pero siempre esos alojamientos sirven para alojar a cientos o a miles de filas, no son para alojar a una o a dos filas sino a cientos o a miles de ellas. O sea que cada vez que se aloja un nuevo C) hay suficiente espacio en él para cientos o miles de filas.

¿Y cuántos bytes se alojan cada vez que la Base de Datos requiere de más espacio?

Cuando el Servidor descubre que la Base de Datos ya casi no tiene espacio libre debe reservar más espacio para ella. En el gráfico anterior la parte B) va creciendo hacia arriba haciendo que la parte C) sea cada vez más pequeña. Es entonces que el Servidor le aloja más espacio, según esta fórmula:

Al tamaño actual de la Base de Datos lo divide por 16

Nunca aloja más espacio que el establecido en la entrada DatabaseGrowthIncrement del archivo FIREBIRD.CONF (que por defecto es 128 Mb) ni menos de 128 Kb

Ejemplos:

Si la Base de Datos tiene 16 Mb entonces aloja 1 Mb (o sea, el tamaño de la Base de Datos dividido 16)

Si la Base de Datos tiene 16 Gb entonces aloja 128 Mb. No aloja 1 Gb sino que aloja 128 Mb. ¿Por qué? porque ese es el valor de la entrada DatabaseGrowthIncrement (que indica cual es el incremento máximo), salvo que haya sido cambiada. Recuerda: Nunca aloja más que el incremento máximo.

Si la Base de Datos tiene 16 Gb y la entrada DatabaseGrowthIncrement tiene el valor 268435456 (que equivale a 256 Mb) entonces aloja 256 Mb.

¿Es conveniente aumentar o disminuir el valor de la entrada DatabaseGrowthIncrement?

En general, el valor por defecto de 128 Mb es bastante bueno para la gran mayoría de las situaciones y podríamos dejarlo así, pero en bases de datos que tienen muchísimo movimiento y crecen mucho y rápido puede ser conveniente aumentarlo, para que el Firebird no esté a cada rato alojando nuevo espacio. Disminuirlo no se justifica (salvo que el disco duro tenga poquísimo espacio libre) porque disminuir significa aumentar la fragmentación del disco duro algo que nunca es conveniente porque un disco duro fragmentado tarda más en ser leído.

El valor de la entrada DatabaseGrowthIncrement se expresa en bytes, no en megabytes. Por lo tanto en ella por defecto veremos el número 134217728 que equivale a 128 Mb.

Conclusión:

Para que las operaciones de mantenimiento de tablas (inserción, modificación, borrado) sean muy rápidas el Firebird les asigna a las bases de datos más espacio en el disco duro que el estrictamente necesario. Eso además tiene la ventaja de que es muy improbable de que ocurra corrupción porque si el disco duro se queda sin espacio libre es muy posible que la Base de Datos no, que aún tenga suficiente espacio libre previamente alojado para terminar exitosamente todas las operaciones que estaban realizando los usuarios.

 Para saber cuantos bytes debe alojar cada vez que lo hace, el Firebird divide por 16 al tamaño actual de la Base de Datos. El tamaño mínimo que aloja es 128 Kb y el tamaño máximo que aloja lo determina la entrada DatabaseGrowthIncrement del archivo FIREBIRD.CONF que por defecto es de 128 Mb pero que puede ser cambiado. Si se cambia entonces lo aconsejable es aumentarlo porque disminuirlo aumentará la fragmentación del disco duro, algo que nunca es bueno.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

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

4 comentarios

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

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

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

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

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

Entonces, nuestra tarea de mantenimiento tiene 2 partes:

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

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

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

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

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

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

Artículos relacionados:

La arquitectura MGA

Entendiendo sweep y garbage collection

El índice del blog Firebird21

El foro del blog Firebird21

 

Averiguando el tamaño en bytes de una tabla

Deja un comentario

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

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

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

Ejemplo:

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

TAMANO1

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

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

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

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

Artículo relacionado:

El índice del blog Firebird21

 

Averiguando el tamaño de la Base de Datos

Deja un comentario

Si necesitas conocer el tamaño de tu Base de Datos en bytes, puedes escribir la siguiente consulta:

SELECT
   MON$PAGES * MON$PAGE_SIZE AS TAMANO_EN_BYTES
FROM
   MON$DATABASE

Lo que hace esa consulta es multiplicar la cantidad total de páginas que tiene la Base de Datos por el tamaño de cada página, hallando así el tamaño de la Base de Datos.

Artículo relacionado:

El índice del blog Firebird21