CONCEPTO SOBRE

TRANSACCIONES

Transaccin: Coleccin de operaciones que
forman una nica unidad lgica de trabajo en
una BD realizada por una o ms sentencias
SQL estrechamente relacionadas.
Una transaccin es una unidad de la
ejecucin 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).
INTRODUCCION
Una transaccin es una unidad de la ejecucin 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 tambin se considera...
Unidad lgica de integridad
Unidad lgica de concurrencia
Unidad lgica de recuperacin
El programa se ejecuta como una pieza atmica. O se
ejecutan todas las operaciones que componen la
transaccin, o no se realiza ninguna.
En SQL
xito. Fracaso
Begin transacction.
Instruccin -1 .
Instruccin-2.
....
Commit work.
Begin transacction.
Instruccin -1 .
Instruccin-2.
....
Rollback work.
Propiedades de una Transaccin
(ACID).
Una unidad lgica de trabajo debe exhibir
cuatro propiedades, conocidas como
propiedades ACID (atomicidad,
coherencia, aislamiento y durabilidad),
para ser calificacada como transaccin.
Atomicity : Una Transaccin (Tx) se
ejecuta completamente de otra manera
se eliminan los cambios parciales
realizados.
Begin Transaction - Programa - End
Transaction
Responsable: el mtodo de recuperacin,
de no completar todas las operaciones,
devuelve la BD a su estado anterior a
empezar esa T (rollback).
Conservacin de la
Consistencia: Asegura que los datos que
estamos viendo
no cambian (por otros usuarios) hasta que
acabemos la transaccin.
Despus de terminar una Transaccin la
Base de datos no viola ninguna de sus
reglas: valores obligatorios, claves
nicas,etc.
Responsable: los programadores
mediante la definicin 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 transaccin en ejecucin no puede revelar sus
resultados a otras transacciones concurrentes antes de
finalizar.
Ms aun, si varias transacciones, se ejecutan
concurrentemente, los resultados deben ser los mismos
que si ellas se hubieran ejecutado secuencialmente.
Esto se conoce como seriabilidad debido a que su
resultado es la capacidad de volver a cargar los datos
iniciales y reproducir una serie de transacciones para
finalizar con los datos en el mismo estado en que
estaban despus de realizar transacciones originales.
Responsable: el mtodo de
concurrencia: mecanismos, reglas,
protocolos
Durabilidad: Si el sistema falla no debe
permitir que se pierdan las operaciones
realizadas por Tx ya confirmadas.
Responsable: el mtodo o gestor de
recuperacin.
Estados y operaciones de una
transaccin
CONCEPTO DE
TRANSACCIONES DE SISTEMAS
Un sistema de procesamiento de
transacciones (TPS por sus siglas en ingls) es
un tipo de sistema de informacin. Un TPS
recolecta, almacena, modifica y recupera toda la
informacin generada por las transacciones
producidas en una organizacin. Una
transaccin es un evento que genera o modifica
los datos que se encuentran eventualmente
almacenados en un sistema de informacin.
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 electrnica, 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
transaccin ocurriese algn error, el TPS debe
poder deshacer las operaciones realizadas
hasta ese instante.
Si bien este tipo de integridad es que debe
presentar cualquier operacin de
procesamiento de transacciones por lotes,
es particularmente importante para el
procesamiento de transacciones on-line:
Sin las debidas precauciones, en una
transaccin podra ocurrir una reserva
doble.
Caractersticas de los sistemas
de procesamiento de
transacciones
Respuesta rpida
En este tipo de sistemas resulta crtico 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 transaccin 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
algn mecanismo que permita una recuperacin
rpida y precisa del sistema. Esto convierte en
esencial la existencia procedimientos de copia
de seguridad y de recuperacin ante fallos
correctamente diseados.
Inflexibilidad
Un SPT requiere que todas las transacciones
sean procesadas exactamente de la misma
forma, independientemente del usuario, el
cliente o la hora del da. Si los SPT fuesen
flexibles, habra entonces demasiadas
posibilidades de ejecutar operaciones no
estndar. Por ejemplo, una aerolnea comercial
necesita aceptar de forma consistente reservas
de vuelos realizadas por un gran nmero de
agencias de viaje distintas; aceptar distintos
datos de transaccin de cada agencia de viajes
supondra un problema.
Procesamiento controlado
El procesamiento en un SPT debe apoyar
las operaciones de la organizacin. Por
ejemplo, si una organizacin establece
roles y responsabilidades para
determinados empleados, el SPT debe
entonces mantener y reforzar este
requisito.
PLANIFICACION Y
RECUPERABILIDAD
Clasificacin de planificaciones:
_ Recuperables: una vez que una T ha
confirmado nunca ser necesario deshacerla.
_ No recuperables: no satisfacen la condicin
anterior ( no se deben permitir).
_ Una planificacin P es recuperable si ninguna
transaccin 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 dificultara la recuperacin
Se transformara en una planificacin
recuperable si posponemos la
confirmacin de T2 hasta despus de la
de T1
Puede ocurrir el fenmeno de
restauracin en cascada
(Aborto en cascada): una transaccin no
confirmada debe deshacerse porque ley
un elemento de una transaccin fallida.



(Aborto en cascada): una transaccin no confirmada
debe deshacerse porque ley un elemento de una
transaccin fallida.



Planificacin sin abortos en cascada: si
toda transaccin de la planificacin solo
lee elementos escritos por transacciones
confirmadas. Por ejemplo:
Planificaciones estrictas: las transacciones no pueden leer ni escribir de un
grnulo x hasta que se confirme la ltima transaccin que escribi x (fciles de
recuperar).
SERIABILIDAD DE TRANSACCIONES
La serializacin 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 ejecucin
en serie de las mismas transacciones. Dado un conjunto de transacciones
entrelazadas, cualquier ejecucin de esas transacciones se dice que es
una calendarizacin (scheduling)
Esta es la ejecucin de esta aseveracin:
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 tambin es correcta la ejecucin de una
transaccin 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 ejecucin intercalada es correcta
cuando equivale a una ejecucin serial, es decir cuando
es seriable.
Es la propiedad que garantiza que un
plan de ejecucin concurrente es
equivalente al secuencial.
Formas de planificar la seriabilidad: 1)
por conflicto 2) por visin
Por simplicidad solo se consideran las
operaciones de lectura y escritura. No
se consideran las operaciones de
clculo sobre los datos obtenidos.
Seriabilidad por conflicto
Eliminar conflictos entre dos o mas transacciones
Operaciones sobre los mismos datos en mas de una
transaccin *
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 ejecucin se puede transformar en otro
cambiando de orden las instrucciones y manteniendo la
seriabilidad
Todos estos planes son equivalentes al plan secuencial.
Seriabilidad por visin
Se basa en definir una regla de
equivalencia menos estricta que la de
conflicto.
Pero basndose 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 despus 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
Definicin de transacciones SQL
_ Inicio de transaccin: es implcito en SQL
_ Final de transaccin: en SQL
_ COMMIT
_ ROLLBACK
_ Caractersticas de una transaccin SQL
_ mediante SET TRANSACTION
_ se puede fijar
_ Modo de acceso
_ Tamao del rea de diagnstico
_ Nivel de aislamiento
Caractersticas de una transaccin
especificables en SQL:
Violaciones posibles con
aislamiento < SERIALIZABLE:
_ Lectura sucia: una transaccin T1 puede leer la
actualizacin de T2 que todava no ha confirmado. Si T2
aborta, T1 habra ledo un dato incorrecto.
_ Lectura no reproducible: Si una transaccin lee dos
veces un mismo dato y en medio una transaccin lo
modifica, ver valores diferentes para el dato.
_ Fantasmas: una transaccin T1 puede leer un
conjunto de filas (que cumplan una condicin). Si una
transaccin T2 inserta una fila que tambin cumple la
condicin y T1 se repite ver un fantasma, una fila que
previamente no exista.
Violaciones posibles segn el nivel
de aislamiento
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 Lpez,2,35000);
EXEC SQL UPDATE EMPLEDO SET SALARIO=SALARIO*1,1
WHERE
DNO=2;
EXEC SQL COMMIT;
FINAL:
UNDO:
EXEC SQL ROLLBACK
GRACIAS
POR
SU
ATENCION