transaccional - ¿Puede alguna vez fallar una instrucción COMMIT(en SQL)? ¿Cómo?

transacciones de sql server 2008

Question

Cuando se trabaja con transacciones de base de datos, ¿cuáles son las posibles condiciones (si las hay) que podrían causar que la declaración final COMMIT en una transacción falle, suponiendo que todas las declaraciones dentro de la transacción ya se hayan ejecutado sin problemas?

Por ejemplo ... digamos que tiene un protocolo de confirmación de two-phase o de tres fases en el que hace un montón de declaraciones, luego espere a que un proceso maestro le indique cuándo está bien cometer finalmente la transacción:

-- <initial handshaking stuff>
START TRANSACTION;
-- <Execute a bunch of SQL statements>
-- <Inform master of readiness to commit>
-- <Time passes... background transactions happening while we wait>
-- <Receive approval to commit from master (finally!)>
COMMIT;

Si su código llega a esa declaración final de COMPROMISO y lo envía a su DBMS, ¿puede alguna vez obtener un error (problema de singularidad, base de datos completa, etc.) en esa declaración? ¿Qué errores? ¿Por qué? ¿Cómo aparecen? ¿Varía dependiendo de qué DBMS ejecutes?

Answer 1

COMPROMISO puede fallar. Es posible que haya tenido recursos suficientes para registrar todos los cambios que desea hacer, pero carece de recursos para implementar los cambios.

Y eso no está considerando otras razones por las que podría fallar:

1. Es posible que el cambio en sí no se ajuste a las restricciones de la base de datos.

2. La pérdida de potencia impide que las cosas se completen.

3. El nivel de concurrencia de selección solicitada puede no permitir una actualización (cursores que actualizan una tabla modificada, por ejemplo).

4. El compromiso puede tener un tiempo de espera o estar en una conexión que se agote debido a problemas de hambre.

5. La conexión de red entre el cliente y la base de datos puede perderse.

Y todas las otras razones "simples" que no están en la parte superior de mi cabeza.

Answer 2

Ciertamente, podría haber una serie de problemas. El acto de cometer, en y por sí mismo, debe hacer alguna entrada final, permanente para indicar que la transacción se cometió. Si falla la entrada, la transacción no se puede confirmar.

Como señala Ignacio, puede haber una verificación de restricciones diferida (esto podría ser cualquier forma de restricción, no solo una restricción única, dependiendo del motor DBMS).

Específico de SQL Server: el vaciado de los datos de FILESTREAM puede diferirse hasta el momento de la confirmación. Eso podría fallar.

Answer 3

Es posible que algunos motores de bases de datos aplacen la comprobación de restricciones del índice ÚNICO hasta COMPRAR. Obviamente, si la restricción no se cumple en el momento de la confirmación, fallará.

Answer 4

No importa cuán maravillosamente pueda diseñarse un sistema, habrá alguna posibilidad de que un compromiso llegue a una situación en la que es imposible saber si tuvo éxito o no. En algunos casos, puede que no importe (por ejemplo, si un disco duro que contiene la base de datos se convierte en una pila de escoria, puede ser imposible saber si el compromiso tuvo éxito o no antes de que ocurriera, pero realmente no importaría); En otros casos, sin embargo, esto podría ser un problema. Especialmente con los sistemas de bases de datos distribuidas, si se produce un fallo en la conexión justo en el momento adecuado durante una confirmación, será posible que ambas partes estén seguras de si la otra parte está esperando una confirmación o una reversión.

Answer 5

Por supuesto.

En un entorno de múltiples usuarios, el COMMIT puede fallar debido a los cambios realizados por otros usuarios (por ejemplo, su COMMIT violaría una restricción de referencia cuando se aplica a la base de datos actual ...).

Thomas

Answer 6

Si está utilizando la confirmación de dos fases, entonces no. Todo lo que podría salir mal se hace en la fase de preparación.

Puede que aún haya interrupciones en la red, menos energía, rayos cósmicos, etc. durante la confirmación, pero aún así, las transacciones se habrán escrito en un almacenamiento permanente y, si se ha activado una confirmación, los procesos de recuperación deberían llevarla a cabo.

Ojalá.

Answer 7

Un elemento muy simple y que a menudo se pasa por alto: falla de hardware. La confirmación puede fallar si el servidor subyacente muere. Esto podría estar relacionado con el disco, la CPU, la memoria o incluso la red.

La transacción podría fallar si nunca recibe la aprobación del maestro (por varias razones).