Transacción: Colección de
operaciones que forman una única
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. Está delimitada por
constructoras como begintransaction
y end-transaction (SQL-Server).
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. Está delimitada por constructoras como
begintransaction y end-transaction (SQL-Server).
Pero también se considera...
Unidad lógica de integridad
¯ Unidad lógica de concurrencia
¯ Unidad lógica de recuperación
El programa se ejecuta como una pieza atómica. O se
ejecutan todas las operaciones que componen la
transacción, o no se realiza ninguna.
Propiedades de una Transacción (ACID).
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.
• Consistencia: En cierto caso el requisito de
consistencia es que la suma de A y B no sea alterada al
ejecutar la transacción. Sin el requisito de consistencia,
¡la transacción podría crear o destruir dinero! Se puede
comprobar fácilmente que si una base de datos es
consistente antes de ejecutar una transacción, sigue
siéndolo después de ejecutar dicha transacción.
Atomicidad: supóngase que justo antes de ejecutar la
transacción Ti los valores de las cuentas A y B son de
1.000 € y de 2.000 €, respectivamente. Supóngase
ahora que durante la ejecución de la transacción Ti se
produce un fallo que impide que dicha transacción
finalice con éxito su ejecución. La información de las
modificaciones realizadas por la transacción guardada
en disco es suficiente para permitir a la base de datos
reconstruir dichas modificaciones cuando el sistema se
reinicie después del fallo.
Durabilidad: una vez que se completa con éxito la
ejecución de una transacción, y después de comunicar
al usuario que inició la transacción que se ha realizado
la transferencia de fondos, no debe suceder que un
fallo en el sistema produzca la pérdida de datos
correspondientes a dicha transferencia. La propiedad
de durabilidad asegura que, una vez que se completa
con éxito una transacción, persisten todas las
modificaciones realizadas en la base de datos, incluso
si hay un fallo en el sistema después de completarse la
ejecución de dicha transacción.
Aislamiento: incluso si se aseguran las propiedades de
consistencia y de atomicidad para cada transacción, si
varias transacciones se ejecutan concurrentemente, se
pueden entrelazar sus operaciones de un modo no
deseado, produciendo un estado inconsistente.
Atomicity : Una Transacción (Tx) se ejecuta
completamente ó de otra manera se eliminan los
cambios parciales realizados.
Begin Transaction - Programa - End Transaction
CONCEPTO DE TRANSACCIONES DE
SISTEMAS
Un sistema de procesamiento de transacciones
(TPS por sus siglas en inglés) es un tipo de sistema
de información. Un TPS recolecta, almacena,
modifica y recupera toda la información generada
por las transacciones producidas en una
organización. Una transacción es un evento que
genera o modifica los datos que se encuentran
eventualmente almacenados en un sistema de
información.
La base de un programa transaccional está en que gestiona
los datos de forma que estos deben ser siempre consistentes
(por ejemplo, si se realiza un pago con una tarjeta
electrónica, la cantidad de dinero de la cuenta sobre la que
realiza el cargo debe disminuir en la misma cantidad que la
cuenta que recibe el pago, de no ser así, ninguna de las dos
cuentas se modificará), si durante el transcurso de una
transacción ocurriese algún error, el TPS debe poder
deshacer las operaciones realizadas hasta ese instante.
Si bien este tipo de integridad es que debe presentar
cualquier operación de procesamiento de
transacciones por lotes, es particularmente importante
para el procesamiento de transacciones on-line:
Sin las debidas precauciones, en una transacción
podría ocurrir una reserva doble.
Características de los sistemas
de procesamiento de
transacciones
Respuesta rápida
En este tipo de sistemas resulta crítico que exista un
rendimiento elevado con tiempos de respuesta cortos. Una
empresa no puede permitirse tener clientes esperando por
una respuesta del SPT; el tiempo total transcurrido desde
que se inicia la transacción hasta que se produce la salida
correspondiente debe ser del orden de unos pocos
segundos o menos.
Fiabilidad
Muchas organizaciones basan su fiabilidad en los SPT; un
fallo en un SPT afectará negativamente a las operaciones o
incluso parará totalmente el negocio. Para que un SPT sea
efectivo, su tasa de fallos debe ser muy baja. En caso de fallo
de un SPT, debe existir algún mecanismo que permita una
recuperación rápida y precisa del sistema. Esto convierte en
esencial la existencia procedimientos de copia de seguridad
y de recuperación ante fallos correctamente diseñados.
Inflexibilidad
Un SPT requiere que todas las transacciones sean
procesadas exactamente de la misma forma,
independientemente del usuario, el cliente o la hora del
día. Si los SPT fuesen flexibles, habría entonces demasiadas
posibilidades de ejecutar operaciones no estándar. Por
ejemplo, una aerolínea comercial necesita aceptar de forma
consistente reservas de vuelos realizadas por un gran
número de agencias de viaje distintas; aceptar distintos
datos de transacción de cada agencia de viajes supondría un
problema.
Procesamiento controlado
El procesamiento en un SPT debe apoyar las
operaciones de la organización. Por ejemplo, si una
organización establece roles y responsabilidades para
determinados empleados, el SPT debe entonces
mantener y reforzar este requisito.
PLANIFICACION Y
RECUPERABILIDAD
Clasificación de planificaciones:
_ Recuperables: una vez que una T ha confirmado nunca
será necesario deshacerla.
_ No recuperables: no satisfacen la condición anterior (
no se deben permitir).
_ Una planificación P es recuperable si ninguna transacción
T de P se confirma antes de que se hayan confirmado todas
las transacciones T’ que han escrito un elemento que T lee
posteriormente.
La anterior es no recuperable porque T2 se confirma
antes de que lo haga T1; si T1 fallara se dificultaría la
recuperación
Se transformaría en una planificación recuperable si
posponemos la confirmación de T2 hasta después de la
de T1
Puede ocurrir el fenómeno de restauración en
cascada
(Aborto en cascada): una transacción no confirmada
debe deshacerse porque leyó un elemento de una
transacción fallida.
(Aborto en cascada): una transacción no
confirmada debe deshacerse porque leyó un
elemento de una transacción fallida.
Planificación sin abortos en cascada: si toda
transacción de la planificación solo lee elementos
escritos por transacciones confirmadas. Por ejemplo:
Planificaciones estrictas: las transacciones no pueden leer ni escribir de un
gránulo x hasta que se confirme la última transacción que escribió x (fáciles de
recuperar).
SERIABILIDAD DE TRANSACCIONES
La serialización es el criterio de lo correcto, para el control de la concurrencia. Un
conjunto entrelazado de transacciones es correcto si es serializable. Es decir si produce
el mismo resultado mediante la ejecución en serie de las mismas transacciones. Dado
un conjunto de transacciones entrelazadas, cualquier ejecución de esas transacciones
se dice que es una calendarización (“scheduling).
Esta es la ejecución de esta aseveración:
1. - Las transacciones individuales son tomadas como
correctas es decir, se da por hecho que transforman un
estado correcto de la base de datos en otro estado
correcto.
2. - Por lo tanto también es correcta la ejecución de
una transacción a la vez en cualquier orden serial y se
dice en cualquier orden serial debido a que las
transacciones individuales son consideradas
independientes entre sí.
3. - Por lo tanto una ejecución intercalada es correcta
cuando equivale a una ejecución serial, es decir cuando
es seriable.
Seriabilidad por conflicto
Eliminar conflictos entre dos o mas transacciones
Operaciones sobre los mismos datos en mas de una transacción *
Tipos de operaciones:
T1: lectura y T2: lectura
No hay conflicto
T1: lectura y T2: escritura ó T1: escritura y T2: lectura
Conflicto: hay que respetar el orden
T1: escritura y T2: escritura
Conflicto: el orden afecta al valor final de la BD
Se dice que hay conflicto cuando se consideran operaciones
sobre los mismos datos en dos transacciones diferentes
Un plan de ejecución se puede transformar en otro cambiando de
orden las instrucciones y manteniendo la seriabilidad
Todos estos planes son equivalentes al plan secuencial.
Seriabilidad por visión
Se basa en definir una regla de equivalencia menos
estricta que la de conflicto.
Pero basándose solo en las operaciones de lectura y
escritura.
Se puede considerar como un refinamiento de la
equivalencia por conflicto.
Pruebas de seriabilidad
Hacer la prueba de seriabilidad después de ejecutar el plan
es un poco tarde.
El objetivo es desarrollar un protocolo de control de
concurrencia que asegure la seriabilidad.
No suele analizar el grafo de precedencia.
Lo habitual es imponer restricciones que aseguren la
seriabilidad del plan.
Las pruebas sirven para ayudar a comprender los
protocolos de control de concurrencia
SOPORTE DE LAS
TRANSACCIONES EN SQL
Definición de transacciones SQL
_ Inicio de transacción: es implícito en SQL
_ Final de transacción: en SQL
_ COMMIT
_ ROLLBACK
_ Características de una transacción SQL
_ mediante SET TRANSACTION
_ se puede fijar
_ Modo de acceso
_ Tamaño del área de diagnóstico
_ Nivel de aislamiento
Violaciones posibles con
aislamiento < SERIALIZABLE:
Lectura sucia: una transacción T1 puede leer la
actualización de T2 que todavía no ha confirmado.
Si T2 aborta, T1 habría leído un dato incorrecto.
_ Lectura no reproducible: Si una transacción lee
dos veces un mismo dato y en medio una
transacción lo modifica, verá valores diferentes
para el dato.
_ Fantasmas: una transacción T1 puede leer un
conjunto de filas (que cumplan una condición). Si
una transacción T2 inserta una fila que también
cumple la condición y T1 se repite verá un
fantasma, una fila que previamente no existía.
EJEMPLO DE TRANSACCION EN
SQL
EXEC SQL WHENEVER SQLERROR GOTO UNDO;
EXEC SQL SET TRANSACTION
READ WRITE
ISOLATION LEVEL SERIALIZABLE;
EXEC SQL INSERT INTO EMPLEADO
(ENOMBRE,DNO,SALARIO)
VALUES (‘Miguel López’,’2’,35000);
EXEC SQL UPDATE EMPLEDO SET
SALARIO=SALARIO*1,1 WHERE
DNO=2;
EXEC SQL COMMIT;
FINAL:
UNDO:
EXEC SQL ROLLBACK
CONCLUSION
Anteriormente una transacción era complicada de
hacer ya que se realizaba por medio manual, es decir
haciendo transferencias de forma real de una cuenta a
otra; hoy en día SQL nos ofrece la forma de realizar
transferencias vía electrónica o virtual dichas
operaciones son fáciles y confiables siempre y cuando
se cumpla con las propiedades ACID y se manejen los
comandos ROLLBACK y COMMIT adecuadamente.