¿Has respondido a las preguntas hechas en el artículo: Más preguntas sobre transacciones (2)?

Si lo has hecho, ¡¡¡excelente!!! porque sirven para auto-evaluarte. Hay que participar.

Veamos ahora cuales son las respuestas correctas.

Pregunta 1. ¿Cuántas transacciones como máximo puede tener una Base de Datos?

[100.000.000]     [1.000.000.000]     [2.147.483.647]      [No hay límite]

La respuesta es 2.147.483.647. ¿Por qué? Porque el número que identifica a las transacciones se guarda como “signed integer” en las versiones de Firebird hasta las 2.5.x, (a partir de la versión 3.0 se guardará como un “unsigned integer”), así que en el momento de escribir este artículo se usa “signed integer”. Firebird está escrito en el lenguaje C++ y en ese lenguaje un número entero se guarda en 4 bytes. Y como 4 bytes equivale a 32 bits entonces la cantidad de valores distintos es 2 ^ 32 que es igual a 4.294.967.296, la mitad de ellos positivos y la otra mitad negativos. Pero como Firebird usa “signed integer”, es decir, enteros con signo, solamente se consideran el cero y los números positivos. El cero no se usa para identificar transacciones y por lo tanto, el mayor número posible de transacciones en una Base de Datos es 2.147.483.647

Algo importante a tener en cuenta es que cuando la Next Transaction ya está muy cerca de ese número hay que realizar un ciclo backup/restore para que se reinicie y así tener otras 2.147.483.000 transacciones disponibles.

Pregunta 2. Después de realizar un ciclo backup/restore con el programa GBAK, ¿cuál es el valor de Next Transaction en la Base de Datos restaurada?

[0]     [1]     [2]     [3]     [1.000]     [Es variable]

La respuesta: es variable. Aunque en general es menor que 1.000. Cuando se empieza a realizar un restore la Next Transaction se inicializa en 1. Pero la restauración requiere de varias transacciones así que cuando la restauración finaliza el valor de Next Transaction es bastante mayor que 1. Normalmente anda alrededor de 300. También depende de si se escribió la opción -verbose o no, porque si se la escribió, cada índice restaurado necesitará de una nueva transacción.

Así que por lo general, salvo que tengas una Base de Datos gigantesca, el valor de la Next Transaction al finalizar el restore será mayor que 1 y menor que 1.000

Pregunta 3. Si una transacción T1 finalizó con un ROLLBACK e inmediatamente después se inició una transacción T2. Esta transacción T2 ¿tendrá el mismo número que la transacción T1 o un número diferente?

[El mismo número]     [Un número diferente]

Todas las transacciones tienen un número diferente. Jamás dos transacciones podrían tener el mismo número en una Base de Datos porque ese número sirve para identificarlas y evidentemente si dos transacciones tuvieran el mismo número no se podría diferenciarlas.

Pregunta 4. Si una transacción realizó un UPDATE y después finalizó con un COMMIT. ¿Dejó basura en la Base de Datos?

[Sí]     [No]

La respuesta es . Todas las operaciones de UPDATE y de DELETE dejan basura en la Base de Datos sin importar si la transacción finalizó con un COMMIT o con un ROLLBACK porque en ambos casos dejan basura.

En general el Firebird es muy bueno recolectando la basura dejada por las transacciones que finalizaron con un COMMIT entonces no tardará en eliminar esa basura, pero la transacción sí dejó basura.

Pregunta 5. Si una transacción realizó un UPDATE y después finalizó con un ROLLBACK. ¿Dejó basura en la Base de Datos?

[Sí]     [No]

La respuesta es . Todas las operaciones de UPDATE y de DELETE dejan basura en la Base de Datos sin importar si la transacción finalizó con un COMMIT o con un ROLLBACK porque en ambos casos dejan basura.

La basura dejada por los ROLLBACK se elimina cuando se realiza un sweep.

Artículos relacionados:

Más preguntas sobre transacciones (2)

Entendiendo los identificadores de las transacciones

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

Entendiendo sweep y garbage collection

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios