Transacciones en MySQL (1)

8/15/2019 Transacciones en MySQL (1)

1/26

TransaccionesTransacciones

Administración de BDAdministración de BDIng. Aida Avila In

g. Aida Avila


2/26

Definición de transaccionesDefinición de transacciones

Las transacciones son un concepto fundamental de todoslos sistemas de bases de datos. El punto esencial de una

transacción es su capacidad para empaquetar variospasos en una sola operación “todo o nada”. Los estadosintermedios entre los pasos no son visibles para otrastransacciones concurrentes, y si ocurre alguna falla queimpida que se complete la transacción, entonces ningunode los pasos se ejecuta y no se afecta la base de datosen absoluto.


3/26

Estructura Estructura

Transacciones Planas

Es una secuencia de operaciones primitivas entre lasmarcas BEGIN y END

Transacciones Anidadas

Las operaciones de las transacciones pueden ser en si

mismas una transacción


4/26

Propiedades deseables en lasPropiedades deseables en lastransacciones (ACID).transacciones (ACID).

ACID son las siglas de Atomicity, Consistency, Isolation y Durability Atomicidad,

Consistencia, Aislamiento , Durabilidad!"

Atomicidad. Es la propiedad #ue asegura #ue la operación se $a reali%ado o no, ypor lo tanto ante un &allo del sistema no puede #uedar a medias"

Consistencia. Esta propiedad esta ligada a la integridad re&erencial, es decir solo sepueden escribir datos v'lidos respetando los tipos de datos declarados y la integridad

re&erencial"

Aislamiento. Asegura #ue una operación no puede a&ectar a otras" Con esto seasegura #ue varias transacciones sobre la misma in&ormación sean independientes y

no generen ning(n tipo de error"

Durabilidad. Cuando se completa una transacción con )*ito los cambios se vuelvenpermanentes"

El e+emplo cl'sico de transacción es una trans&erencia bancaria, en la #ue #uitamos

saldo a una cuenta y lo aadimos en otra" -i no somo capaces de abonar el dinero

en la cuenta de destino, no debemos #uitarlo de la cuenta de origen"


5/26

Estado de una transacciónEstado de una transacción

Activa el estado inicial. la transacción permanece en este estado mientras seest' e+ecutando" Parcialmente comprometida despu)s de e+ecutarse la (ltima instrucción" !allida despu)s de descubrir #ue la e+ecución normal ya no puede llevarse acabo" Abortada despu)s del retroceso de la transacción y $aber restaurado la basede datos su estado anterior al inicio de la

transacción" Dos opciones despu)s de #ue $aya abortado/

0 reiniciar la transacción

0 cancelar la transacción Comprometida, despu)s de terminar con )*ito"


6/26

El control de accesos concurrentes y espec1&icamente de transacciones

concurrentes es mane+ado por un módulo del dbms llamado 2sc$eduler2"

Es importante recordar #ue muc$os de los datos de la base no se

encuentran nada m's en disco, sino tambien en los bu&&ers de memoria,de a$1 #ue el sc$eduler interact(a con ellos y en su de&ecto solicita la

lectura de los datos del disco"

Control de concurrencia Control de concurrencia


7/26

Conceptos relacionados con el control de concurrencia"

#eriali$abilidad"%n plan seriali$able implica &ue el plan es correcto

3 De+a la base de datos en un estado consistente

3 El intercalamiento es apropiado y resultar' en un estado como si las

transacciones &ueran e+ecutadas secuencialmente, pero ser' e&iciente

debido a la e+ecución concurrente"

'a seriali$abilidad es difcil de verificar3 El intercalamiento de las operaciones ocurre en el sistema operativo a

trav)s de un plani&icador

3 Di&1cil determinar de antemano como las operaciones ser'n intercaladas

Enfo&ue prctico"4rotocolos asegurando la seriali%abilidad a trav)s del uso de Candados loc5s!



8/26

En general, re&or%ar el aislamiento a trav)s de la e*clusión mutua! entre

transacciones con&lictivas"

En particular, evitar los problemas de/

3 Actuali%ación perdida

3 Actuali%ación temporal

3 -uma incorrecta

Propósito del Control dePropósito del Control de

Concurrencia"Concurrencia"


9/26

Algoritmos de control de concurrencia"

Los algoritmos de control de concurrencia deben sincroni%ar la

e+ecución de transacciones concurrentes ba+o el criterio de

correctitud" La consistencia entre transacciones se garanti%a

mediante el aislamiento de las mismas"



10/26


Control de concurrencia optimista

Los algoritmos de control de concurrencia discutidos antes son por naturale%a

pesimistas" En otras palabras, ellos asumen #ue los con&lictos entre

transacciones son muy &recuentes y no permiten el acceso a un dato si e*iste unatransacción con&lictiva #ue acceda al mismo dato" As1, la e+ecución de cual#uier

operación de una transacción sigue la secuencia de &ases/ validación 6!, lectura

7!, cómputo C! y escritura 8!" Los algoritmos optimistas, por otra parte,

retrasan la &ase de validación +usto antes de la &ase de escritura" De esta manera,

una operación sometida a un despac$ador optimista nunca es retrasada"


11/26

Control de Concurrencia Basado en 'oc*"

En los algoritmos basados en candados, las transacciones indican sus intenciones

solicitando candados al despac$ador llamado el administrador de candados! Los

candados son de lectura , tambi)n llamados compartidos, o de escritura , tambi)n

llamados e*clusivos"

En sistemas basados en candados, el despac$ador es un administrador de

candados " El administrador de transacciones le pasa al administrador de

candados la operación sobre la base de datos lectura o escritura! e in&ormación

asociada, como por e+emplo el elemento de datos #ue es accedido y el

identi&icador de la transacción #ue est' enviando la operación a la base de datos"



12/26

%so de tablas InnoDB%so de tablas InnoDB El servidor de bases de datos +,#-' soporta distintos tipos de tablas

tales como I#A+ +,I#A+ InnoDB , BDB (Ber*ele, Database). De stosInnoDB es el tipo de tabla ms importante (despus del tipopredeterminado +,I#A+) , merece una atención especial.

'as tablas del tipo InnoDB estn estructuradas de forma distinta &ue+,I#A+ ,a &ue se almacenan en un sólo arc/ivo en lugar de tres , susprincipales caractersticas son &ue permite traba0ar con transacciones ,definir reglas de integridad referencial.

las tablas &ue soportan transacciones como es el caso de InnoDB sonmuc/o ms seguras , fciles de recuperar si se produce alg1n fallo en elservidor ,a &ue las consultas se e0ecutan o no en su totalidad. Por otraparte las transacciones pueden /acer &ue las consultas tarden ms tiempoen e0ecutarse.


13/26

Para asegurarnos &ue tenemos soporte para el tipo de tablas InnoDBpodemos e0ecutar la siguiente sentencia"

m,s&l2 #345 6A7IAB'E# 'I8E 9:innodb:9;

'a variable ms importante es por supuesto /ave


14/26

4TA"

Estas dos consultas deben traba0ar bien pero &ue sucede siocurre alg1n imprevisto , se cae el sistema despus de &ue

se e0ecuta la primer consulta pero la segunda a1n no se /acompletadoF. 'a persona@ tendr una cantidad de dineroremovida de su cuenta , creer &ue /a reali$ado su pago sinembargo la persona estar enfadada puesto &ue pensar &ueno se le /a depositado el dinero &ue le deben. En este e0emplotan sencillo se ilustra la necesidad de &ue las consultas seane0ecutadas de manera con0unta o en su caso &ue no see0ecute ninguna de ellas. Es a&u donde las transaccionestoman un papel mu, importante.


15/26

PA#4# PA7A 7EA'IGA7PA#4# PA7A 7EA'IGA7

T7A#ACCI4E#T7A#ACCI4E# Iniciar una transacción con el uso de la sentencia BEHI.

Actuali$ar insertar o eliminar registros en la base de datos.

#i se &uieren /acer los cambios a la base de datos se debe completar latransacción con el uso de la sentencia C4++IT. nicamente cuando seprocesa un C4++IT los cambios /ec/os por las consultas sernpermanentes.

#i sucede alg1n problema podemos /acer uso de la sentencia74''BAC8 para cancelar los cambios &ue /an sido reali$ados por lasconsultas &ue /an sido e0ecutadas /asta el momento.


16/26

C7EA7 TAB'A DE TIP4 InnoDBC7EA7 TAB'A DE TIP4 InnoDB

m,s&l2 C7EATE TAB'E innotest (campo IT 4T %'' P7I+A7= 8E=)T=PE > InnoDB;-uer, 48 J roKs affected (J.@J sec)

m,s&l2 I#E7T IT4 innotest 6A'%E#(@); -uer, 48 @ roK affected (J.JL sec)

m,s&l2 I#E7T IT4 innotest 6A'%E#(); -uer, 48 @ roK affected (J.J@ sec)

m,s&l2 I#E7T IT4 innotest 6A'%E#(M); -uer, 48 @ roK affected (J.JN sec)

m,s&l2 #E'ECT O !74+ innotest;


17/26

C4+4 %#A7 'A# T7A#ACCI4E#C4+4 %#A7 'A# T7A#ACCI4E# m,s&l2 BEHI;

-uer, 48 J roKs affected (J.J@ sec)

m,s&l2 I#E7T IT4 innotest 6A'%E#(N);-uer, 48 @ roK affected (J.JJ sec)


#i en este momento e0ecutamos un 74''BAC8 la transacción no sercompletada , los cambios reali$ados sobre la tabla no tendrn efecto.

m,s&l2 74''BAC8;-uer, 48 J roKs affected (J.J sec)



18/26

A/ora vamos a ver &ue sucede si perdemos la coneQión al servidor antes de

&ue la transacción sea completada.

m,s&l2 BEHI;

-uer, 48 J roKs affected (J.JJ sec)

m,s&l2 I#E7T IT4 innotest 6A'%E#(N);-uer, 48 @ roK affected (J.JJ sec)


m,s&l2 ERIT; B,e

Cuando obtengamos de nuevo la coneQión podemos verificar &ue elregistro no se insertó ,a &ue la transacción no fue completada.


19/26


A/ora vamos a repetir la sentencia I#E7T e0ecutada anteriormente pero

/aremos un C4++IT antes de perder la coneQión al servidor al salir delmonitor de +,#-'.

m,s&l2 BEHI;


m,s&l2 I#E7T IT4 innotest 6A'%E#(N);

-uer, 48 @ roK affected (J.JJ sec)

m,s&l2 C4++IT;

-uer, 48 J roKs affected (J.J sec)

m,s&l2 ERIT;

B,e


20/26

%na ve$ &ue /acemos un C4++IT la transacción es completada , todas lassentencias #-' &ue /an sido e0ecutadas previamente afectan de manerapermanente a las tablas de la base de datos.

#E'ECT O !74+ innotest;


21/26

Por defecto las tablas InnoDB e0ecutan una lectura consistente(consistent read ). Esto significa &ue cuando una sentencia #E'ECT ese0ecutada +,#-' regresa los valores presentes en la base de datos

/asta la transacción ms reciente &ue /a sido completada. #i algunatransacción est en progreso los cambios /ec/os por alguna sentenciaI#E7T o %PDATE no sern refle0ados. #in embargo eQiste unaeQcepción" las transacciones abiertas si pueden ver sus propioscambios. Para demostrar esto necesitamos establecer dos coneQionesal servidor +,#-'.

Primero agregaremos un registro dentro de una transacción con laprimera coneQión (ID SN)"

'ecturas Consistentes'ecturas Consistentes


22/26

m,s&l2 BEHI;


m,s&l2 I#E7T IT4 innotest 6A'%E#(S);-uer, 48 @ roK affected (J.JJ sec)

A/ora desde la segunda coneQión (ID SS) consultamos los datos de nuestra

tabla. m,s&l2 #E'ECT O !74+ innotest;

Como se puede observar el registro &ue /emos insertado desde la @ra.coneQión no es regresado puesto &ue forma parte de una transacción &ueno /a sido completada. A/ora desde la @ra. coneQión e0ecutamos la

misma consulta #E'ECT.



23/26

Despus de completar la transacción con una sentencia C4++IT en la @ra.coneQión podremos verificar &ue desde la da. coneQión los cambios ,ason visibles.



24/26

4tro E0emplo4tro E0emplo

En el e0emplo anterior /emos usado 1nicamente sentencias I#E7T sinembargo sucede lo mismo con sentencias %PDATE o DE'ETE.

6amos a crear una sencilla tabla llamada ventas &ue sea del tipo InnoDB.

m,s&l2 C7EATE TAB'E ventas( ?2 id IT 4T %'' P7I+A7= 8E= A%T4 InnoDB;

Insertamos un registro.

m,s&l2 I#E7T IT4 ventas 6A'%E#(J9Hansito marinela9M);-uer, 48 @ roK affected (J.@ sec)

m,s&l2 #E'ECT O !74+ ventas;


25/26

A/ora vamos a iniciar una transacción con la sentencia BEHI.

m,s&l2 BEHI;


Actuali$amos el registro.

3m,s&l2 %PDATE ventas #ET cantidad>N 53E7E id>@;-uer, 48 @ roK affected (J.J sec)

'neas correspondientes" @ Cambiadas" @ Avisos" J

6erificamos &ue los cambios /an sucedido.

3m,s&l2 #E'ECT O !74+ ventas;

#i &ueremos des/acer los cambios entonces e0ecutamos un74''BAC8.

3m,s&l2 74''BAC8;-uer, 48 J roKs affected (J.J sec)


26/26

6erificamos &ue se des/icieron los cambios.


6amos a actuali$ar el registro usando otra transacción.

3m,s&l2 BEHI;-uer, 48 J roKs affected (J.JJ sec)

3m,s&l2 %PDATE ventas #ET cantidad> 53E7E id>@;

-uer, 48 @ roK affected (J.JJ sec)'neas correspondientes" @ Cambiadas" @ Avisos" J


6amos a confirmar &ue deseamos los cambios.

3m,s&l2 C4++IT;-uer, 48 J roKs affected (J.JS sec)

En este momento los cambios son permanentes , definitivos.


Documents

Transacciones en MySQL (1)