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

Question

Al trabajar con transacciones de bases de datos, ¿cuáles son las condiciones posibles (si las hay) que harían que falle la declaración final COMMIT en una transacción, suponiendo que todas las instrucciones dentro de la transacción ya se hayan ejecutado sin problemas?

---

Por ejemplo ... digamos que usted tiene un poco de two-phase o three-phase commit protocol en el que hacer un montón de declaraciones, a continuación, esperar algún proceso maestro que le diga cuando está bien para 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 la sentencia final de COMMIT y lo envía a su DBMS, ¿puede alguna vez obtener un error (problema de exclusividad, base de datos llena, etc.) en esa declaración? Que errores? ¿Por qué? ¿Cómo aparecen? ¿Varía dependiendo de qué DBMS ejecutas?

Answer 1

Es posible que algunos motores de bases de datos difieran la comprobación de restricciones de índice ÚNICO hasta COMMIT. Obviamente, si la restricción no es verdadera en el momento de la confirmación, fallará.

Answer 2

Sure.

En un entorno multiusuario, COMMIT puede fallar debido a cambios por otros usuarios (por ejemplo, su COMMIT violaría una restricción referencial cuando se aplica a la base de datos actual ...).

Thomas

Answer 3

Ciertamente, podría haber una serie de cuestiones. El acto de cometer, en sí mismo, debe hacer una entrada definitiva y permanente para indicar que la transacción se ha comprometido. Si la entrada falla, la transacción no se puede confirmar.

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

Específico del servidor SQL: los datos de FILESTREAM pueden diferirse hasta el momento de la confirmación. Eso podría fallar

Answer 4

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. Puede ser disco, CPU, memoria o incluso relacionado con la red.

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

Answer 5

COMMIT puede fallar. Es posible que haya tenido suficientes recursos para registrar todos los cambios que deseaba realizar, pero le faltan recursos para implementar realmente los cambios.

Y eso sin tener en cuenta otras razones por las que puede fallar:

1. El cambio en sí mismo puede no encajar en las limitaciones 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 (los cursores actualizan una tabla modificada, por ejemplo).

4. Es posible que el tiempo de espera de la confirmación exceda el tiempo de espera o que se desconecte debido a problemas de inanición.

5. Se puede perder la conexión de red entre el cliente y la base de datos.

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

Answer 6

No importa cuán maravillosamente se diseñe un sistema, existirá la posibilidad de que una confirmación llegue a una situación en la que sea imposible saber si tuvo éxito o no. En algunos casos, puede no importar (por ejemplo, si un disco duro que contiene la base de datos se convierte en una pila de escoria, puede ser imposible determinar si la confirmación tuvo éxito o no antes de que ocurriera, pero en realidad no importaría); en otros casos, sin embargo, esto podría ser un problema. Especialmente con los sistemas de bases de datos distribuidos, si se produce una falla de conexión justo en el momento correcto durante una confirmación, será posible que ambas partes estén seguras de si la otra parte espera una confirmación o una reversión.

Answer 7

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

Aún podría haber interrupción de red, menos energía, rayos cósmicos, etc., durante la confirmación, pero aún así, las transacciones se habrán escrito en almacenamiento permanente, y si se ha activado una confirmación, los procesos de recuperación deberían llevarlas mediante.

Esperemos que.