1

BASES DE DATOS

TRANSACCIONES
Transaccin (transaction): Grupo de operaciones de base de datos combinadas en una unidad lgica de
trabajo que se confirma o se deshace completamente. Una transaccin es atmica, coherente, aislada y
duradera.
Atmica: Deben ejecutarse todas las modificaciones de los datos de la transaccin o ninguna de ellas.
Coherente: debe dejar la base de datos en un estado coherente despues de que se realiza o falla.
Aislada: no interactua ni entra en conflicto con ninguna otra transaccion.
Duradera: los efectos de su trabajo son permanentes solo al finalizar su ejecucin
independientemente de lo sucedido inmediatamente despues de su conclusin.


CONTROL DE LA CONCURRENCIA.

La mayora de las BD es multiusuario, por lo tanto debe tener un control de la concurrencia. En algn
momento, ms de un usuario accede a un determinado registro al mismo tiempo. El problema principal
es la modificacin de registros.

Casos que generan inconsistencias:

- Actualizacin perdida (lost update)
- Dependencia de una transaccin no cometida (uncommitted transaction)
- Inconsistencia de anlisis (analysis inconsistence)

Debido a lo anterior, es necesario un mecanismo que evite que otros usuarios actualicen informacin
mientras alguno est realizando esta tarea.

Uno de los mecanismos ms utilizados es el "bloqueo". El control de concurrencia usualmente se hace a
travs de mecanismos de bloqueo.

Dependiendo del DBMS existen diversos tipos de bloqueos:

Bloquear la BD.
Bloquear la tabla o el archivo.
Bloquear el registro.
Bloquear el dato (data tem).

Para realizar el bloqueo se debe conocer:

- Operacin a realizar: modificacin.
- Lmites de la transaccin (inicio y fin).

2
Se debe tratar de bloquear lo mnimo, lo ms recomendable es a nivel de registro o dato. Si se bloquea a
nivel de tabla se degrada el rendimiento de la BD (no se puede hacer ninguna otra operacin sobre la
tabla). Si se bloquea la BD, se da la sensacin de inestabilidad.

Hoy da, el mecanismo de bloqueo ms utilizado en DBMSs se denomina "two-phase commit protocol"
(protocolo de commit de dos fases).

Es importante notar que el bloqueo tiene un problema (similar a cualquier algoritmo de regin crtica): se
pueden producir deadlocks (abrazo mortal).

DEADLOCK (Abrazo Mortal): Se produce cuando dos o mas usuarios para ejecutar una transaccin
bloquean algn dato o registro que es necesario para otro usuario y a su vez necesitan para completar la
transaccin un dato que est bloqueado por otro usuario, el resultado es que ninguno de los involucrados
podr completar su transaccin, esto es similar a cuando dos vehculos se encuentran frente a frente en
una calle estrecha y ninguno de los conductores est dispuesto a retroceder, el resultado es una espera
infinita.

Para controlar este problema se utiliza un mecanismo (monitor) que detecta los sujetos que estn
actuando en la BD y con que objetos, y conocida esa informacin le da privilegio a uno de los dos (por
ejemplo: el que usa ms CPU). De este modo, es posible abortar la transaccin con menor privilegio.

El deadlock no se puede evitar, en vez de intentar evitarlo se deben tener mecanismos para deshacerlo.

RECUPERACION

Se debe contar con elementos que permitan recuperar la informacin cuando se pierde, se ingresa un
dato errneo, etc.
Un DBMS debe, normalmente, proveer las siguientes facilidades:
Respaldo peridico: El DBMS debe proveer un sistema de " vaciado" que produzca una copia de la BD, la
que debe almacenarse en algn lugar seguro. La periodicidad depende de la importancia de los datos.
Bitcora de las Transacciones: Contiene un " diario" de todas las transacciones realizadas sobre los
registros con los principales datos que se usaron en la transaccin. Contiene los cambios que se han
producido, teniendo una imagen del registro antes de ser modificado y una imagen del registro despus
de ser modificado (Archivo pre- imagen y post- imagen).
Facilidad para los Check Points: El DBMS detiene el proceso en forma manual por comando o en forma
automtica, "sincroniza" la BD con la bitcora de transacciones y genera un registro en un archivo, en
donde guarda la informacin sobre el estado de la BD a una determinada transaccin.

Una transaccin exitosa produce cambios en la BD, en cuyo caso se llama transaccin cometida
(committed). Si la transaccin no es exitosa se dice que ha sido abortada, y en cuyo caso no se han de
producir cambios en la BD. Para mantener la integridad de la transaccin, el DBMS debe proveer
facilidades para que el usuario o el programador de aplicacin defina los lmites de la transaccin.

La administracin de la recuperacin corresponde a un modelo en que se restaura la BD a un estado
correcto cuando se produce algn error para lo que existen los siguientes procedimientos de
recuperacin :
3

Restore/Rerun (reprocesamiento). El cual implica un reprocesamiento completo de las transacciones del
da , es decir, se toman todas las transacciones que se han realizado y se ejecutan de nuevo (se reprocesa
despus del ltimo backup correcto). Este procedimiento presenta las siguientes desventajas :

Tiempo de reproceso.
No hay garanta de que la secuencia de transacciones que se vayan a realizar se ejecuten en el mismo
orden como fueron ejecutadas originalmente ( por ej:, sistemas de inventario donde hay una transaccin
que ingres material y otra que sac, y pueden ejecutarse al revs, lo que origina otros errores : no hay
nada en bodega por que no se ha ingresado antes).
Al ejecutarse este proceso se difiere el procesamiento de las transacciones nuevas.

Backward o Rollback (recuperacin hacia atrs): Este procedimiento elimina los cambios que se
producen en la BD por efecto de una transaccin que ha sido abortada. Se pierden todos los cambios que
se han hecho en una BD producto de la ejecucin parcial de una transaccin .

Forward o Rollforward (recuperacin hacia adelante): Este procedimiento considera la copia ms
temprana de la BD, es decir, la BD sin cambio y el archivo de transacciones post-imagen el que contiene
las transacciones exitosas y con ello la BD es restaurada a un estado ms adelante. Es diferente al Restore
/ Rerun, por que ste ejecuta la transaccin (toma de la bitcora de transacciones las que se han de
ejecutar y las ejecuta), en cambio el Rollforward toma el resultado de las transacciones (desde un archivo
de respaldo, post-imagen).
De este modo, el Rollforward tiene algunas similitudes con el Restore / Rerun, pero es ms rpido debido
a :

No repite el tiempo de proceso.
Requiere slo las imgenes posteriores o post- imagen
No presenta problemas con la secuencia de transacciones .

La recuperacin se produce, evidentemente, segn los tipos de fallas.

Tipos de fallas en una B.D.

Transacciones abortadas: Una transaccin abortada se puede producir por ingreso errneo de datos, falla
del HW, error humano o por un dead- lock . Al producirse estas situaciones, el procedimiento de
recuperacin a utilizar es el Rollback.

Datos incorrectos: La situacin es ms compleja porque no se tiene como saber si un dato es o no
correcto (puede que se sepa muy tarde). En este caso se pueden adoptar las siguientes formas para
recuperar:

a) Si el error es descubierto rpidamente se puede aplicar una recuperacin Rollback, asegurndose que
las consecuencias del error sean corregidas (se conocen las transacciones ejecutadas con posterioridad a
la del dato incorrecto).

4
b) Usar transacciones compensatorias. Si se descubren errores que no pueden recuperarse (por ejemplo
se produce una cadena de eventos por una transaccin y se descubre mucho tiempo despus el error).

c) Restaurar desde el ltimo Checkpoint. (Rollforward o Restore / Rerun dependiendo del caso)


Fallas de sistema : Se pueden producir por problemas de energa, por error de operacin, por problemas
en las comunicaciones, por fallas del sw. Cuando se produce este tipo de fallas, generalmente existen
transacciones en proceso. Se podra aplicar un procedimiento RollBack, y si la falla afecta a muchas
transacciones y existen problemas con la informacin obtenida se deber utilizar una recuperacin desde
el ltimo Checkpoint, utilizando una recuperacin RollForward.

Es factible pensar que la BD se puede recuperar, en general ante cualquier falla. Siempre se tendrn
respaldo de la BD, registros de Checkpoint y los procedimientos para recuperar segn el caso.

Muchos de estos procedimientos se manejan desde el SW y otros son automticos (por ejemplo:
Checkpoint y Rollback de transacciones uncommitted).

SELECT NOM_ALU, SEXO
FROM ALUMNO
WHERE NOM_ALU LIKE "?????";

SELECT NOM_ALU, SEXO
FROM ALUMNO
WHERE DAY(FECHA_NAC)=DAY(NOW()) AND MONTH(FECHA_NAC)=MONTH(NOW());

SELECT NOM_ALU, SEXO
FROM ALUMNO
WHERE MONTH(FECHA_NAC)=MONTH(NOW());

SELECT ALUMNO.NOM_ALU & ' ' & ALUMNO.AP_ALU & ' ' & ALUMNO.AM_ALU AS NOMBRE, format
(DATEDIFF("m", ALUMNO.FECHA_NAC , now ())/12,'d' ) +1 AS EDAD
FROM ALUMNO;

SELECT NOM_ALU, SEXO
FROM ALUMNO
WHERE NOM_ALU LIKE 'J*'
ORDER BY SEXO DESC , NOM_ALU;

SELECT ALUMNO.NOM_ALU & ' ' & ALUMNO.AP_ALU & ' ' & ALUMNO.AM_ALU AS NOMBRE , 'ALUMNO'
AS TIPO
FROM ALUMNO;
UNION SELECT PROFESOR.NOM_EMP & ' ' & PROFESOR.AP_EMP & ' ' & PROFESOR.AM_EMP AS
NOMBRE , 'PROFESOR' AS TIPO
FROM PROFESOR;

5
SELECT NOM_ALUMNO, NUM_SEMESTRE, NUM_GRUPO
FROM ALUMNO, HISTORIAL

PRODUCTO CARTESIANO EXTENDIDO CONSULTAS DE RESTRICCION

FILTRO.

WHERE ALUMNO, NUM_CTA = HISTORIAL.NUM_CTA
SELECT NUM_ALU, NUM_SEMESTRE, NUM_GRUPO

FROM ALUMNO INNER JOIN HISTORIAL
ON ALUMNO.NUM_CTA = HISTORIAL.NUM_CTA

FROM ALUMNO LEFT JOIN HISTORIAL.

FROM ALUMNO RIGTH JOIN HISTORIAL..