Entendiendo a GSTAT (2)

Deja un comentario

Ya hemos empezado a entender a GSTAT en el artículo:

Entendiendo a GSTAT (1)

así que ahora continuaremos interiorizándonos más sobre este muy útil programa.

Opción -fetch

A veces, estamos trabajando en una computadora pero no estamos solos, hay algunos curiosos cerca nuestro que están mirando lo que estamos haciendo. Desde luego que si escribimos nuestra contraseña podrán verla … y recordarla … y usarla cuando no estemos presentes.

gstat01

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

Claro, podríamos pedirles que desaparezcan, que se vayan a otro lado, que dejen de curiosear, que se dediquen a hacer algo productivo bien lejos de nosotros, etc., pero eso no siempre es posible. Y entonces ¿qué hacemos?

La solución es guardar nuestra contraseña en un archivo de texto (que podría estar en un pen-drive, por ejemplo) y extraer la contraseña desde ese archivo de texto.

gstat02

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

Desde luego que el nombre del archivo puede ser cualquiera, no necesariamente FIREBIRD.TXT, y nuestra contraseña también puede ser cualquiera, no necesariamente contra99. Esto es solamente un ejemplo.

Recuerda que una contraseña que todos conocen es lo mismo que no tener contraseña.

gstat03

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

En la Captura 3. vemos que la contraseña se obtiene desde el archivo de texto FIREBIRD.TXT que se encuentra en el pen-drive colocado en la unidad G: y en la carpeta \SQL

De esta manera, siempre y cuando no dejemos nuestro pen-drive al alcance de los curiosos, ellos no podrán conocer cual es nuestra contraseña.

Esta, es una muy importante medida de seguridad que deberíamos acostumbrarnos a adoptar: nunca escribir la contraseña, siempre obtenerla de un archivo de texto.

gstat04

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

En la Captura 4. estamos viendo la forma correcta de usar al programa GSTAT. Nuestra contraseña la obtenemos de un archivo de texto y la salida del programa GSTAT la enviamos a otro archivo de texto. Esta es la forma mejor y más recomendable.

Artículos relacionados:

Entendiendo a GSTAT (1)

El índice del blog Firebird21

El foro del blog Firebird21

 

 

 

 

 

Anuncios

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

PHP: guardando un archivo en un campo BLOB

1 comentario

Si estás programando con PHP y usando una Base de Datos de Firebird puedes encontrarte con la necesidad de guardar un archivo en un campo BLOB, aquí está una forma de hacerlo, colaboración de Jaume.

$f = realpath("factura.pdf");

$stream = fopen($f, "r");

$dpdf = stream_get_contents($stream);

fclose($stream);

$sql = "UPDATE OR INSERT INTO MiTabla (MiColumna1, MiColumna2) VALUES (MiValor1, :foo)";

try {
   $queri = $co->prepare($sql);
   $queri->bindParam(':foo', $dpdf);
   $queri->execute();
   $queri = NULL;
}
catch (PDOException $e) {
   $ok    = false;
   $queri = NULL;
   $inf   = $e->getMessage();
}

Artículo relacionado:

El índice del blog Firebird21