Transacciones

Administracin de BD
Ing. Aida Avila

Definicin de transacciones
Las transacciones son un concepto fundamental de todos
los sistemas de bases de datos. El punto esencial de una
transaccin es su capacidad para empaquetar varios
pasos en una sola operacin todo o nada. Los estados
intermedios entre los pasos no son visibles para otras
transacciones concurrentes, y si ocurre alguna falla que
impida que se complete la transaccin, entonces ninguno
de los pasos se ejecuta y no se afecta la base de datos
en absoluto.

Estructura
Transacciones Planas
Es una secuencia de operaciones primitivas entre las
marcas BEGIN y END

Transacciones Anidadas
Las operaciones de las transacciones pueden ser en si
mismas una transaccin

Propiedades deseables en las

transacciones (ACID).
ACID son las siglas de Atomicity, Consistency, Isolation y Durability (Atomicidad,
Consistencia, Aislamiento , Durabilidad).
Atomicidad. Es la propiedad que asegura que la operacin se ha realizado o no, y
por lo tanto ante un fallo del sistema no puede quedar a medias.
Consistencia. Esta propiedad esta ligada a la integridad referencial, es decir solo se
pueden escribir datos vlidos respetando los tipos de datos declarados y la integridad
referencial.
Aislamiento. Asegura que una operacin no puede afectar a otras. Con esto se
asegura que varias transacciones sobre la misma informacin sean independientes y
no generen ningn tipo de error.
Durabilidad. Cuando se completa una transaccin con xito los cambios se vuelven
permanentes.
El ejemplo clsico de transaccin es una transferencia bancaria, en la que quitamos
saldo a una cuenta y lo aadimos en otra. Si no somo capaces de abonar el dinero
en la cuenta de destino, no debemos quitarlo de la cuenta de origen.

Estado de una transaccin

Activa, el estado inicial; la transaccin permanece en este estado mientras se
est ejecutando.

Parcialmente comprometida, despus de ejecutarse la ltima instruccin.

Fallida, despus de descubrir que la ejecucin normal ya no puede llevarse a

cabo.

Abortada, despus del retroceso de la transaccin y haber restaurado la base

de datos su estado anterior al inicio de la
transaccin. Dos opciones despus de que haya abortado:
reiniciar la transaccin
cancelar la transaccin

Comprometida, despus de terminar con xito.

Control de concurrencia
El control de accesos concurrentes y especficamente de transacciones
concurrentes es manejado por un mdulo del dbms llamado "scheduler".
Es importante recordar que muchos de los datos de la base no se
encuentran nada ms en disco, sino tambien en los buffers de memoria,
de ah que el scheduler interacta con ellos y en su defecto solicita la
lectura de los datos del disco.

Control de concurrencia
Conceptos relacionados con el control de concurrencia:
Serializabilidad:
Un plan serializable implica que el plan es correcto
Deja la base de datos en un estado consistente
El intercalamiento es apropiado y resultar en un estado como si las
transacciones fueran ejecutadas secuencialmente, pero ser eficiente
debido a la ejecucin concurrente.
La serializabilidad es difcil de verificar
El intercalamiento de las operaciones ocurre en el sistema operativo a
travs de un planificador
Difcil determinar de antemano como las operaciones sern intercaladas
Enfoque prctico:
Protocolos asegurando la serializabilidad a travs del uso de Candados (locks)

Propsito del Control de

Concurrencia:
En general, reforzar el aislamiento (a travs de la exclusin mutua) entre
transacciones conflictivas.
En particular, evitar los problemas de:
Actualizacin perdida
Actualizacin temporal
Suma incorrecta

Control de concurrencia

Algoritmos de control de concurrencia:

Los algoritmos de control de concurrencia deben sincronizar la
ejecucin de transacciones concurrentes bajo el criterio de
correctitud. La consistencia entre transacciones se garantiza
mediante el aislamiento de las mismas.

Control de concurrencia
Control de concurrencia optimista
Los algoritmos de control de concurrencia discutidos antes son por naturaleza
pesimistas. En otras palabras, ellos asumen que los conflictos entre
transacciones son muy frecuentes y no permiten el acceso a un dato si existe una
transaccin conflictiva que acceda al mismo dato. As, la ejecucin de cualquier
operacin de una transaccin sigue la secuencia de fases: validacin (V), lectura
(R), cmputo (C) y escritura (W). Los algoritmos optimistas, por otra parte,
retrasan la fase de validacin justo antes de la fase de escritura. De esta manera,
una operacin sometida a un despachador optimista nunca es retrasada.

Control de concurrencia
Control de Concurrencia Basado en Lock:
En los algoritmos basados en candados, las transacciones indican sus intenciones
solicitando candados al despachador (llamado el administrador de candados) Los
candados son de lectura , tambin llamados compartidos, o de escritura , tambin
llamados exclusivos.
En sistemas basados en candados, el despachador es un administrador de
candados . El administrador de transacciones le pasa al administrador de
candados la operacin sobre la base de datos (lectura o escritura) e informacin
asociada, como por ejemplo el elemento de datos que es accedido y el
identificador de la transaccin que est enviando la operacin a la base de datos.

Uso de tablas InnoDB

El servidor de bases de datos MySQL soporta distintos tipos de tablas,

tales como ISAM, MyISAM, InnoDB y BDB (Berkeley Database). De stos,
InnoDB es el tipo de tabla ms importante (despus del tipo
predeterminado, MyISAM), y merece una atencin especial.

Las tablas del tipo InnoDB estn estructuradas de forma distinta que
MyISAM, ya que se almacenan en un slo archivo en lugar de tres, y sus
principales caractersticas son que permite trabajar con transacciones, y
definir reglas de integridad referencial.

las tablas que soportan transacciones, como es el caso de InnoDB, son

mucho ms seguras y fciles de recuperar si se produce algn fallo en el
servidor, ya que las consultas se ejecutan o no en su totalidad. Por otra
parte, las transacciones pueden hacer que las consultas tarden ms tiempo
en ejecutarse.

Para asegurarnos que tenemos soporte para el tipo de tablas InnoDB

podemos ejecutar la siguiente sentencia:

mysql> SHOW VARIABLES LIKE '%innodb%';

La variable ms importante es por supuesto have_innodb que tiene el valor
YES.
En efecto, una de las principales caractersticas de las tablas del tipo InnoDB
es que pueden trabajar con transacciones, o sentencias SQL que son
agrupadas como una sola. Un ejemplo tpico de esto es una transaccin
bancaria. Por ejemplo, si una cantidad de dinero es transferida de la
cuenta de una persona a otra, se requerirn por lo menos dos consultas:
UPDATE cuentas SET balance = balance - cantidad_transferida WHERE
cliente = persona1;
UPDATE cuentas SET balance = balance + cantidad_transferida WHERE
cliente = persona2;

NOTA:

Estas dos consultas deben trabajar bien, pero que sucede si

ocurre algn imprevisto y "se cae" el sistema despus de que
se ejecuta la primer consulta, pero la segunda an no se ha
completado?. La persona1 tendr una cantidad de dinero
removida de su cuenta, y creer que ha realizado su pago, sin
embargo, la persona2 estar enfadada puesto que pensar que
no se le ha depositado el dinero que le deben. En este ejemplo
tan sencillo se ilustra la necesidad de que las consultas sean
ejecutadas de manera conjunta, o en su caso, que no se
ejecute ninguna de ellas. Es aqu donde las transacciones
toman un papel muy importante.

PASOS PARA REALIZAR

TRANSACCIONES

Iniciar una transaccin con el uso de la sentencia BEGIN.

Actualizar, insertar o eliminar registros en la base de datos.

Si se quieren hacer los cambios a la base de datos, se debe completar la

transaccin con el uso de la sentencia COMMIT. nicamente cuando se
procesa un COMMIT los cambios hechos por las consultas sern
permanentes.

Si sucede algn problema, podemos hacer uso de la sentencia

ROLLBACK para cancelar los cambios que han sido realizados por las
consultas que han sido ejecutadas hasta el momento.

CREAR TABLA DE TIPO InnoDB

mysql> CREATE TABLE innotest (campo INT NOT NULL PRIMARY KEY)
TYPE = InnoDB;
Query OK, 0 rows affected (0.10 sec)

mysql> INSERT INTO innotest VALUES(1);

Query OK, 1 row affected (0.08 sec)

mysql> INSERT INTO innotest VALUES(2);

Query OK, 1 row affected (0.01 sec)

mysql> INSERT INTO innotest VALUES(3);

Query OK, 1 row affected (0.04 sec)

mysql> SELECT * FROM innotest;

COMO USAR LAS TRANSACCIONES

mysql> BEGIN;
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO innotest VALUES(4);

Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM innotest;

Si en este momento ejecutamos un ROLLBACK, la transaccin no ser

completada, y los cambios realizados sobre la tabla no tendrn efecto.

mysql> ROLLBACK;
Query OK, 0 rows affected (0.06 sec)

mysql> SELECT * FROM innotest;

Ahora vamos a ver que sucede si perdemos la conexin al servidor antes de

que la transaccin sea completada.

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO innotest VALUES(4);

Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM innotest;

mysql> EXIT; Bye

Cuando obtengamos de nuevo la conexin, podemos verificar que el

registro no se insert, ya que la transaccin no fue completada.

mysql> SELECT * FROM innotest;

Ahora vamos a repetir la sentencia INSERT ejecutada anteriormente, pero

haremos un COMMIT antes de perder la conexin al servidor al salir del
monitor de MySQL.

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO innotest VALUES(4);

Query OK, 1 row affected (0.00 sec)

mysql> COMMIT;
Query OK, 0 rows affected (0.02 sec)

mysql> EXIT;
Bye

Una vez que hacemos un COMMIT, la transaccin es completada, y todas las

sentencias SQL que han sido ejecutadas previamente afectan de manera
permanente a las tablas de la base de datos.

SELECT * FROM innotest;

Lecturas Consistentes
Por defecto, 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 transaccin ms reciente que ha sido completada. Si alguna
transaccin est en progreso, los cambios hechos por alguna sentencia
INSERT o UPDATE no sern reflejados. Sin embargo, existe una
excepcin: las transacciones abiertas si pueden ver sus propios
cambios. Para demostrar esto, necesitamos establecer dos conexiones
al servidor MySQL.
Primero agregaremos un registro dentro de una transaccin con la
primera conexin (ID 524):

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO innotest VALUES(5);

Query OK, 1 row affected (0.00 sec)

Ahora, desde la segunda conexin (ID 525) consultamos los datos de nuestra
tabla.

mysql> SELECT * FROM innotest;

Como se puede observar, el registro que hemos insertado desde la 1ra.

conexin no es regresado puesto que forma parte de una transaccin que
no ha sido completada. Ahora, desde la 1ra. conexin ejecutamos la
misma consulta SELECT.

mysql> SELECT * FROM innotest;

Despus de completar la transaccin con una sentencia COMMIT en la 1ra.

conexin podremos verificar que desde la 2da. conexin los cambios ya
son visibles.

mysql> SELECT * FROM innotest;

Otro Ejemplo
En el ejemplo anterior hemos usado nicamente sentencias INSERT, sin
embargo, sucede lo mismo con sentencias UPDATE o DELETE.
Vamos a crear una sencilla tabla llamada ventas que sea del tipo InnoDB.
mysql> CREATE TABLE ventas(
-> id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
-> producto VARCHAR(30) NOT NULL,
-> cantidad TINYINT NOT NULL) TYPE = InnoDB;

Insertamos un registro.
mysql> INSERT INTO ventas VALUES(0,'Gansito marinela',3);
Query OK, 1 row affected (0.16 sec)
mysql> SELECT * FROM ventas;

Ahora vamos a iniciar una transaccin con la sentencia BEGIN.

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)
Actualizamos el registro.
mysql> UPDATE ventas SET cantidad=4 WHERE id=1;
Query OK, 1 row affected (0.07 sec)

Lneas correspondientes: 1 Cambiadas: 1 Avisos: 0

Verificamos que los cambios han sucedido.
mysql> SELECT * FROM ventas;
Si queremos deshacer los cambios, entonces ejecutamos un
ROLLBACK.
mysql> ROLLBACK;
Query OK, 0 rows affected (0.06 sec)

Verificamos que se deshicieron los cambios.

mysql> SELECT * FROM ventas;
Vamos a actualizar el registro usando otra transaccin.
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql> UPDATE ventas SET cantidad=2 WHERE id=1;
Query OK, 1 row affected (0.00 sec)
Lneas correspondientes: 1 Cambiadas: 1 Avisos: 0
mysql> SELECT * FROM ventas;
Vamos a confirmar que deseamos los cambios.
mysql> COMMIT;
Query OK, 0 rows affected (0.05 sec)
En este momento los cambios son permanentes y definitivos.
mysql> SELECT * FROM ventas;