Estoy realmente confundido acerca de cómo digerir el hecho de que una transacción es atómica. Si una transacción es un conjunto de «consultas», entonces, ¿cómo será atómica? Estoy relacionando la palabra «consultas» con una consulta SQL general. Por lo tanto, una transacción se convierte en nada más que un conjunto de consultas SQL ejecutadas al mismo tiempo. Pero el hecho de que cada consulta tenga múltiples operaciones, realmente no entiendo cómo las consultas ejecutadas anteriormente (en el mismo conjunto) se revierten si ocurre un error en una consulta posterior. ¿Que me estoy perdiendo aqui? ¡Gracias!
Responder
TL; DR; El registro de transacciones contiene toda la información necesaria para recrear o deshacer cada transacción, dependiendo de si contiene un registro de confirmación para esa transacción o no.
En las bases de datos SQL, la atomicidad de la transacción se implementa con mayor frecuencia usando registro de escritura anticipada (lo que significa que las entradas del registro de transacciones se escriben antes que se actualicen las tablas e índices reales).
Consultas en el sentido estricto de la palabra, es decir, SELECT declaraciones y otras operaciones de lectura que no cambian el estado de la base de datos, no se registran ya que no hay nada que confirmar o revertir, y como tal, el concepto de atomicidad realmente no se aplica aquí, al menos a nivel DBMS. Es posible que la aplicación que consume los resultados de la consulta deba aplicar la atomicidad descartando los resultados de las consultas anteriores si una de las consultas posteriores falla y provoca la reversión.
Cuando las declaraciones DML (INSERT, UPDATE, DELETE, MERGE) y otras declaraciones que cambian el estado de la base de datos get ejecutado, los cambios que realizan se escriben primero en el registro de escritura anticipada (WAL). Si todas las declaraciones tienen éxito y se emite una confirmación (explícita o implícita), este hecho también se registra en la WAL y el registro se conserva. Esto hace que los cambios sean duraderos. Pueden escribirse en la tabla real y en los segmentos de índice en algún momento posterior, durante un punto de control o una repetición del registro.
Sin embargo, si una de las declaraciones falla, no habría ningún registro de confirmación en el registro para esta transacción, y el DBMS deshará los cambios de tabla e índice realizados hasta ahora utilizando los registros de registro anteriores de esa transacción.
De manera similar, si el proceso del DBMS falla, o se corta la energía, no habrá un registro de confirmación para la transacción en curso, y los cambios en la tabla o en el índice que pueden haber sido persistentes se deshacerán durante la reproducción del registro.
Comentarios
- Esto no es ' t correcto: " consultas en el sentido estricto de la palabra, es decir, sentencias SELECT y otras operaciones de lectura que no cambian el estado de la base de datos, no se registran ya que no hay nada que confirmar o revertir " – dependiendo de la configuración de su base de datos, incluso un SELECT puede iniciar un tr implícito ansaction. brentozar.com/archive/2018/02/…
- I ' No digo que ' no están bajo el control de transacciones, ' digo eso, ya que están no cambia nada, no se registran.
Respuesta
Una transacción es atómica cuando está encapsulada como esto:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT En ese caso, ambas actualizaciones en las dos tablas separadas se confirmarán juntas o se revertirán (fallarán) juntas. Atomicidad significa esta es la unidad más pequeña de una transacción que se confirmará.
Sin embargo, si más adelante, intenta ejecutar una consulta separada fuera de ese alcance, esa sería una transacción separada.
Si intentas algo como esto:
BEGIN TRAN UPDATE dbo.Users SET Reputation = Reputation + 1 WHERE Id = 26837; Y luego, en tu aplicación, haces otro tipo de trabajo, como código C #, y luego regresas a la base de datos más tarde y haz esto:
UPDATE dbo.Posts SET Score = Score + 1 WHERE Id = 227563; COMMIT Entonces, tanto la actualización de Usuarios anterior como la actualización de Publicaciones subsiguiente tendrán éxito o fallarán juntas.
Sin embargo, en la vida real, no puede mantener una transacción abierta como que durante un período prolongado de tiempo porque estará bloqueando a otras personas para que no trabajen en la base de datos. Es por eso que a menudo verá consejos como «Mantenga su transacción breve y sencilla», es decir, ingrese, haga su trabajo y salga. No mantenga abiertas las transacciones explícitamente.
Comentarios
- Una transacción es siempre atómica, no es ' ¿no es así?
- Sí, pero dependiendo de la configuración de su base de datos, es posible que tenga las transacciones implícitas activadas, es decir, ' re obtener un BEGIN TRAN incluso si no ' no lo solicita. Eso varía según el proveedor; por ejemplo, escuché que Oracle utiliza transacciones implícitas de forma predeterminada, mientras que SQL Server no.Puede PENSAR que ' está recibiendo solo una transacción si proviene de un entorno de Oracle, cuando es posible que obtenga varias transacciones diferentes en SQL Server, cada una de las cuales sería atómica.