Fechas aleatorias

Deja un comentario

A veces cuando estamos realizando pruebas necesitamos datos aleatorios, o sea datos que pueden ser cualesquiera, no podemos anticipar cuales serán.

Supongamos que necesitamos fechas aleatorias. Para ello, como de costumbre usaremos la función RAND(). Esta función nos devolverá un número entre 0 y 0,999999. También usaremos la función FLOOR() que nos devuelve la parte entera de un número. También usaremos la función DATEADD() que le suma un número a una fecha para devolvernos una nueva fecha, la fecha original más la cantidad de días que le hemos sumado.

Veamos algunos ejemplos:

Listado 1. Fechas entre el 1 de enero de 2017 y el 31 de marzo de 2017

SELECT
   DATEADD(FLOOR(90 * RAND()) DAY TO DATE '2017-JAN-01')
FROM
   RDB$DATABASE

Explicación:

La cantidad de días posibles es 90, así que multiplicamos a RAND() por 90. La cantidad de días debe ser un número entero, así que usamos la función FLOOR(), porque la función RAND() nos devuelve un número con decimales. Lo que estamos sumando son días así que usamos DAY, la fecha la expresamos como un string así que debemos convertirla a tipo fecha con DATE.

En síntesis, lo que estamos diciendo es: muéstrame una fecha aleatoria entre el 1 de enero de 2017 y el 31 de marzo de 2017

Listado 2. Fechas entre el 1 de enero de 2017 y el 31 de diciembre de 2017

SELECT
   DATEADD(FLOOR(365 * RAND()) DAY TO DATE '2017-JAN-01')
FROM
   RDB$DATABASE

Explicación:

Como la cantidad de días posibles es 365, entonces multiplicamos a 365 por RAND()

Listado 3. Fechas entre el 1 de abril de 2017 y el 30 de abril de 2017

SELECT
   DATEADD(FLOOR(30 * RAND()) DAY TO DATE '2017-APR-01')
FROM
   RDB$DATABASE

Explicación:

Como la cantidad de días posibles es 30, entonces multiplicamos 30 por RAND(). Como la fecha inicial es el 1 de abril de 2017, entonces escribimos esa fecha después de DATE.

Artículos relacionados:

La función DATEADD()

La función FLOOR()

La función RAND()

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Liberada la versión 3.0.2 de Firebird

3 comentarios

El día 22 de marzo de 2017 fue liberada la versión 3.0.2 de Firebird, la cual ha corregido muchos “bugs” que se encontraron desde la liberación de la versión 3.0.0 y además tiene algunas mejoras en cuanto a rendimiento. Por lo tanto, si ya estás usando Firebird 3 es altamente  recomendable que descargues e instales esta nueva versión.

Puedes descargarla desde:

https://www.firebirdsql.org/en/firebird-3-0-2/

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

Liberada la versión 2.5.7 de Firebird

5 comentarios

El 15 de Febrero de 2017 se liberó la versión 2.5.7 de Firebird, la cual tiene las siguientes mejoras:

  1. Se corrigió una vulnerabilidad que ocurría cuando se realizaban conexiones autenticadas. Como las conexiones autenticadas no son muy usadas por los administradores de bases de datos de Firebird el riesgo en general no era muy grande, pero igualmente es muy conveniente actualizarse a la versión 2.5.7
  2. Ahora se pueden filtrar la información y los avisos de advertencia del trace log
  3. Se agregó soporte para “TCP Loopback Fast Path”, el cual fue introducido en Windows 8 y en Server 2012, lo cual mejorará las velocidades en redes locales que usen esos sistemas operativos o versiones posteriores.

Puede ser descargado desde:

https://www.firebirdsql.org/en/firebird-2-5/

Artículos recomendados:

El índice del blog Firebird21

El foro del blog Firebird21

Ventajas y desventajas de usar servidores virtuales con Firebird

2 comentarios

Desde más o menos el año 2007 es cada vez más frecuente que las empresas e incluso los usuarios individuales cuenten con servidores virtuales. Entonces la pregunta es ¿qué tan bueno es usarlos con Firebird?

Antes de responder a esa pregunta debemos empezar por el principio y definir lo que es un servidor virtual.

Servidor virtual

Un Servidor virtual es simplemente una partición de los recursos de una computadora. Cada computadora física cuenta con memoria RAM, uno o más discos duros, uno o más núcleos, etc.

Si necesitamos una computadora que por algún motivo deba tener instalado a Windows XP y otra computadora que deba tener instalado a Windows 7, podemos ahorrar dinero, electricidad, espacio físico, etc. si instalamos ambos sistemas operativos en una sola computadora física pero particionada para que a todos los efectos parezca que se trata de 2 computadoras. Inclusive las direcciones IP serán distintas, por lo que para el mundo exterior se tratará de 2 computadoras distintas, aunque en realidad como sabemos se trata de una sola computadora.

Cada Servidor virtual tendrá acceso a una cierta cantidad de memoria RAM que se determina en el momento de la instalación. Por ejemplo, si la computadora real tiene 16 Gb de memoria RAM a la partición donde instalamos el Windows XP podríamos asignarle 4 Gb de RAM y a la partición donde instalamos el Windows 7 podríamos asignarle 12 Gb de RAM.

Desde luego que si tenemos recursos suficientes podemos tener más particiones: 3, 4, 5, 20, las que sean necesarias.

Además, los sistemas operativos que instalemos en ellas pueden ser cualesquiera que soporte el hardware. Así, podríamos tener en una partición Windows XP, en otra partición Windows 7, en otra partición Windows 10, y en otra partición Linux Ubuntu Server.

Ventajas de usar un Servidor virtual

  • Se ahorra dinero al comprar. Porque es más barato comprar una sola computadora con muchos recursos que varias computadoras con menos recursos. O sea, siempre saldrá más barato comprar una sola computadora con 16 Gb de RAM que comprar 4 computadoras con 4 Gb de RAM cada una.
  • Se ahorra electricidad. El consumo eléctrico será menor si es una sola computadora la que usa electricidad que si son varias las computadoras.
  • Se ahorra espacio físico. Porque el espacio que ocupa una sola computadora siempre será menor que el espacio que ocupan 2, 3, 5, 10, o más computadoras.
  • Se aprovecha mejor el hardware. Porque si se tienen varias computadoras físicas en algunas de ellas los recursos podrían estar mal utilizados, desperdiciándose recursos.
  • Se pueden tener programas distintos en cada Servidor virtual. No solamente el Sistema Operativo puede ser distinto, también los programas que instalemos pueden ser distintos, o distintas versiones del mismo programa.
  • Se puede verificar el rendimiento de los programas. Esto es útil para los programadores que quieren comprobar si el programa que están desarrollando funciona bien en distintos sistemas operativos o con distintas cantidades de memoria RAM, etc.
  • Cada partición es independiente de las demás particiones. Eso implica que si algún problema ocurrió en una partición las demás particiones no se verán afectadas. Por ejemplo, si por algún problema un Servidor virtual se “colgó”, los demás servidores virtuales ni se enterarán.
  • Instalar un servidor virtual es gratis o muy barato. Hay programas gratis muy buenos por lo cual no es obligatorio gastar dinero.

Desventajas de usar un Servidor virtual

  • El software de seguridad no se ejecuta bien. Los antivirus, firewalls, etc., a veces tienen problemas cuando son ejecutados desde un Servidor virtual.
  • Hay un límite en el uso de recursos. La cantidad de memoria RAM asignada, el espacio en el disco duro que puede ocupar, la cantidad de núcleos que puede utilizar, etc. tienen un límite muy inferior al que tendría si la computadora física no estuviera particionada. Por ejemplo, si la computadora física tiene 16 Gb de RAM, esos 16 Gb de RAM estarían disponibles para los programas si no se particiona; pero si se hacen 4 particiones de 4 Gb de RAM cada una, entonces ningún programa podrá utilizar más de 4 Gb de RAM.
  • Los programas que acceden al Servidor remoto se ejecutan más lentamente. Si tenemos a nuestra Base de Datos en un servidor virtual, los clientes que quieran conectarse desde otras computadoras no lo harán directamente sino que antes deberán pasar por el programa que administra a los servidores virtuales (cuyo nombre es hipervisor). Y aunque ese tiempo de demora es cada vez menor porque la tecnología avanza, siempre existe y siempre existirá.
  • Un daño físico afecta a todos los servidores. Si por ejemplo el disco duro se daña, o se quema un chip de memoria, o se quema la fuente de poder, etc., como es un único hardware el que se utiliza, este es compartido por todos los servidores virtuales, y por lo tanto todos ellos serán afectados. Así, si en un servidor virtual teníamos almacenado nuestro sitio web, en otro servidor virtual teníamos nuestro servidor de e-mails, en otro servidor virtual teníamos nuestra Base de Datos, y el disco duro se dañó y hay que reemplazarlo, ese daño afectará a todos los servidores virtuales.

Conclusión:

Como ya hemos visto, usar un servidor virtual tiene sus ventajas y sus desventajas. Por lo general no se recomienda usarlo cuando las aplicaciones constantemente están leyendo y escribiendo en el disco duro, y eso es justamente lo que ocurre con las aplicaciones que usan bases de datos. Si se usa un servidor virtual para alojar a las bases de datos, las velocidades de respuesta serán inferiores a las que se obtendrán cuando no se lo usa.

Sin embargo, los servidores virtuales son cada vez más eficientes y muchos usuarios no podrán distinguir entre ambas alternativas.

Por lo tanto, una buena política es la siguiente: si la Empresa quiere ahorrar costos, instalar y usar un servidor virtual con la Base de Datos. Si los usuarios se quejan porque la aplicación demora mucho entonces colocar la Base de Datos en un servidor real.

Artículos relacionados:

Usando Oracle VM VirtualBox

El índice del blog Firebird21

El foro del blog Firebird21

 

 

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

Entendiendo a GSTAT (3)

Deja un comentario

Ya hemos visto algunas de las características del programa GSTAT en estos artículos:

Entendiendo a GSTAT (1)

Entendiendo a GSTAT (2)

ahora continuaremos analizándolo.

Opción -data

Esta es la opción que debemos elegir cuando solamente nos interesan las páginas de datos. Como recordarás, en Firebird todo se guarda dentro de páginas. En cada página se guarda solamente una clase de ítems, nunca jamás se mezclan. Así por ejemplo tenemos una página de cabecera, una o varias páginas para las transacciones, una o varias páginas para los datos, una o varias páginas para los índices, etc.

La opción -data nos informa sobre los datos que se encuentran dentro de nuestras tablas. Por ejemplo, si tenemos una tabla llamada ALUMNOS los nombres de los alumnos se encontrarán dentro de una o varias páginas de datos. Si tenemos una tabla llamada PROFESORES los nombres de los profesores se encontrarán dentro de una o varias páginas de datos. Pero las páginas donde se encuentran los nombres de los alumnos son distintas a las páginas donde se encuentran los nombres de los profesores. Es decir, en una página de datos podríamos tener nombres de alumnos, o nombres de profesores, pero jamás de ambos.

Eso significa que una tabla puede tener muchas páginas de datos, y que todas esas páginas le corresponden exclusivamente a esa tabla. Por ejemplo, los nombres de los ALUMNOS podrían encontrarse en las páginas 12.345, 12.346, 20.118, 20.129, y los nombres de los PROFESORES podrían encontrarse en las páginas 11.521 y 12.379, los números son siempre distintos.

gstat01

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

En la Captura 1. invocamos a GSTAT con la opción -data para que nos muestre información sobre los datos contenidos en nuestras tablas y, como es lo normal, enviamos esa información a un archivo de texto para poder analizarlo con más facilidad.

Abrimos ese archivo de texto con el Bloc de Notas del Windows y vemos lo siguiente (Nota: los nombres de nuestras tablas siempre aparecen ordenados alfabéticamente):

gstat02

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

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

ASIENTOSCAB es el nombre de nuestra tabla

(131) es el identificador de esta tabla en RDB$RELATIONS, lo cual podemos comprobar facilmente así:

gstat03

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

Como podemos ver en la Captura 3., el identificador 131 le corresponde a la tabla ASIENTOSCAB. En RDB$RELATIONS se guardan los nombres de todas las tablas que tiene la Base de Datos.

Primary pointer page es número de la primera página donde se guardan los punteros a las páginas de datos. ¿Qué significa eso? Bien, como ya sabemos, cada tabla puede tener varias páginas de datos y los números de esas páginas deben guardarse en algún lado. El lugar donde se guardan es en una Pointer Page. O sea que en una Pointer Page se encuentran los números de cada una de las páginas de datos de una tabla. El número 502 que vemos en la Captura 2. significa que en la página 502 se encuentran los números de las páginas de datos de la tabla ASIENTOSCAB. Las tablas grandes pueden necesitar de varias Pointer Page, la Primary pointer page es la primera de esas páginas. Por ejemplo, en la página 502 (que como ya sabemos es una pointer page) podríamos tener los números 31.218, 31.219, 92.128; eso significa que en las páginas cuyos números son 31.218, 31.219, y 92.128 se encuentran datos de la tabla ASIENTOSCAB.

Index root page es el número de la primera página donde se guardan los punteros a los índices. Así como tenemos páginas donde se guardan los datos de una tabla también tenemos páginas donde se guardan los índices de esa tabla. El número 503 que vemos en la Captura 2. significa que en la página número 503 se encuentran los punteros a las páginas de índices de la tabla ASIENTOSCAB. En otras palabras, los números que se encuentren en la página 503 serán los números de las páginas donde se encuentran los índices de la tabla ASIENTOSCAB. Si por ejemplo en la página 503 están los números 14.127 y 29.218 significa que en esas páginas hay índices que corresponden a la tabla ASIENTOSCAB.

Data pages es la cantidad total de páginas de datos de nuestra tabla. En la Captura 2. vemos que la tabla ASIENTOSCAB está usando 148 páginas de la Base de Datos. Hay que tener en cuenta algo importante aquí: algunas de esas páginas pueden contener basura dejada por los comandos UPDATE y DELETE, o tener datos de transacciones que aún no han finalizado con un COMMIT. O sea que no necesariamente todas las 148 páginas que usa ASIENTOSCAB contienen datos útiles.

Data page slots es la cantidad de punteros que hay en las pointer pages y frecuentemente es igual que data pages ¿por qué eso? porque cada página de datos tiene un puntero que guarda ese número de página. Si observamos la Captura 2. veremos que data pages es 148 y que data page slots también es 148. Eso es lo normal, y está muy bien que así sea, significa que la tabla ASIENTOSCAB usa 148 páginas de datos y que hay 148 punteros indicando cuales son esos números de página. Si los números son diferentes, eso no es un error. ¿qué significa que los números sean diferentes? Cada vez que el motor del Firebird necesita una nueva página para guardar los datos de una tabla guarda el número de esa página en una pointer page de esa tabla. Si más adelante esa página que tenía datos ya no los tiene porque un comando DELETE los borró, el puntero que guardaba  ese número de página permanece en la pointer page, no es borrado de allí. ¿Por qué no es borrado? porque si más adelante la tabla necesita una nueva página de datos usará (de ser posible) una página de datos que ya había usado anteriormente. La finalidad de hacerlo así es que eso acelera el proceso. O sea, es mejor reusar una página de datos vacía que crear una nueva página de datos.

gstat04

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

En la Captura 4. vemos que la página número 502 es una pointer page, que corresponde a la tabla ASIENTOSCAB y que contiene los números de las páginas de datos que tienen datos de la tabla ASIENTOSCAB. O sea que la página número 31.218 es una página de datos y los datos allí contenidos corresponden a la tabla ASIENTOSCAB. Lo mismo se aplica a los demás números que vemos en la segunda columna.

gstat05

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

En la Captura 5. vemos las estadísticas de la tabla CUENTAS y observamos que data pages es distinto que data page slots. ¿Qué significa eso? que alguna vez la tabla CUENTAS tuvo 85 páginas de datos pero ahora solamente está usando 15 de esas páginas, las restantes 70 están vacías, sin datos, pero disponibles para ser re-utilizadas cuando la tabla CUENTAS las necesite. Esas páginas que ahora están vacías alguna vez contuvieron datos pero esos datos fueron borrados con un comando DELETE o cuando se recolectó la basura. Si una página solamente contenía basura la recolección automática de basura o un sweep podrían eliminar a esa basura pero no liberan a la página, esa página sigue perteneciendo a la misma tabla. Cuando un comando INSERT o un comando UPDATE o un comando DELETE necesite de una nueva página de datos para escribir lo que necesita escribir, se usará una de esas páginas de datos que ahora están vacías.

gstat06

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

En la Captura 6. vemos que la tabla CUENTAS tiene una pointer page cuyo número es 498 y que nos indica cuales de sus páginas de datos contienen datos y cuales están vacías. Esas páginas de datos que ahora están vacías se usarán alguna vez si la tabla CUENTAS necesita más páginas de datos. ¿Y cuándo la tabla CUENTAS podría necesitar más páginas de datos? Cuando las páginas que está usando ahora se llenen. Una página podría llenarse porque el comando INSERT ha agregado nuevas filas o porque los comandos UPDATE o DELETE han agregado versiones viejas de una fila. En general, el comando INSERT llena una página hasta un 80% de su capacidad y deja un 20% libre para que los comandos UPDATE y DELETE coloquen allí las versiones antiguas de las filas. ¿Por qué hace eso? Para acelerar el proceso, porque es más rápido guardar las versiones viejas de una fila en la misma página de datos que contiene a esa fila que usar una nueva página de datos. Por ejemplo, si la fila cuyo identificador es 12.345 se encuentra en la página número 32.334 y se hace un UPDATE o un DELETE a la fila con identificador 12.345 lo más conveniente es que las versiones viejas de esa fila también se guarden en la página número 32.334, eso es más rápido que guardar las versiones viejas en otra página de datos.

Mirando los números de data page slots y de data pages podemos saber cuantas páginas de nuestra tabla contienen solamente basura y por lo tanto están disponibles para ser utilizadas. Según la Captura 5. vemos que data page slots es 85 y que data pages es 15, eso implica que hay 70 páginas de datos vacías y disponibles.

Un ciclo backup/restore hace que ambos números sean iguales. En el backup restaurado la cantidad de data pages será siempre igual a la cantidad de data page slots.

Average fills es el promedio de llenado de las páginas de datos, e incluye a las versiones viejas de las filas (las versiones viejas son creadas por los comandos UPDATE y DELETE). Mirando la fill distribution tendremos más detalles.

Fill distribution es una tabla de frecuencias. Si alguna vez estudiaste Estadísticas seguramente las recordarás.

gstat02

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

Esta tabla de frecuencias tiene 5 filas, que van de 20% en 20% y sirve para indicarnos como están llenadas las páginas de datos.

Mirando la Captura 7. descubrimos que hay 97 páginas de datos que están llenas entre un 0% y un 19%, o sea que en esas 97 páginas de datos hay muchísimo espacio libre.

Hay 5 páginas de datos que están llenas entre un 20% y un 39%

Hay 20 páginas de datos que están llenas entre un 40% y un 59%

Hay 3 páginas de datos que están llenas entre un 60% y un 79%

Hay 23 páginas de datos que están llenas entre un 80%  y un 99%, o sea que hay muy poco espacio libre en ellas

La suma de esas cantidades de páginas siempre debe ser igual a data pages. Veamos si es así: 97 + 5 + 20 + 3 + 23 = 148. Está perfecto, así debe ser.

Artículos relacionados:

Entendiendo a GSTAT (1)

Entendiendo a GSTAT (2)

El índice del blog Firebird21

El foro del blog Firebird21

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

 

 

 

 

 

Older Entries Newer Entries