database - tipos - transacciones sql server ejemplos
Transacciones de base de datos-¿Cómo funcionan? (6)
Estoy tratando de aprender más sobre las transacciones de la base de datos, encontré la regla de oro de ACID para escribir transacciones y pensé en algunas preguntas.
La regla de oro de ACID:
Una transacción debe ser:
- Atómico: es una unidad de trabajo y no depende de las transacciones anteriores y siguientes.
- Consistente: los datos se confirman o se retrotraen, no hay un caso "intermedio" en el que algo se haya actualizado y algo no.
- Aislado: ninguna transacción ve los resultados intermedios de la transacción actual.
- Duradero: los valores persisten si los datos se han confirmado, incluso si el sistema falla justo después.
Me preguntaba cómo funcionan bajo el capó, por lo que puedo entender mejor los factores que deben tenerse en cuenta al escribir una transacción de este tipo. Supongo que los detalles específicos variarán entre las implementaciones de base de datos disponibles, pero ciertas reglas siempre estarán en su lugar.
- ¿Cómo maneja la base de datos las transacciones concurrentes mientras sigue soportando la regla atómica?
- ¿Hay una cola de transacciones que se procesa en orden?
- ¿Cómo se maneja una transacción larga que está retrasando a todos los demás?
- ¿Las actualizaciones de las tablas se realizan en la memoria, por lo que si se produce un bloqueo antes de confirmar, no hay ninguna alteración en la base de datos?
- ¿O hay algunas tablas intermedias que se actualizan para sobrevivir a tal caída?
- Mientras una transacción está en curso, ¿se impide el acceso de lectura y escritura a las tablas afectadas?
- ¿O la base de datos permitiría escrituras pero la transacción sobreescribiría todos los cambios al confirmar?
Gracias
Consistente: los datos se confirman o se retrotraen, no hay un caso "intermedio" en el que algo se haya actualizado y algo no.
No estoy de acuerdo con la opinión de Erwin Smout de lo que significa Consistente: su interpretación está más cerca del dinero. Según mi interpretación de Ramakrishnan y Gehrke , un estado consistente va más allá de las restricciones declaradas del sistema.
En el caso de transferir dinero entre dos cuentas debitando una cuenta y acreditando a otra, el sistema podría estar en varios estados:
- Ambas cuentas mantienen sus saldos iniciales;
- La cantidad se deduce de un saldo de cuenta pero no se agrega a otra;
- El monto se agrega a un saldo de cuenta pero no se deduce de otro;
- Ambas cuentas mantienen sus saldos finales.
En los cuatro estados se pueden mantener las restricciones de integridad del sistema. Pero el segundo y el tercero no coinciden con una visión razonable del sistema: el dinero debería estar en alguna parte . Entonces, estos no son estados consistentes, mientras que los estados inicial y final son consistentes.
Las transacciones no hacen que un sistema sea coherente automáticamente, permiten que un usuario las escriba así. Una transacción mal escrita podría tener un error que olvidó acreditar la segunda cuenta. La transacción se ejecutaría bien y las restricciones de integridad se mantendrían.
Pero un procedimiento escrito correctamente toma al sistema de un estado coherente, realiza algunos cambios que son temporalmente inconsistentes (por ejemplo, dinero que no está en ninguna de las cuentas) y luego devuelve el sistema a un estado coherente. Al colocar estos pasos en una transacción, se le garantiza que el sistema alcanzará el estado consistente final (cuando se confirme) o regresará a su estado consistente inicial (si retrocede). De cualquier manera, se mantiene la consistencia.
Hay muchas maneras diferentes, incluyendo la cola de transacciones, el control de concurrencia optimista, etc. Esta es en realidad una pregunta muy compleja, hay libros escritos al respecto:
Depende del nivel de registro en la base de datos. Si se mantienen registros estrictos de escritura anticipada en el caso de una falla del sistema, la base de datos puede recuperarse a un estado consistente.
Depende del tipo de concurrencia. La concurrencia optimista no implica bloqueos, pero si el estado de la base de datos ha cambiado una vez que la transacción ha finalizado, se abandona y se reinicia. Esto puede acelerar dbs donde las colisiones son raras. También hay diferentes niveles de bloqueo: fila, tabla o incluso la db completa.
Estas son preguntas muy complejas, recomendaría comprar un libro o asistir a una serie de conferencias de sistemas concurrentes si desea poder responderlas completamente :-)
"¿Cuál es el veredicto sobre transacciones anidadas"
No hay veredicto. Existen transacciones anidadas. Las propiedades ACID existen. Se ven obligados a coexistir. No hay absolutos. Ciertamente no a ACID.
En términos de implementación, hay esfuerzos desequilibrados para garantizar cada una de ACID propiedades de ACID . Puedo resumirlo en mis pensamientos simplificados:
Un tomicity eventualmente se basa en el bloqueo u otras operaciones atómicas para intercambiar datos modificados dentro de la transacción (creados en la separación) con datos originales en vista compartida.
¿Cómo maneja la base de datos las transacciones concurrentes mientras sigue soportando la regla atómica?
Veo el solation.
C oncistencia se basa en las propiedades más fundamentales de A tomicity y I solation y se extiende más en la capa de aplicación en lugar de pertenecer intrínsecamente al servicio de base de datos.
Asegurar las reglas (cuando A tomicity y I solation está en su lugar) es bastante sencillo ejecutándolas en los datos modificados.
Esto puede provocar debates filosóficos. Pero en mi opinión, en sus casos no triviales, la verificación de todas las condiciones en todos los datos relacionados antes de que finalmente se confirme puede implementarse en la lógica de la aplicación por completo o en procedimientos específicos de la aplicación en la capa de base de datos, lo que no los hace específicos de la base de datos. Lo mínimo que el servicio de base de datos debe garantizar es poder leer los datos escritos previamente sin errores.
¿Las actualizaciones de las tablas se realizan en la memoria, por lo que si se produce un bloqueo antes de confirmar, no hay ninguna alteración en la base de datos?
Veo el solation.
Tenga en cuenta que la coherencia en ACID es puramente lógica, estática y no tiene niveles o grados relacionados con la propagación de datos sugeridos más adelante por el teorema de CAP .
I solación se logra universalmente modificando copias de los datos originales primero (antes de confirmar los cambios en la vista compartida).
Mientras una transacción está en curso, ¿se impide el acceso de lectura y escritura a las tablas afectadas?
En general, si solo se modifica la copia de datos en una transacción, otras no verán estos cambios de manera trivial. Sin embargo, los niveles de aislamiento pueden ser diferentes.
Es la única propiedad de ACID que puede tener algunos niveles y grados sin ser simplemente blanco y negro.
En última instancia, la separación es la más profunda en su implementación y posibles compensaciones entre todas las propiedades de ACID . Y entrar en detalles sobre esta propiedad es el primer tema más importante sobre qué garantiza el servicio de base de datos (incluso en el contexto del teorema de CAP, donde las compensaciones evolucionan nuevamente en torno a la consistencia de vistas aisladas en datos distribuidos).
D urabilidad es en realidad más bien un SLA .
El tipo de durabilidad ("escrito en un disco corruptible" o "distribuido de manera redundante a través de la RAM de los servidores con alimentación de plutonio") generalmente se negocia fuera de la lógica de transacción normal.
La implementación también es bastante trivial y se reduce a la confirmación de la transacción exitosa solo después de que se vacían todos los buffers posibles.
Dos aspectos de implementación cruciales para el rendimiento (que a ACID no le importa explícitamente):
Detección de conflictos
Debería haber una manera de (eficientemente) detectar cambios en conflicto realizados de forma concurrente en otra transacción.
Un punto extremo es bloquear todo lo que no requiere detección de conflictos (sin posible concurrencia).
Otro punto extremo es la concurrencia optimista (al menos parcialmente). Entonces hay una necesidad de saber si hubo cambios concurrentes en absoluto. Esto se puede implementar a través de contadores en ejecución (números de versión) o sumas de comprobación para varios objetos en la base de datos. Entonces, esto se relaciona estrechamente con la implementación del aislamiento.
Procedimiento de reversión
Esto requiere mantener las estructuras de datos de los valores originales y sus copias modificadas (registros de transacciones) para deshacer los cambios. Nuevamente, esto está muy relacionado con cómo se implementa el aislamiento.
Alguna información corta adicional:
- Explicación concisa de la implementación de transacciones en bases de datos.
- answer para evitar tratar con recursos no transaccionales en transacciones.
- ACID cómo implementar métodos de reversión dentro de la aplicación.
Los detalles reales probablemente dependerán en cierta medida de qué servidor de base de datos sea, pero este artículo podría interesarle: Hoja de trucos para el procesamiento de transacciones
Un par de nitpickings en sus definiciones:
Atómico: es una unidad de trabajo y no depende de las transacciones anteriores y siguientes.
Una definición más correcta de atomicidad no mencionaría ninguna transacción "anterior o siguiente". La atomicidad es una propiedad de una sola transacción realizada por sí misma, es decir, que en la cuenta atrás final, o bien todas sus acciones persisten, o ninguna en absoluto. En otras palabras, no será el caso que "solo se permita la mitad de una transacción".
Sin embargo, el concepto está borroso por conceptos como las transacciones anidadas, los puntos de salvaguarda y la capacidad del usuario para solicitar retrocesos explícitos hasta un punto de salvaguardia tomado. Esto permite, en cierto sentido, que "solo la mitad de las acciones de una transacción" persistan, todo a petición del usuario explícito.
Consistente: los datos se confirman o se retrotraen, no hay un caso "intermedio" en el que algo se haya actualizado y algo no.
Esta interpretación es totalmente errónea. Consistente significa que el procesador de transacciones (en este caso, un motor DBMS) no puede dejar el sistema (la base de datos) en un estado de violación de cualquier restricción declarada de la que tenga conocimiento (el procesador de transacciones). Ver, por ejemplo, "Introducción a los sistemas de bases de datos", Capítulo 16.
Aislado: ninguna transacción ve los resultados intermedios de la transacción actual.
Nitpicking: ninguna transacción que no sea la actual puede ver estados intermedios (estados, no resultados). Tenga en cuenta, además, que los "niveles de aislamiento" de los motores de procesamiento de transacciones generalmente definen el grado en que la propiedad I puede violarse.
Duradero: los valores persisten si los datos se han confirmado, incluso si el sistema falla justo después.
Pero esta propiedad también se ve borrosa por la posibilidad de transacciones anidadas. Incluso si una transacción interna se ha comprometido y se ha completado, la transacción que contiene puede deshacer ese compromiso por sí mismo, retrocediendo por completo.