Your SlideShare is downloading. ×
0
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Gestion de transacciones
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Gestion de transacciones

3,660

Published on

Cuestiones

Cuestiones

1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total Views
3,660
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
111
Comments
1
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. UNIVERSIDAD TECNICA PARTICULAR DE LOJA <ul><li>ECC </li></ul><ul><li>Base de Datos Avanzada </li></ul><ul><li>GESTION DE TRANSACCIONES </li></ul><ul><li>Por: Patricia Flores </li></ul>
  • 2. <ul><li>Transacción es una secuencia de operaciones de acceso a la base de datos que constituyen una unidad lógica de ejecución estás pueden ser coherentes o incoherentes, pero su respuesta darán un resultado acorde con lo solicitado. </li></ul>
  • 3. <ul><li>Las propiedades de las transacciones son: </li></ul><ul><ul><li>Atomicidad </li></ul></ul><ul><ul><li>Coherencia </li></ul></ul><ul><ul><li>Aislamiento </li></ul></ul><ul><ul><li>Permanencia </li></ul></ul>
  • 4. <ul><li>Atomicidad </li></ul><ul><li>Una transacción es una unidad atómica de </li></ul><ul><li>ejecución (o se ejecutan todas sus operaciones o ninguna). Si se esta realizando un a matricula a un estudiante y antes de guardar todos los cambios el sistema se para y no termina la operación, por lo tanto la transacción no se realiza. </li></ul><ul><li>Coherencia </li></ul><ul><ul><li>En caso de una transacción de dinero de una cuenta a otra, pude ocurrir que se realizó a una cuenta errónea por lo tanto no es responsable el SGBD, entonces la incoherencia viene a partir de los desarrolladores, pero se cumple con la operación que ha sido programada. </li></ul></ul>
  • 5. <ul><li>Aislamiento </li></ul><ul><li>una transacción no debe hacer visibles sus </li></ul><ul><li>cambios a otras transacciones hasta que es confirmada Si existió un error en la transacción del dinero no debería afectar las demás, ya que se bloquearían para que puedan acceder otros usuarios, por lo tanto debería tratarse como acceso independiente, por usuario o por transacciones. </li></ul>
  • 6. <ul><li>Permanencia </li></ul><ul><ul><li> Cuando una transacción es confirmada sus cambios deben ser grabados en la BD y no deben perderse debido a fallos de otras transacciones o del sistema. </li></ul></ul><ul><ul><li>En el momento de realizar la transacción del traspaso de dinero de una cuenta a otra, debe ser confirmada la permanencia de los datos </li></ul></ul>
  • 7. <ul><li>EL problema del análisis incoherente: </li></ul><ul><li>Esto sucede cuando se regresa nuevamente a leer la tupla, pero esta ya ha sido cambiada por tanto tendrá un nuevo valor y por lo tanto el cálculo realizado será incoherente, para resolver esto se debe realizar lo mismo que en el problema anterior. </li></ul>
  • 8. <ul><li>Podríamos solucionarlo haciendo ejecutar una sola una sola transacción cada vez, es decir que para que continúe con otra transacción esta debe confirmarse para que comience la siguiente. </li></ul>
  • 9. <ul><li>Existen dos planificaciones que se utilizan para garantizar la concurrencia de incoherencia. </li></ul><ul><li>Planificación Serializable.- Es encontrar planificaciones no serie, es decir que produzca los mismos resultados que alguna ejecución en serie. El orden es importante de esta planificación debido a que en una transacción escribe un elemento, y otra lee o escribe el mismo elemento. </li></ul>
  • 10. <ul><li>Planificación recuperable.- Es que para cada para de transacciones T1 y T2, si T1 lee un elemento de datos previamente escrito por T2, entonces la confirmación de T1 precede de la confirmación de T2. </li></ul>
  • 11. <ul><li>Planificaciones no serie.- Es en la cual las operaciones de un conjunto de transacciones concurrentes están entrelazadas. </li></ul><ul><li>Planificaciones serializables.- Se dice que si el conjunto de transacciones se ejecuta concurrentemente y si produce los mismos resultados que alguna ejecución en serie, se denomina planificación serializable. </li></ul>
  • 12. <ul><li>Serializabilidad de conflictos: Esta planificación ordena las operaciones conflictivas de la misma manera que alguna de las posibles ejecuciones serie. </li></ul><ul><li>Serializabilidad de vistas: Si es equivalente en términos de vistas a una planificación en serie, o si es serializable en términos de conflictos, pero que no lo es vista a la inversa. </li></ul>
  • 13. <ul><li>Anulación en cascada </li></ul><ul><li>Es que en una única transacción conduce a una serie de anulaciones. </li></ul><ul><li>Se consigue en dos faces, que consiste en dejar la liberación de todos los bloqueos hasta el final de la transacción. </li></ul><ul><li>Se puede provocar interbloqueos </li></ul><ul><li>Debido a que las transacciones pueden tener que esperar a que se liberen los bloqueos sobre elementos de datos establecidos. </li></ul>
  • 14. <ul><li>Puede existir que las transacciones queden en bloqueo indefinido , es decir que se queden en un estado de espera indefinida. </li></ul><ul><li>ACCIONES QUE TOMA SGBD </li></ul><ul><li>Para todo esto el SGBD utiliza un sistema de prioridades en la que la prioridad vaya aumentando a medida que lo hace el tiempo de espera. </li></ul><ul><li>Se pude utilizar una cola de tipo FIFO </li></ul>
  • 15. <ul><li>Debido a que se puede acceder con frecuencia a los índices de nivel más altos de los árboles, por lo tanto existirá una contienda por los bloqueos. </li></ul><ul><li>Un bloque eficiente sería el acoplamiento de bloqueos que consiste en bloquear un nodo hijo y liberar el bloqueo en el nodo padre si es posible. </li></ul>
  • 16. <ul><li>Una marca temporal es un identificador unívoco creado por el SGBD y que indica el tiempo de inicio relativo de una transacción. </li></ul><ul><li>En el control de concurrencia basado en bloques existen dos fases: el la una la de crecimiento se adquiere todos los bloques y en la fase de decrecimiento se empieza a liberar cada uno de estos bloques, mientras que en la que es basada en marcas temporales se ubican en orden como llegaron, y tienen prioridad según su marca temporal sea más pequeña. </li></ul>
  • 17. <ul><li>Cuando un transacción T ejecuta un comando read : </li></ul><ul><li>La transacción trata de leer un elemento que ya ha actualizado por un operación posterior, por lo que la transacción llega tarde y cualquier datos que reciba será incoherente, esta deberá ser abortada y reiniciada con una nueva marca temporal. En caso contrario la operación se puede realizar. </li></ul>
  • 18. <ul><li>Cuando un transacción T ejecuta un comando write: </li></ul><ul><li>La transacción solicita escribir un elemento que ya ha sido por una operación más reciente, una operación está ya actualizando este elemento y sería erróneo volver actualizar el elemento ahora, en caso contrario la operación se realiza. </li></ul><ul><li>Regla de escritura de Thomas </li></ul><ul><li>S e utiliza para modificar el protocolo básico de ordenación, con el fin de proporcionar un mayor grado de concurrencia las operaciones de escritura obsoletas. </li></ul>
  • 19. <ul><li>Las versiones pueden borrarse cuando ya no sean necesarias. </li></ul><ul><li>La transacción T ejecuta un comando write: </li></ul><ul><li>si se quiere escribir el elemento de datos x se debe garantizar que este no haya sido leído por otra transacción. Si permitimos que se realice la operación será obvio que la siguiente transacción no podrá leer el dato. </li></ul>
  • 20. <ul><li>La transacción T ejecuta un comando read: </li></ul><ul><li>Si la transacción desea leer un elemento de datos x, debemos asignar la mayor marca temporal de datos a x. para que pueda ejecutarse, con este protocolo las operaciones de lectura nunca fallan. </li></ul>
  • 21. <ul><li>En las técnicas pesimistas o conservadoras se realiza un retardo en las transacciones por si haya un conflicto con tras transacciones en algún instante. En cambio los métodos optimistas mantienen que los conflictos son raros, ellos permiten a las transacciones que continúen de manera no sincronizada y los conflictos se los confirma al final, cuando la transacción se confirma. </li></ul>
  • 22. <ul><li>Tipos de fallos que pueden afectar el procesamiento de la base de datos: </li></ul><ul><li>Paradas catastróficas del sistema: errores del software o del hardware, se pierde el contenido de la memoria principal. </li></ul><ul><li>Fallos de soporte físico: produce pérdida de parte de la información guardada en el almacenamiento secundario </li></ul>
  • 23. <ul><li>Errores en el software de las aplicaciones: errores lógicos en los programas, que producen fallo de transacciones </li></ul><ul><li>Desastres físicos naturales: incendios, inundaciones, terremotos o apagones </li></ul><ul><li>Destrucción Negligente: no intencionada por operadores o usuarios </li></ul><ul><li>Sabotaje: destrucción intencionada de los datos, del hardware, software o de las instalaciones </li></ul>
  • 24.  
  • 25. <ul><li>El archivo de registro es una característica fundamental de cualquier mecanismo de operación ya es este quien contiene información sobre todas las actualizaciones realizadas en la base de datos. </li></ul>
  • 26. <ul><li>Las actualizaciones se escriben en una base de datos hasta que la transacción no alcance su punto de confirmación, si la transacción falla antes de alcanzar este punto no se habrá modificado la base de datos y no será necesario deshacer el cambio. </li></ul><ul><li>En cambio en una actualización inmediata las actualizaciones son aplicadas en la base de datos según se vayan realizando sin espera que alcance su punto de confirmación. </li></ul>
  • 27. <ul><li>Transacciones anidadas: estas transacciones tienen jerarquía de subtransacciones. Existen transacciones de primer nivel que tienen transacciones hijas, y estas a su vez puede volver a tener nuevas transacciones anidadas. </li></ul><ul><li>b) Sagas: Las sagas no son mas que secuencia de transacciones que pueden entrelazarse con otras transacciones. </li></ul>

×