Todas las transacciones tienen un número que las identifica, a ese número se le llama TID (Transaction Identificator).

TID es un número de tipo INTEGER, y los números de tipo INTEGER van desde el 0 hasta el 2 ^ 31 – 1, es decir desde 0 hasta 2.147.483.647

¿Y qué sucede cuándo se alcanzó el límite?

Si el número de tu última transacción es 2.147.483.647 el número de la siguiente transacción será 1, la cuenta se reinicia.

¿Y eso puede causar problemas?

Sí, porque habrá dos transacciones con el mismo TID, o sea que tendrás dos transacciones cuyo TID es 1. Y eso solamente puede provocar corrupción en tu Base de Datos.

¿Y cuál es la solución?

Hacer un ciclo backup/restore usando el programa GBAK antes de alcanzar el límite. Por ejemplo cuando el TID es 2.100.000.000 haces un ciclo backup/restore con GBAK y con eso conseguirás que en la Base de Datos restaurada (no en la original, sino en la que restauraste) se eliminen los TID de todas las transacciones. Por lo tanto:

  • Antes de que el número de la Next Transaction (siguiente transacción) llegue a 2.147.483.647 haces un backup de tu Base de Datos, usando para hacer el backup el programa GBAK
  • Restauras ese backup (probablemente con el mismo nombre que la Base de Datos original)
  • A partir de este momento todas las conexiones deben realizarse en la Base de Datos restaurada, no en la Base de Datos original
  • Eso te permitirá tener otras 2.147.483.647 transacciones

Ejemplo:

  1. Cuando el número de la Next Transaction llega a 2.100.000.000 se hace un backup, usando para ello el programa GBAK
  2. Se restaura el backup
  3. A partir de este momento todas las conexiones se hacen en el backup restaurado
  4. Se vuelve al punto 1.

De esta manera no habrá límites a la cantidad de transacciones totales de tu Base de Datos.

¿Por qué hay que usar GBAK para hacer el backup?

Porque GBAK además de hacer el backup también recolecta la basura (es la opción por defecto, y por supuesto que debe estar habilitada).

¿Qué significa “recolectar la basura”?

Eliminar permanentemente de la Base de Datos versiones de registros que ya no son útiles pero que permanecían en la Base de Datos, ocupando lugar innecesariamente. Cuando se hace un UPDATE o un DELETE el Firebird guarda la versión anterior del registro para que si la transacción finaliza con un ROLLBACK poder regresar a esa versión anterior. Eso va dejando versiones de registros inservibles a los cuales se les llama “basura”, alguna de la cual puede ser eliminada automáticamente, pero no toda. Para asegurarte de que toda la basura sea eliminada debes hacer un sweep (barrido) manual o usar el programa GBAK.

¿Por qué al recolectarse la basura se eliminan los TID?

Porque como hemos visto en este artículo:

https://firebird21.wordpress.com/2013/09/08/entendiendo-los-identificadores-de-las-transacciones/

una transacción solamente le interesa al Firebird cuando está activa, está revertida o está en limbo. Una transacción que finalizó con un COMMIT (o que finalizó con un ROLLBACK pero la basura que dejó ya fue recolectada) no es de interés para el Firebird ni para alguien más. ¿Por qué no? porque ya nada queda por hacer en esa transacción. Una transacción es algo transitorio, algo temporal, después de finalizar con un COMMIT o después que su basura fue recolectada ya no es interesante, porque ya nada se puede hacer en ella. Por ese motivo los TID pueden reutilizarse, pero para que puedan ser reutilizados se debe hacer un backup con GBAK y luego usar la Base de Datos restaurada, no la original.

¿Y cómo puedo saber si el número de la Next Transaction está cerca del límite de 2.147.483.647?

Usando el programa GSTAT que viene incluido con el Firebird (o muchos otros programas de terceros que también te muestran ese dato)

Transacciones1

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

También podrías escribir:

SELECT
   MON$NEXT_TRANSACTION
FROM
   MON$DATABASE

Entonces, cuando el número de la Next Transaction supera los 2.100.000.000 (algo que puede tardar muchos años, dependiendo de la cantidad de transacciones diarias que tenga tu Base de Datos) urgentemente debes ir pensando en hacer un ciclo backup/restore.

Si por ejemplo tienes 1.000.000 de transacciones por día entonces recién en 2.100 días necesitarás realizar el ciclo backup/restore, y eso equivale a más de 5 años y medio.

Artículos relacionados:

La arquitectura MGA

Entendiendo los identificadores de las transacciones

El índice del blog Firebird21

Anuncios