Transacciones
Se llama transacción a una colección de operaciones que
forman una unidad lógica de trabajo en una BD realizada por una o más
sentencias SQL estrechamente relacionadas.
Una transacción es una unidad de la ejecución de un programa
que lee y escribe datos a y desde la Base de Datos. Puede consistir en varias
operaciones de acceso a la base de datos. Una Transacción está delimitada por
instrucciones de inicio transacción y fin transacción (la transacción consiste
en todas las operaciones que se ejecutan entre inicio transacción y fin
transacción).
Las transacciones agrupan una serie de operaciones de manera
que es posible garantizar la integridad del resultado final. O todas las
operaciones se ejecutan con éxito y se confirman (se escriben en la base de
datos), o toda la transacción se considera no realizada. La acción de cancelar
una transacción se denomina deshacer la transacción. Deshacer una transacción
permite anular los cambios y recuperar el estado de la base de datos previo a
la transacción.
Propiedades de la Transacción
Una unidad lógica de trabajo debe exhibir cuatro
propiedades, conocidas como propiedades ACID (atomicidad, coherencia,
aislamiento y durabilidad), para ser calificada como transacción.
Atomicity: Una Transacción (Tx) se ejecuta completamente o
de otra manera se eliminan los cambios parciales realizados.
Begin Transaction - Programa - End Transaction
Responsable: El método de recuperación, de no completar
todas las operaciones, devuelve la BD a su estado anterior a empezar esa Tx
rollback).
Coherencia: Asegura que los datos que observamos no cambian
(por otros usuarios) hasta que acabemos la Transacción.
Después de terminar una Transacción la Base de datos no
viola ninguna de sus reglas: valores obligatorios, claves únicas, etc.
Responsable: los programadores mediante la definición
adecuada de la integridad referencial: check, triggers, primary key, foreign
key,…
Aislamiento: Los efectos de una Tx no son visibles a otros
usuarios mientras no se confirmen.
Una Transacción en ejecución no puede revelar sus resultados
a otras transacciones concurrentes antes de finalizar.
Durabilidad: Si el sistema falla no debe permitir que se
pierdan las operaciones realizadas por Tx ya confirmadas.
Funcionamiento de una transacción:
En este diagrama se puede observar que el principio de O se
hace bien o no se hace se mantiene.
Control de
transacciones en Oracle
Inicio de transacción
Cuando no hay ya una transacción en progreso, y se ejecuta
una sentencia LDD o LMD.
Cada sentencia LDD es tratada como una transacción N No
existe sentencia de tipo BEGIN TRANSACTION
Fin de transacción
COMMIT: Finaliza la transacción actual y hace permanentes
(confirma) los cambios realizados
ROLLBACK: Finaliza la transacción actual y deshace los
cambios realizados. En caso de que la transacción no se complete o haya un
error.
Sentencia COMMIT
Una sentencia COMMIT marca el final de una transacción
correcta, implícita o definida por el usuario. COMMIT hace que todas las
modificaciones efectuadas sobre los datos desde el inicio de la transacción
sean parte permanente de la base de datos, y además, libera los recursos
mantenidos por la conexión. Su sintaxis es la siguiente:
COMMIT COMMENT 'mensaje' | FORCE 'texto']
COMMENT sirve para comentar la transacción en un máximo 255
caracteres.
FORCE fuera de modo manual una transacción dudosa y es de
uso exclusivo en sistemas distribuidos de base de datos.
Una vez que el COMMIT t se presenta en una transacción y
asegura que todo salió bien, entonces los usuario puede utilizar las tablas y
registros que al empezar la transacción se bloquearon.
Sentencia SAVEPOINT
Esta sentencia permite crear un punto de restauración dentro
de una transacción, es decir, un punto al que podremos retroceder deshaciendo
todo lo hecho deshaciendo todo lo hecho desde él en adelante. Su sintaxis es la
siguiente:
SAVEPOINT nombrePuntoRestauración;
Sentencia ROLLBACK
Señala el final sin éxito de una transacción, elimina todas
las modificaciones de datos realizadas desde el inicio de la transacción y
también libera los recursos que retiene la transacción. Su sintaxis es la
siguiente:
ROLLBACK [WORK] [TO SAVEPOINT nombre PuntoRestauración |
FORCE 'texto'];
Lo que básicamente hace este código es regresar todo a como
estaba al momento de iniciar la transacción esta función es de gran utilidad ya
que en caso de un error sea el que sea, mantiene los valores congruentes.
Grados de consistencia
Consistencia es un término más amplio que el de integridad.
Podría definirse como la coherencia entre todos los datos de la base de datos.
Cuando se pierde la integridad también se pierde la consistencia. Pero la
consistencia también puede perderse por razones de funcionamiento.
·
Una transacción finalizada (confirmada
parcialmente) puede no confirmarse definitivamente (consistencia).
·
Si se confirma definitivamente el sistema
asegura la persistencia de los cambios que ha efectuado en la base de datos.
·
Si se anula los cambios que ha efectuado son
deshechos.
·
La ejecución de una transacción debe conducir a
un estado de la base de datos consistente (que cumple todas las restricciones
de integridad definidas).
·
Si se confirma definitivamente el sistema
asegura la persistencia de los cambios que ha efectuado en la base de datos.
·
Si se anula los cambios que ha efectuado son
deshechos.
Una transacción que termina con éxito se dice que está
comprometida (commited), una transacción que haya sido comprometida llevará a
la base de datos a un nuevo estado consistente que debe permanecer incluso si
hay un fallo en el sistema. En cualquier momento una transacción sólo puede
estar en uno de los siguientes estados:
·
Activa (Active): el estado inicial; la
transacción permanece en este estado durante su ejecución.
·
Parcialmente comprometida (Uncommited): Después
de ejecutarse la última transacción.
·
Fallida (Failed): tras descubrir que no se puede
continuar la ejecución normal.
·
Abortada (Rolled Back): después de haber
retrocedido la transacción y restablecido la base de datos a su estado anterior
al comienzo de la transacción.
·
Comprometida (Commited): tras completarse con
éxito.
Niveles de
aislamiento
Las transacciones
especifican un nivel de aislamiento que define el grado en que se debe aislar
una transacción de las modificaciones de recursos o datos realizadas por otras
transacciones. Los niveles de aislamiento se describen en cuanto a los efectos
secundarios de la simultaneidad que se permiten, como las lecturas desfasadas o
ficticias.
Control de los niveles de aislamiento de
transacción:
·
Controla si se 11realizan bloqueos cuando se leen los datos y qué tipos
de bloqueos se solicitan.
·
Duración de los bloqueos de lectura.
·
Si una operación de lectura que hace referencia a filas modificadas por
otra transacción:
o
Se bloquea hasta que se libera el bloqueo exclusivo de la fila.
o
Recupera la versión confirmada de la fila que existía en el momento en
el que empezó la instrucción o la transacción.
o
Lee la modificación de los datos no confirmados.
El nivel de
aislamiento para una sesión SQL establece el comportamiento de los bloqueos
para las instrucciones SQL.
Se usa el
aislamiento en:
Lectura sucia. Las sentencias SELECT son
ejecutadas sin realizar bloqueos, pero podría usarse una versión anterior de un
registro. Por lo tanto, las lecturas no son consistentes al usar este nivel de aislamiento.
·
Lectura no repetible. Una transacción
vuelve a leer datos que previamente había leído y encuentra que han sido
modificados o eliminados por una transacción cursada.
·
Lectura fantasma. Una transacción vuelve a ejecutar una consulta,
devolviendo un conjunto de registros que satisfacen una condición de búsqueda y
encuentra que otros registro que satisfacen la condición han sido insertadas
por otra transacción cursada.
COMMIT Y ROLLBACK
Ejemplo
básico en MySQL precio del dolar con respecto al peso 1995 al 2012.
CREATE TABLE IF NOT EXISTS dolar ( fecha
DATE, precio DECIMAL (8,4), PRIMARY KEY (fecha)) ENGINE = InnoDB DEFAULT
CHARSET=latin1;
Lecturas
consistentes
Por
default, las tablas InnoDB ejecutan una lectura consistente (consistent read). Esto significa que cuando una sentencia SELECT es ejecutada,
MySQL regresa los valores presentes en la base de datos hasta la transacción
más reciente que ha sido completada.
Si
alguna transacción está en progreso, los cambios hechos por alguna sentencia DELETE, INSERT o UPDATE no serán reflejados. Sin embargo,
existe una excepción: las transacciones abiertas si pueden ver sus propios
cambios. Para demostrar esto, necesitamos establecer dos conexiones al servidor
MySQL.
No hay comentarios:
Publicar un comentario