La Next Transaction después de un ciclo backup/restore

Deja un comentario

Como recordarás, al Firebird hay unas cuantas transacciones que le interesan, ellas son:

  • Oldest Transaction, representada por las letras OIT que significan Oldest Interesting Transaction
  • Oldest Active Transaction, representada por las letras OAT
  • Oldest Snapshot Transaction, representada por las letras OST
  • Next Transaction, representada por las letras NT

 Puedes leer más sobre ellas en este artículo:

Entendiendo los identificadores de las transacciones

Los números de las transacciones siempre van en aumento, hasta que se realiza un ciclo backup/restore.

¿Qué sucede cuándo se realiza un ciclo backup/restore?

 Que en la Base de Datos restaurada (no en la original, sino en la restaurada), el identificador de todas las transacciones que finalizaron con un COMMIT es puesto en 1.

¿Y por qué el número de la Next Transaction no es 2, ó 3, ó un número muy cercano a ellos?

Después de todo, podrías pensar que si todas las transacciones que finalizaron con un COMMIT tienen el identificador 1, la Next Transaction debería tener el número 2. O si el programa GBAK abre alguna transacción más, entonces un número muy cercano al 2. Pero no es así, la Next Transaction puede estar muy alejada del número 2.

La respuesta es que el programa GBAK puede abrir muchas transacciones cuando restaura una Base de Datos.

Ejemplo:

En la ventanita “Símbolo del sistema” escribimos el comando GSTAT -h para conocer los identificadores de las transacciones de una Base de Datos.

NT1

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

Se hace el ciclo backup/restore con la opción -v[erbose] y luego se ejecuta el comando GSTAT -h en la Base de Datos restaurada, obteniendo estos valores:

NT2

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

En la Captura 1. podemos ver los identificadores originales de las transacciones y en la Captura 2. podemos ver los valores de los identificadores en la Base de Datos restaurada. Y lo que llama la atención es que la Next Transaction es 304, un número aparentemente muy alto, muy alejado del 3 que uno podría esperar. ¿Por qué?

Porque el programa GBAK abre varias transacciones:

  • Al iniciar la restauración de la Base de Datos, la Next Transaction es puesta en 1
  • Luego, para restaurar los metadatos puede abrir nuevas transacciones
  • Si se usó la opción -o[nce] se iniciará una transacción por cada tabla restaurada
  • Si se usó la opción -v[erbose] se iniciará una transacción por cada índice restaurado

Entonces, ahora sí ya tiene sentido del por qué la Next Transaction está tan alejada del número 1. Es que el programa GBAK abre varias transacciones al restaurar un backup.

Fíjate en un detalle interesante. Como la Base de Datos restaurada aún no ha sido utilizada entonces no importa que los identificadores de las otras transacciones (OIT, OAT, OST) estén desfasados. En este momento nada significan y por lo tanto el número que tengan es irrelevante.

Sin embargo, si te conectas a la Base de Datos e inicias una transacción cuando te desconectes esos números sí ya estarán actualizados. Por ejemplo:

NT3

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

Aquí, usando el programa ISQL nos conectamos a la Base de Datos restaurada, salimos con un EXIT (al salir con un EXIT de ISQL se ejecuta automáticamente un COMMIT, si se sale con un QUIT entonces se ejecuta automáticamente un ROLLBACK) y volvemos a verificar los identificadores de las transacciones ¿y con qué nos encontramos?

Conque los identificadores OIT, OAT y OST se han actualizado.

Estos nuevos valores sí son los correctos. Los anteriores no tenían importancia porque aún no se había usado la Base de Datos, entonces eran irrelevantes sus valores.

Para verificar que la opción -v[erbose] realmente inicia varias transacciones se restauró la misma Base de Datos pero sin esa opción, y este fue el resultado obtenido:

NT4

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

Como puedes ver ahora la Next Transaction es solamente 84, entonces se comprobó que usando la opción -v[erbose] el programa GBAK inicia varias transacciones. Usando esa opción, Next Transaction fue 304, sin usarla fue 84. Desde luego que esos números variarán en tu caso porque dependen de la cantidad de índices que hayas definido.

Conclusión:

Al hacer un ciclo backup/restore con el programa GBAK, en la nueva Base de Datos el valor de la Next Transaction empieza con 1 pero como el programa GBAK abre varias transacciones para poder realizar sus tareas, entonces al finalizar la restauración el valor de la Next Transaction puede estar bastante alejado del 1, dependiendo de la cantidad de transacciones que el programa GBAK tuvo que abrir.

No importa cuales son los valores de los identificadores OIT, OAT, y OST al finalizar la restauración porque aún no han sido utilizados. Solamente después de finalizar la primera transacción sus valores serán actualizados y estarán muy próximos al de la Next Transaction.

Artículos relacionados:

Entendiendo los identificadores de las transacciones

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Inferencia de datos

Deja un comentario

Como sabes, las bases de datos son muy útiles para guardar y procesar datos pero también pueden conllevar un compromiso con la seguridad de los mismos. Muchas veces lo que se guarda en sus tablas es para que lo vean solamente algunos usuarios, no todos los usuarios.

Esto es más importante en las aplicaciones que se diseñan para los organismos de seguridad (militares, policías, servicios de inteligencia, etc.) pero también puede ocurrir con empresas comerciales.

¿Qué significa inferir?

Según el Diccionario es obtener una conclusión, deducir algo a partir de los datos con los que se cuenta.

Ejemplo

Tenemos una tabla llamada SALARIOS donde se guarda el salario de cada empleado de la Empresa. El personal de Recursos Humanos es el encargado de elaborar los cheques de pago a esos empleados, pero no deben conocer el salario de los empleados de nivel superior, solamente deben conocer el salario de los empleados de nivel medio y nivel bajo.

INFERIR1

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

En la Captura 1 estamos viendo el Identificador del Empleado, el Número del Mes, el Número del Año y el Monto de su salario. El Gerente de Recursos Humanos es “Juan” y él sí puede ver esa tabla. Pero su empleada “María” no debería ver el salario del empleado cuyo Identificador es 3, o sea que “María” debería ver esto:

INFERIR2

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

Al mirar esa tabla ella nota que está faltando un empleado con Identificador igual a 3, y entonces cuando la Empresa contrata a un nuevo empleado cuyo nombre es “Martín” ella trata de usar el Identificador 3 para asignárselo a “Martín” y así no tener números de Identificación faltantes. Pero como el Identificador 3 sí existe (aunque ella no puede verlo) al intentar grabar los datos de “Martín” obtendrá un mensaje de error. Y como “María” es inteligente entonces infiere (es decir: deduce) que sí existe un empleado con Identificador igual a 3 pero que a ella no le permiten verlo.

Y como además de inteligente es curiosa a partir de ese momento se dedica a intentar averiguar los datos del empleado con Identificador 3, mediante tablas cruzadas, o algunas otras técnicas.

Diseñando para evitar inferencias

Si algún usuario puede inferir (deducir) que algo se le está ocultando entonces puede también inferir (deducir) que se trata de algo valioso, algo de lo cual podrá obtener provecho económico o de otro tipo. Por algo se le ocultan los datos ¿verdad?.

Entonces, cuando diseñamos nuestras bases de datos debemos pensar en como evitar las inferencias. No es fácil ante usuarios inteligentes y con muchos conocimientos de Informática pero debemos intentarlo.

La primera y elemental medida es impedir que los usuarios puedan asignar identificadores o códigos. Estos deberían ser elegidos y puestos automáticamente por el Servidor del Firebird o por nuestra aplicación.

Lo segundo a recordar siempre es que los identificadores son para uso interno y los códigos son para uso externo. Eso implica que los usuarios jamás deberían ver los identificadores (ni siquiera necesitan saber que existen) y manejarse siempre exclusivamente con códigos. En general los códigos no deberían cambiarse pero si se cambian no afectarán a la operatividad de la Base de Datos porque ésta no los utiliza para nada, son solamente para mostrárselos a los usuarios.

Tercero, los códigos no deberían ser de la forma “A, B, C, D, E, …” o de la forma “1, 2, 3, 4, 5, …” porque si falta una letra o un número en la secuencia entonces es muy fácil inferir que algo se está ocultando.

Conclusión:

Cuando se diseña una Base de Datos un aspecto importante es el relacionado con la seguridad de los datos. Y dentro de la seguridad hay que tomar en cuenta que los usuarios no autorizados a ver una información no puedan realizar inferencias para saber que esa información existe.

En el caso de nuestro ejemplo “María” rápidamente descubrió que se le estaban ocultando los salarios del empleado cuyo Identificador es 3. ¿Por qué? porque la Base de Datos estaba mal diseñada y se le permitía a ella asignar un Identificador al nuevo empleado. En una Base de Datos bien diseñada ningún usuario, por ningún motivo, puede asignar o cambiar un Identificador o un Código. Si alguna vez se requiere hacer eso entonces debería hacerse exclusivamente usando nuestra aplicación.

Artículos relacionados

Usando IDENTIFICADORES y CÓDIGOS en nuestras tablas

El índice del blog Firebird21