COMMIT Y ROLLBACK

COMMIT Y ROLLBACK

COMMIT
Consolidar, confirmar o hacer un commit se refiere, en el contexto de la ciencia de la computación y la gestión de datos, a la idea de confirmar un conjunto de cambios provisionales de forma permanente. Un uso popular es al final de una transacción de base de datos.
Una sentencia COMMIT en SQL finaliza una transacción de base de datos dentro de un sistema gestor de base de datos relacional (RDBMS) y hace visibles todos los cambios a otros usuarios. El formato general es emitir una sentencia BEGIN WORK o BEGIN TRANSACTION (o la que sea para el lenguaje SQL en cuestión), una o más sentencias SQL, y entonces la sentencia COMMIT.

EJEMPLO
BEGIN TRANSACTION;

DELETE FROM Paises.telefonos

WHERE id_telefono = 555555555;

COMMIT TRANSACTION;
En términos de transacciones, lo opuesto de una consolidación para descartar el intento de realizar cambios de una transacción es una reversión o rollback. Se puede enviar una sentencia ROLLBACK de reversión de transacción, la cual deshace todo el trabajo realizado desde que se emitió BEGIN TRANSACTION. Una sentencia COMMIT eliminará cualquiera de los puntos de recuperación existentes que puedan estar en uso.


ROLLBACK
En tecnologías de base de datos, un rollback o reversión es una operación que devuelve a la base de datos a algún estado previo. Las reversiones son importantes para la integridad de la base de datos, a causa de que significan que la base de datos puede ser restaurada a una copia limpia incluso después de que se han realizado operaciones erróneas. Son cruciales para la recuperación ante errores de un servidor de base de datos, como por ejemplo un cuelgue del equipo. Al realizar una reversión cualquier transacción que estuviera activa en el tiempo del cuelgue es revertida y la base de datos se ve restaurada a un estado consistente.
En SQL, ROLLBACK es un comando que causa que todos los cambios de datos desde la última sentencia BEGIN WORK, o START TRANSACTION sean descartados por el sistema de gestión de base de datos relacional (RDBMS), para que el estado de los datos sea revertida a la forma en que estaba antes de que aquellos cambios tuvieran lugar.
Una sentencia ROLLBACK también publicará cualquier punto de recuperación existente que pudiera estar en uso.
En muchos dialectos de SQL, los ROLLBACK son específicos de la conexión. Esto significa que si se hicieron dos conexiones a la misma base de datos, un ROLLBACK hecho sobre una conexión no afectará a las demás conexiones. Esto es vital para el buen funcionamiento de la concurrencia en la base de datos.
La funcionalidad de la reversión está normalmente implementada en un registro de transacciones, pero puede también estar implementada mediante control de concurrencia multiversión.

EJEMPLO
Resultado de imagen para ROLLBACK EJEMPLO


TRANSACCIONES
Una transacción es una interacción con una estructura de datos compleja, compuesta por varios procesos que se han de aplicar uno después del otro. La transacción debe realizarse de una sola vez y sin que la estructura a medio manipular pueda ser alcanzada por el resto del sistema hasta que se hayan finalizado todos sus procesos.

Ejemplo

La transferencia de fondos entre dos cuentas corrientes de un banco. Si queremos transferir, supongamos 5000€ de la cuenta corriente de A y B y las cuentas tienen, respectivamente, 20000€ y 0€ de saldo los pasos lógicos serían:
  1. Comprobar si en la cuenta A hay dinero suficiente.
  2. Restar 5000€ de la cuenta de A, con lo que su saldo pasa a ser de 15000€.
  3. Sumar 5000€ a la cuenta de B, con lo que los saldos quedan A= 15000€ y B= 5000€
Ahora bien, si entre el paso 2 y el 3 el sistema sufre una parada o error inesperado las cuentas quedarían como A= 15000 y B= 0 con lo cual se han volatilizado 5000€ y presumiblemente ni A ni B estarán contentos, y hubiesen preferido que la transacción nunca hubiese sido iniciada.
Este ejemplo ilustra por qué las transacciones tienen un comportamiento deseado de Todo o nada, o se realiza completamente o no debe tener ningún efecto.

Propiedades

Las transacciones deben cumplir cuatro propiedades ACID:
  1. Atomicidad (Atomicity):es la propiedad que asegura que la operación se ha realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias.
  2. Consistencia (Consistency): es la propiedad que asegura que sólo se empieza aquello que se puede acabar. Por lo tanto, se ejecutan aquellas operaciones que no van a romper la reglas y directrices de integridad de la base de datos.
  3. Aislamiento (Isolation): es la propiedad que asegura que una operación no puede afectar a otras. Esto asegura que la realización de dos transacciones sobre la misma información nunca generará ningún tipo de error.
  4. Permanencia (Durability): es la propiedad que asegura que una vez realizada la operación, ésta persistirá y no se podrá deshacer aunque falle el sistema.
La atomicidad frente a fallos se suele implementar con mecanismos de journaling, y la protección frente a accesos concurrentes mediante bloqueos en las estructuras afectadas. La serialibilidad viene garantizada por la atomicidad. La permanencia se suele implementar forzando a los periféricos encargados de almacenar los cambios a confirmar la completa y definitiva transmisión de los datos al medio (generalmente, el disco).
La forma algorítmica que suelen tener las transacciones es la siguiente:
iniciar transacción (lista de recursos a bloquear)
ejecución de las operaciones individuales.
if (todo_ok){
 aplicar_cambios
}
else{
 cancelar_cambios
}
En cualquier momento, el programa podría decidir que es necesario hacer fallar la transacción, con lo que el sistema deberá revertir todos los cambios hechos por las operaciones ya hechas. En el lenguaje SQL se denomina COMMIT a aplicar_cambios y ROLLBACK a cancelar_cambios.
Las transacciones suelen verse implementadas en sistemas de bases de datos y, más recientemente, se han visto incorporadas a cómo gestiona un sistema operativo la interacción con un sistema de archivos (como varias características de las bases de datos, debido a que son muy similares arquitectónicamente).

Transacciones en bases de datos

Una transacción en un Sistema de Gestión de Bases de Datos es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.
Un SGBD se dice transaccional si es capaz de mantener la integridad de los datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se hubiese realizado. Una transacción debe contar con ACID (un acrónimo inglés) que quiere decir: Atomicidad, consistencia, aislamiento y durabilidad.
Para esto, el lenguaje de consulta de datos SQL (Structured Query Language), provee los mecanismos para especificar que un conjunto de acciones deben constituir una transacción.
  • BEGIN TRAN: Especifica que va a empezar una transacción.
  • COMMIT TRAN: Le indica al motor que puede considerar la transacción completada con éxito.
  • ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la base al punto de integridad.
En un sistema ideal, las transacciones deberían garantizar todas las propiedades ACID; en la práctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento.

Ejemplo

Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la que incrementamos el saldo de la cuenta destino. Para garantizar la integridad del sistema (es decir, para que no aparezca o desaparezca dinero), las dos operaciones deben ser atómicas, el sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.

SAVEPOINT
Un punto de recuperación, del inglés savepoint, es una forma de implementar subtransacciones (también conocidas como transacciones anidadas) dentro de un sistema gestor de base de datos relacional indicando un punto dentro de una transacción de base de datos que puede ser restaurada sin afectar a cualquier trabajo realizado en la transacción antes de que el punto de recuperación fuera creado. Pueden existir varios puntos de recuperación dentro de una transacción individual. Los puntos de recuperación son útiles para implementar la recuperación ante errores complejos en aplicaciones de base de datos. Si ocurre un error en medio de una transacción compuesta por múltiples sentencias, la aplicación puede ser capaz de recuperarse del error revirtiendo la transacción hasta un punto de recuperación anterior sin necesidad de abortar la transacción completa.
Un punto de recuperación puede estar declarado emitiendo una sentencia SAVEPOINT name. Todos los cambios realizados después de que un punto de recuperación haya sido declarado pueden ser deshechos emitiendo una sentencia ROLLBACK TO SAVEPOINT name. Emitiendo RELEASE SAVEPOINT name causará que el punto de recuperación concreto sea descartado, pero no afectará a nada más. Emitiendo los comandos ROLLBACK o COMMIT también descartará cualesquiera puntos de recuperación creados desde el inicio de la transacción principal.
Los puntos de recuperación son implementados de una u otra forma en sistemas de bases de datos tales como PostgreSQL, Oracle, Microsoft SQL Server, MySQL, DB2, y Firebird. Los puntos de recuperación están también definidos en el estándar SQL.

EJEMPLO
Resultado de imagen para SAVEPOINT EJEMPLO
ACID EN UNA TRANSACCION
En bases de datos se denomina ACID a las características de los parámetros que permiten clasificar las transacciones de los sistemas de gestión de bases de datos. Cuando se dice que es ACID compliant se indica -en diversos grados- que éste permite realizar transacciones.
En concreto ACID es un acrónimo de Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad en español.

EJEMPLO
Resultado de imagen para acid en transacciones EJEMPLO

Definiciones

  • Atomicidad: Si cuando una operación consiste en una serie de pasos, bien todos ellos se ejecutan o bien ninguno, es decir, las transacciones son completas.
  • Consistencia: (Integridad). Es la propiedad que asegura que sólo se empieza aquello que se puede acabar. Por lo tanto se ejecutan aquellas operaciones que no van a romper las reglas y directrices de Integridad de la base de datos. La propiedad de consistencia sostiene que cualquier transacción llevará a la base de datos desde un estado válido a otro también válido. "La Integridad de la Base de Datos nos permite asegurar que los datos son exactos y consistentes, es decir que estén siempre intactos, sean siempre los esperados y que de ninguna manera cambian ni se deformen. De esta manera podemos garantizar que la información que se presenta al usuario será siempre la misma."
  • Aislamiento: Esta propiedad asegura que una operación no puede afectar a otras. Esto asegura que la realización de dos transacciones sobre la misma información sean independientes y no generen ningún tipo de error. Esta propiedad define cómo y cuándo los cambios producidos por una operación se hacen visibles para las demás operaciones concurrentes. El aislamiento puede alcanzarse en distintos niveles, siendo el parámetro esencial a la hora de seleccionar SGBDs.
  • Durabilidad: (Persistencia). Esta propiedad asegura que una vez realizada la operación, esta persistirá y no se podrá deshacer aunque falle el sistema y que de esta forma los datos sobrevivan de alguna manera.
Cumpliendo estos 4 requisitos un sistema gestor de bases de datos puede ser considerado ACID Compliant.

Puesta en práctica

Poner las características ACID en ejecución no es tan sencillo. El proceso de una transacción requiere a menudo un número de cambios pequeños al ser realizado, incluyendo la puesta al día de los índices que son utilizados en el sistema para acelerar búsquedas. Esta secuencia de operaciones puede fallar por un número de razones; por ejemplo, el sistema puede no tener ningún sitio disponible en sus accionamientos de disco, o puede haber sobrepasado su tiempo de CPU asignado.
ACID sugiere que la base de datos pueda realizar todas estas operaciones inmediatamente. De hecho esto es difícil de conseguir. Hay dos clases de técnicas populares: escribir a un registro antes de continuar y la paginación de la sombra. En ambos casos, los bloqueos se deben implantar antes que la información sea actualizada, y dependiendo de la técnica puesta en práctica, todos los datos se tienen que haber leído. En escribir a un registro antes de continuar, la atomicidad es garantizada asegurándose que toda la información esté escrita a un registro antes que se escriba a la base de datos. Eso permite que la base de datos vuelva a un estado anterior en caso de un desplome. En sombrear, las actualizaciones se aplican a una copia de la base de datos, y se activa la nueva copia cuando la transacción sea confiable. La copia refiere a partes sin cambios de la vieja versión de la base de datos, en vez de ser un duplicado entero.
Esto significa que debe realizarse un bloqueo en cualquier momento antes de procesar datos en una base de datos, incluso en operaciones leídas. Mantener una gran cantidad de bloqueos da lugar a un aumento substancial indirecto de los procesos así como a una alteración de la concurrencia de ellos. Si el usuario A está procesando una transacción que ha leído una fila de los datos que el usuario B desea modificar, por ejemplo, el usuario B debe esperar hasta que el otro usuario acabe..
Una alternativa a la fijación es mantener copias separadas de cualquier dato que se modifique. Esto permite a usuarios leer datos sin adquirir ningún bloqueo. Usando de nuevo el ejemplo anterior, cuando la transacción del usuario consigue los datos que el usuario B ha modificado, la base de datos puede recuperar la versión exacta de los datos para que el usuario A comience su transacción. Esto asegura que el usuario A consiga una vista constante de la base de datos aunque otros usuarios estén cambiando datos.
Es difícill garantizar las características ACID en un ambiente de red. Las conexiones de red pueden fallar, o dos usuarios pueden utilizar la misma parte de la base de datos al mismo tiempo.

BEGIN


  • Tiempo de lectura: 2 minutos
  • Colaboradores
    • Douglas Laudenschlager
      •  
    • olprod
      •  
    • OpenLocalizationService
SE APLICA A: síSQL Server (a partir de 2008) síAzure SQL Database síAzure SQL Data Warehouse síAlmacenamiento de datos paralelos
Incluye una serie de instrucciones Transact-SQL de forma que se pueda ejecutar un grupo de instrucciones Transact-SQL. BEGIN y END son palabras clave del lenguaje de control de flujo.
Icono de vínculo de tema Convenciones de sintaxis de Transact-SQL

Sintaxis

BEGIN  
    { sql_statement | statement_block }   
END

Argumentos

{ sql_statement | statement_block }
Se trata de cualquier instrucción o grupo de instrucciones Transact-SQL definidas con un bloque de instrucciones.

Notas

Los bloques BEGIN...END pueden anidarse.
Aunque todas las instrucciones Transact-SQL son válidas en un bloque BEGIN...END, ciertas instrucciones Transact-SQL no deben agruparse en el mismo proceso por lotes o bloque de instrucciones.

Ejemplos

En el siguiente ejemplo, BEGIN y END definen un conjunto de instrucciones Transact-SQL que se ejecutan juntas. Si el bloqueo BEGIN...END no se incluye, ambas instrucciones ROLLBACK TRANSACTION se ejecutarán y se devolverán ambos mensajes PRINT.
USE AdventureWorks2012;  
GO  
BEGIN TRANSACTION;  
GO  
IF @@TRANCOUNT = 0  
BEGIN  
    SELECT FirstName, MiddleName   
    FROM Person.Person WHERE LastName = 'Adams';  
    ROLLBACK TRANSACTION;  
    PRINT N'Rolling back the transaction two times would cause an error.';  
END;  
ROLLBACK TRANSACTION;  
PRINT N'Rolled back the transaction.';  
GO  
/*  
Rolled back the transaction.  
*/

Ejemplos: Almacenamiento de datos SQL de Azure yAlmacenamiento de datos paralelos

En el siguiente ejemplo, BEGIN y END definen un conjunto de instrucciones SQL que se ejecutan juntas. Si no se incluye el bloque BEGIN...END, en el ejemplo siguiente se estará en un bucle continuo.
-- Uses AdventureWorks  

DECLARE @Iteration Integer = 0  
WHILE @Iteration <10  
BEGIN  
    SELECT FirstName, MiddleName   
    FROM dbo.DimCustomer WHERE LastName = 'Adams';  
SET @Iteration += 1  
END;

Comentarios

Publicar un comentario

Entradas más populares de este blog

Roles de un Administrador de base de datos

Imagen
Roles de un Administrador de base de datos Un  administrador de bases de datos  (también conocido como  DBA , en inglés  database administrator ) es aquel profesional que administra las tecnologías de la información y la comunicación, siendo responsable de los aspectos técnicos, tecnológicos, científicos, inteligencia de negocios y legales de bases de datos, y de la calidad de datos. Sus tareas incluyen las siguientes: Implementar, dar soporte y gestionar bases de datos corporativas. Crear y configurar bases de datos relacionales. Ser responsables de la integridad de los datos y la disponibilidad. Diseñar, desplegar y monitorizar servidores de bases de datos. Diseñar la distribución de los datos y las soluciones de almacenamiento. Garantizar la seguridad de las bases de datos, realizar copias de seguridad y llevar a cabo la recuperación de desastres. Planificar e implementar el aprovisionamiento de los datos y aplicaciones. Diseñar  planes de contingencia . Diseñar y cr
Leer más

Alertas

Imagen
ALERTAS  Alertas y notificaciones de base de datos: Introducción: Las tecnologías de notificaciones y alertas se definen como interfaces usadas fundamentalmente en procedimientos de atención multitarea, los mismos proporcionan información actualizada y valiosa al usuario de manera efectiva. Su objetivo es mostrar un mensaje de modo que mejore la capacidad de los usuarios para distinguir los eventos que ocurren y tienen prioridad alta. Este tipo de tecnología permite la recolección de datos sobre eventos de interés que ocurren o están por ocurrir, producidos en cualquier esfera dentro del ámbito de trabajo, para ser emitidas posteriormente tomando como canal de comunicación fundamental el correo electrónico, manteniendo constantemente informados a personas y áreas que interactúen con el mismo. Con el resultado y conclusión de la presente investigación se logra entender el funcionamiento básico de un sistema de notificaciones y alertas, tomando como referencia diversos
Leer más