Transacciones DBMS

¡Todo castor! Estamos ampliando activamente nuestra gama de cursos, por así decirlo, y ahora nos complace presentar uno nuevo: "DBMS relacional" . El curso fue creado por uno de los principales maestros del curso de Administrador de Linux : Alexey Tsykunov . De lo contrario, todo será como de costumbre: utilidades y lecciones abiertas en las que Alex compartirá cosas diferentes que no están incluidas en el curso en sí.

Vamos!

Una transacción puede definirse como un conjunto de tareas, cuyo cumplimiento es un requisito previo para completar correctamente la transacción. Una sola tarea es el bloque mínimo indivisible de cambio de datos.

Aquí hay un ejemplo de una transacción simple. Supongamos que un empleado del banco transfiere 500 rupias de la cuenta A a la cuenta B. Esta transacción pequeña y simple involucra varias tareas de bajo nivel.

Cuenta A

Open_Account(A) Old_Balance = A.balance New_Balance = Old_Balance - 500 A.balance = New_Balance Close_Account(A) 

Cuenta B

 Open_Account(B) Old_Balance = B.balance New_Balance = Old_Balance + 500 B.balance = New_Balance Close_Account(B) 

Propiedades ácidas

Una transacción en el sistema de base de datos debe mantener Atomicidad, Consistencia, Aislamiento y Durabilidad (ACID para abreviar) para garantizar la precisión, integridad e integridad de los datos:

• Atomicidad : esta propiedad muestra que una transacción debe considerarse como una unidad atómica, es decir, se realizan todas sus operaciones o no una sola. No debe haber estados en la base de datos en los que la transacción se complete parcialmente. Los estados deben establecerse antes del inicio de la transacción o después de la finalización / interrupción / falla de la transacción.
• Consistencia : esta propiedad indica que la base de datos debe permanecer en un estado coherente después de cualquier transacción. Ninguna transacción debería tener un efecto negativo en los datos de la base de datos. Si la base de datos estaba en un estado consistente antes de que se completara la transacción, entonces debería estar en ella después de su finalización.
• Aislamiento : en el sistema de base de datos, donde se realizan varias transacciones simultáneamente y en paralelo, la propiedad de aislamiento indica que cada transacción se ejecutará y ejecutará como si fuera la única transacción en el sistema. Ninguna transacción debería afectar la existencia de otras transacciones.
• Resistencia : esta propiedad indica que la base de datos debe ser lo suficientemente estable como para almacenar todas las actualizaciones más recientes, incluso si el sistema comete un error o se reinicia. Si la transacción conduce a una actualización del fragmento de datos en la base de datos, estos cambios deben continuar almacenados en la base de datos. Si se realiza la transacción, pero el sistema se bloquea antes de escribir datos en el disco, los datos deben actualizarse inmediatamente después de reiniciar el sistema.

Serialización

Cuando el sistema operativo realiza varias transacciones en un entorno multiprograma, es probable que las instrucciones de una transacción se mezclen con las instrucciones de otra.

• Un cronograma es una ejecución cronológica de una serie de transacciones. Un programa puede tener muchas transacciones, cada una de las cuales consta de varias instrucciones / tareas.
• Un cronograma secuencial es un cronograma en el que las transacciones se organizan de manera que cada una de las transacciones se completa a su vez. Un cronograma se llama secuencial solo por un patrón de ejecución consistente.

En un entorno de transacciones múltiples, un cronograma secuencial se considera un punto de referencia. El orden de ejecución de las instrucciones en una transacción no se puede cambiar, pero la ejecución de las instrucciones de dos transacciones puede ser aleatoria. La ejecución no es perjudicial cuando dos transacciones son mutuamente independientes y funcionan en diferentes segmentos de datos; pero si usan los mismos datos, los resultados pueden diferir, lo que puede llevar a la base de datos a un estado inconsistente.

Para resolver este problema, permitimos la ejecución paralela del cronograma de transacciones en caso de que las transacciones se serialicen o tengan alguna relación de equivalencia.

Horarios equivalentes

Los horarios equivalentes pueden ser de los siguientes tipos:

Equivalencia del resultado.

Si dos programaciones después de la ejecución producen el mismo resultado, se consideran equivalentes en el resultado. Los resultados pueden ser los mismos para algunos valores y pueden diferir para otro conjunto de valores. Por lo tanto, dicha equivalencia generalmente no se considera significativa.

Equivalencia de presentación

Dos cronogramas se consideran equivalentes en la presentación si las transacciones en cada uno de los cronogramas realizan acciones similares de manera similar.

Por ejemplo:

• Si T lee los datos originales en S1, entonces también lee los datos originales en S2.
• Si T lee el valor escrito por J en S1, entonces también lee el valor escrito por J en S2.
• Si T termina de escribir valores en S1, entonces también termina de escribir valores en S2.

Equivalencia de conflictos

Dos programaciones entrarán en conflicto si tienen las siguientes propiedades:

• Pertenecen a diferentes transacciones.
• Acceden a los mismos datos.
• Al menos uno de ellos es la operación de "escritura".

Dos cronogramas con varias transacciones con operaciones en conflicto se consideran equivalentes a un conflicto solo si:

• Ambas programaciones contienen el mismo conjunto de transacciones.
• El orden de los pares de operaciones en conflicto se admite en ambos programas.

Nota : Las programaciones equivalentes en la presentación son serializables en la presentación, y las programaciones equivalentes a conflictos son serializables en conflictos. Todos los cronogramas serializables por conflictos son serializables por presentación.

Estado de la transacción

Una transacción en una base de datos puede estar en los siguientes estados:

• Activo (Activo) : en este estado, la transacción comienza a ejecutarse. Este es el estado inicial de cualquier transacción.
• Parcialmente comprometido : cuando una transacción completa su operación final, se considera que está en un estado parcialmente perfecto.
• Fallido: una transacción se considera fallida si una de las comprobaciones realizadas por el sistema de recuperación de la base de datos ha fallado. Tal transacción no puede continuar.
• Anulado : si falla alguna verificación y la transacción pasa a un estado fallido, el administrador de recuperación revertirá todas las operaciones de escritura en la base de datos para devolverla a su estado original antes de que la transacción comenzara.
  Las transacciones en este estado se consideran interrumpidas. El módulo de recuperación de la base de datos puede seleccionar una de dos operaciones después de que se interrumpe la transacción:
  
  
  • Reiniciar la transacción;
  • Cancelar transacción.
• Perfecto : si la transacción ha completado con éxito todas las operaciones, se considera perfecta. Todos sus efectos se registran permanentemente en el sistema de base de datos.

El fin

Como siempre, estamos esperando comentarios, una pregunta que se puede hacer tanto aquí como en una lección abierta con Alexei .