Transacciones: BEGIN, COMMIT y ROLLBACK

Clase 16 de 26Curso de Gestión de Bases de Datos con SQL Server

Resumen

Cuando un proceso de negocio involucra varias operaciones que deben completarse juntas o no ejecutarse en absoluto, las transacciones se convierten en la herramienta fundamental para mantener la integridad de los datos. Comprender cómo funcionan, cómo monitorearlas y cómo revertirlas ante fallos marca la diferencia entre una base de datos confiable y una que acumula inconsistencias silenciosas.

¿Por qué una transacción protege la consistencia de tus datos?

Imagina un escenario real: el cierre de caja en una tienda necesita actualizar el inventario, registrar el movimiento de caja y cerrar el pedido [0:08]. Son tres operaciones. Si la segunda falla por un error de red, un conflicto de datos o un corte de luz, el inventario ya cambió pero el pedido sigue abierto. La base de datos quedó en un estado inconsistente. Eso es exactamente lo que una transacción previene.

Una transacción es una secuencia de pasos que deben ejecutarse de forma completa o simplemente no ejecutarse. Es el principio de "todo o nada".

¿Qué significa el principio ACID en bases de datos?

El principio ACID [1:00] es un acrónimo que define cuatro propiedades fundamentales:

  • Atomicidad: todas las operaciones se completan o ninguna tiene efecto.
  • Consistencia: la base de datos pasa de un estado válido a otro estado válido, respetando siempre las restricciones.
  • Aislamiento (isolated): las transacciones concurrentes no se ven entre sí hasta que hacen commit, es decir, están aisladas.
  • Durabilidad: una vez que se hace commit, el cambio persiste aunque el servidor se caiga.

ACID no es solo un concepto académico. Es lo que hace que SQL Server sea confiable en producción [1:52].

¿Cómo se estructura una transacción explícita básica?

Una transacción explícita agrupa operaciones secuenciales [2:05]. Por ejemplo, en tres pasos:

  1. Actualizar inventario: un UPDATE en la tabla de productos que reduce el stock.
  2. Registrar el pedido: un INSERT INTO en la tabla de pedidos.
  3. Registrar el detalle: un INSERT INTO en la tabla detalle pedidos.

Si una de estas operaciones falla, la transacción no se completa. Al ejecutarla correctamente, SQL Server confirma cada fila afectada: una fila por cada operación exitosa [3:18].

¿Cómo monitorear transacciones abiertas con TRANCOUNT?

En producción, muchas transacciones toman tiempo en terminar porque involucran múltiples pasos. La función de sistema @@TRANCOUNT [3:50] permite saber cuántas transacciones están abiertas en un momento dado.

  • Si @@TRANCOUNT devuelve cero, no hay transacciones corriendo.
  • Si devuelve un número mayor, hay transacciones activas y conviene esperar a que terminen antes de realizar revisiones o auditorías.

Esto es útil para evitar encolar transacciones sobre transacciones o ejecutar comandos de análisis mientras una operación larga aún no finaliza [4:50].

¿Cómo funcionan los savepoints y el rollback en SQL Server?

Cuando las transacciones son muy largas, puedes definir puntos de guardado intermedios con SAVE TRANSACTION [5:38]. Esto permite revertir parcialmente una transacción sin perder todo el trabajo previo.

¿Qué es un savepoint y cuándo usarlo?

En una transacción por partes funciona así [5:55]:

  • Se ejecuta la operación uno (por ejemplo, un INSERT INTO resumen_mensual) y se crea un punto de guardado con SAVE TRANSACTION punto_guardado_1.
  • Se ejecuta la operación dos (por ejemplo, un DELETE agresivo).
  • Si la operación dos afecta demasiadas filas (por ejemplo, más de mil), se ejecuta ROLLBACK TRANSACTION punto_guardado_1, revirtiendo solo hasta ese punto.

El sistema devuelve un mensaje claro: "Se revirtió la limpieza de logs porque hay demasiadas filas afectadas" [6:48].

¿Cómo funciona el rollback completo ante un fallo?

Para simular un fallo [7:15], se puede intentar una operación imposible, como restar un valor que deje el stock en negativo. El flujo es:

  1. Se verifica el stock actual: por ejemplo, 383 unidades.
  2. Se inicia la transacción con un UPDATE que resta 999 al stock.
  3. La operación falla porque viola una restricción.
  4. Se ejecuta el ROLLBACK TRANSACTION, devolviendo los datos a su estado original.
  5. Al consultar nuevamente, el stock sigue en 383 [8:30].

Las transacciones son el mecanismo que convierte operaciones individuales en procesos atómicos. Sin ellas, cualquier proceso de múltiples pasos puede dejar la base de datos en un estado inconsistente.

Como desafío práctico, intenta envolver el stored procedure de cierre de mes en una transacción, simula un error agregando una operación que falle intencionalmente (como un INSERT en una columna que no existe) y verifica que el rollback revierta todo. Comparte tu código y el resultado del SELECT * FROM resumen_mensual antes y después en los comentarios.