Administración de Transacciones - del tema 1 al 4
34
3.1 Transacciones 3.2 Tipos de fallas 3.3 Recuperación 3.4 Concurrencia
-
Upload
mayito-pdg -
Category
Documents
-
view
3.193 -
download
0
Transcript of Administración de Transacciones - del tema 1 al 4
3.1 Transacciones
3.2 Tipos de fallas
3.3 Recuperación
3.4 Concurrencia
Definición: Una transacción en un Sistema
de Gestión de Bases de Datos (SGBD), es
un conjunto de órdenes que se ejecutan
formando una unidad de trabajo, es decir,
en forma indivisible o atómica.
1.- Acciones lógica:
• Introducir una nueva factura.
• Dar de alta a un cliente.
• Registrar un cobro.
• Cambiar dirección de un proveedor.
2.- Acciones física: (instrucción insert, delete, update)
• Agrega un registro en la tabla factura.
• Modifica un campo de un registro de la tabla clientes.
• Elimina varias filas de las tablas.
• Etc.
Las transacciones nos permiten
agrupar los pasos fiscos cuando se
hacen modificaciones a una base de
datos.
Commit: Esta instrucción es la que
confirma la transacción para
modificación de los datos en la base de
datos.
Rollback: Esta instrucción es la que
anula cualquier modificación realizada
en la base de datos.
conjunto de características necesarias
para que una serie de instrucciones
puedan ser consideradas como
una transacción
• ATOMICIDAD
• CONSISTENCIA
• AISLAMIENTO
• DURABILIDAD
Begin transaction
Insert
Update
Delete
If error
Rollback
Else
commit
Atomicidad: Es la propiedad que asegura que la
operación se ha realizado o no, que se realiza con
commit para confirmar o rollback para deshacer.
Consistencia: Es la propiedad que asegura que solo
se emplea aquello que solo se pueda acabar. Por lo
tanto solo se ejecutan aquellas operaciones que no
van a romper las reglas y directrices de la integridad
de la base de datos.
Aislamiento: es la propiedad que asegura que una
operación no pueda afectar a otras. Esto asegura que
la realización de 2 transacciones sobre la misma
información sean independientes y no generen ningún
tipo de error.
Durabilidad: Es la propiedad que asegura que una
ves realizada la transacción, esta persistirá y no se
podrá deshacer aunque falle el sistema .
Normalmente en una base de datos de Microsoft las
transacciones son explicitas, lo que quiere decir que
debemos poner begin transaction
Transacción explicita
Begin transaction
Update tabla…
Insert into tabla…
Delete from tabla…
Commit o rollback
En algunas otras bases de datos como Oracle en donde
las transacciones se consideran implícitas, por que se
considera que todas las instrucciones pertenecen a la
transacción.
Transacciones implisitas
Update tabla…
Insert into tabla…
Delete from tabla…
Commit o rollback
La estructura de una transacción usualmente viene dada según el modelo de la transacción, estas pueden ser planas (simples) o anidadas.
Transacciones planas:
Consisten en una secuencia de operaciones primitivas encerradas entre las palabras clave BEGIN y END. Por ejemplo:
BEGIN _TRANSACTION Reservación
....
END.
Consiste en tener transacciones que dependen de otras, estas transacciones están incluidas dentro de otras de un nivel superior y se las conoce como sub-transacciones. La transacción de nivel superior puede producir hijos (sub-transacciones) que hagan más fácil la programación del sistema y mejoras del desempeño.
En las transacciones anidadas las operaciones de una transacción pueden ser así mismo otras transacciones. Por ejemplo:
BEGIN _TRANSACTION Reservación
..........
BEGIN _TRANSACTION Vuelo
........
END.(Vuelo)......
BEGIN _TRANSACTION Hotel
........
END
......
END.
Los siguientes son los aspectos más importantes relacionadoscon el procesamiento de transacciones:
• Modelo de estructura de transacciones:
Es importante considerar si las transacciones son planas oanidadas.
• Consistencia de la base de datos interna:
Los algoritmos de control de datos tienen que satisfacer lasrestricciones de integridad cuando una transacción pretendehacer un compromiso.
• Protocolos de confiabilidad:
En transacciones distribuidas es necesario introducir medios decomunicación entre los diferentes nodos de una red paragarantizar la atomicidad de las transacciones.
• Algoritmos de control de concurrencia:
Deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre
• Protocolos de control de replicas:
Se refiere a como garantizar la consistencia mutua de datos
replicados.
El procesamiento de transacciones básicamente consiste en
una serie de modificaciones (transacciones) a un determinado
recurso del sistema (por ejemplo una base de datos) y en
donde se define un punto de inicio y un punto de terminación
que define un bloque entre el conjunto de operaciones que son
realizadas.
Dentro de este proceso en bloque los demás usuarios no
pueden modificar nada hasta que no se presente un estado
estable de los datos, esto ocasiona inconsistencia temporal y
conflictos. Para evitar lo anterior se implementan dos maneras
diferentes:
1.-Ejecución de transacciones serializadas
2.- Ejecución de transacciones calendarizadas
• 1.-Ejecutar transacciones serializadas:
Es un sistema que permite el procesamiento de
transacciones en forma secuencial o serializado
dándole una secuencia a cada transacción, este
proceso reduce el rendimiento del sistema, pero tiene
como ventaja que el proceso de sincronización es
más sencillo.
• 2- Ejecutar transacciones calendarizadas:
Permite el proceso de transacciones asignándoles
tiempos de procesamiento el cual permite incrementar
el rendimiento del sistema ya que se ejecuta un
máximo de procesos en forma concurrente y no a
través de una serie. La ventaja es que a un mismo
tiempo de reloj se pueden hacer dos operaciones,
aunque el proceso de sincronización es mas
complicado.
1.- Fase de lectura: Cuerpo de la transacción donde
se copian datos desde la base de datos, copias que
pueden ser actualizadas pero sin copiar a la base de
datos.
2.Fase de validación: Se comprueba que no existan
conflictos.
3.- Fase de escritura: Si no existen conflictos se
instalan lo cambios en la base de datos.
Fin de
transacción
Ejecución de
una
transacción
Inicio de
transacción
Base de datos en un
estado consiente
La base de datos
puede estar
temporalmente en un
estado inconsistente
durante la ejecución
Base de datos en un
estado consiente
enlace de video
http://www.youtube.com/watch?v=4Yku4epDHDQ&feature
=related
• Una falla local: sólo afecta a la transacción en
la cual se presentó esa falla, como por
ejemplo un ?overflow?. Tales fallas son
recuperables mediante los mecanismos de
soporte de la instrucción COMMIT.
• Una falla global: Afecta a varias transacciones
(y con mucha probabilidad a la totalidad) de
las transacciones que se estaban efectuando
en e momento de la falla. Tales fallas se
dividen en dos tipos:
1.-Fallas del sistema: (por ejemplo
interrupciones del suministro de electricidad) las
cuales afectan a todas las transacciones que se
están realizando pero no dañan físicamente a la
base de datos.
2.-Falla de los medios de almacenamiento: (por
ejemplo, un aterrizaje de cabezas en el disco),
las cuales si causan daños a la base de datos o
a una porción de ella, y afectan al menos a las
transacciones que están utilizando esa porción.
• 1.- Fallos locales a la transacción, que detecta el propio código dela
aplicación.
Responsabilidad del Programador
• 2. Fallos locales a la transacción, que no detecta el propio códigode la
aplicación.
El SGBD fuerza Rollback de la Transacción
• 3. Fallos del sistema que no dañan la BD.
"Recuperación en caliente“: consulta del diario para deshacer yrehacer
Transacciones.
• 4. Fallos del sistema que dañan la BD.
"Recuperación de emergencia“: Copia de Seguridad +Recuperaciónen base
al diario.
• 5. Error Fatal (Pérdida de archivo(s) de diario)
"Recuperación en frío“: Copia de Seguridad. Pérdida de Ultimas
La recuperabilidad significa que, si se da algún error en los datos, hay un bug de programa ó de hardware, el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el daño se causara. Las actividades de recuperación incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de daño ó pérdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del área en antelación a un desastre anticipado. La recuperación es una de las tareas más importantes de los DBA’s.
Si el DBA (o el administrador) intentan implementar un plan de recuperación de bases de datos sin pruebas de recuperación, no existe la certeza de que los respaldos sean del todo válidos. En la práctica, los respaldos de la mayoría de los RDBMSs son raramente válidos si no se hacen pruebas exhaustivas que aseguren que no ha habido errores humanos ó bugs que pudieran haber corrompido los respaldos.
Las pruebas de recuperación consisten en la
restauración de los datos, después se aplican las bitácoras a esos datos para restaurar la base de datos y llevarla a un estado consistente en un tiempo y momento determinados. Alternativamente se puede restaurar una base de datos que se encuentra fuera de línea sustituyendo con una copia de la base de datos.
La primera cuestión a tener en cuenta ante la recuperación de una base de datos es el nivel de recuperación q desea para es te proceso es necesario arrancando el servidor con la opción
mysqld skip- grant – tables
después de de restaurar las tablas es necesario indicar al servidor que cargue las tabla de concesión y las empiece a usar mediante la sentencia
mysqld nombre_b_d < fichero
Otra forma de recuperación en My SQL es el uso de los ficheros log de actualización q contiene la sintaxis SQl de la construcción de todas la tablas de la base de datos como ficheros de entrada para el comando mysql.
mysqld nombre_b_d < log 1
mysqld nombre_b_d < log 2
mysqld nombre_b_d < log 3
Se debe de utilizar la opcion
mysqld one –data base nombre_b_d < log 1
mysqld one –data base nombre_b_d < log 2
mysqld one –data base nombre_b_d < log 3
Los archivos log de actualización hace el seguimiento de las consultas que modifican a la base de datos que contiene un registro para cada consulta.
Estos se pueden usar de entrada para MySQL para restaurar
Sentencia:
mysqld -- log – update [=nombre_ruta]
Los sistemas de bases de datos, según el número de usuarios que pueden utilizarlos de forma concurrente, se clasifican en sistemas monousuario y multiusuario
Varios usuarios pueden usar un mismo equipo a la vez gracias a la multiprogramación: el computador puede procesar al mismo tiempo varias transacciones Si el equipo tiene varias CPU, es posible el
procesamiento simultáneo (paralelo) de transacciones Si sólo hay una CPU, el SO de multiprogramación
reparte el tiempo de CPU entre las transacciones: ejecución concurrente intercalada
Introducción
• Aumentar la productividad: número de transacciones ejecutadas por minuto.
• Aumentar la utilización de la CPU y Control del disco.
• Reduciendo el tiempo medio de respuesta de transacciones
El objetivo fundamental del control de concurrencia de base de datos es garantizar que la ejecución concurrente de transacciones no resulte en una perdida de consistencia de la misma.
Dos sentencias UPDATE que actualicen un mismo producto decrementando el stock del mismo en una unidad podrían terminar en que una de ellas no se realizase. Si pensamos en un UPDATE como una secuencia de una lectura y una escritura, puede que ambos UPDATE hagan la lectura, por ejemplo, de un stock de 10, y después las escrituras, decrementando ese dato, quedando el resultado en 9, mientras que lo correcto es un resultado de 8.
Una forma de controlar la concurrencia es hacer que cada transacción deba adquirir un derecho de acceso exclusivo a cada fragmento de datos que necesite modificar. A estos “derechos” se les denomina bloqueos.
