Está en la página 1de 36

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 (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
Para que lo anterior quede mejor comprendido crearemos unas tablas
utilizando los principales comandos de las transacciones.
Hasta aqu todo va normal o hasta donde
nosotros sabemos ahora bien que pasa si
anteponemos el comando BEGIN antes de
seguir agregando datos.
Con el comando COMMIT damos por hecho que los
cambios que se efectuaran en la tabla sern
permanentes y as de esta forma garantizamos que
todos los datos que anexemos a nuestra tabla entraran
todos o ninguno.

También podría gustarte