Control de Transacciones

Los conceptos detrás de una transacción son una parte del paradigma de la base de datos relacional. Una transacción consiste en una o más sentencias DML, seguida ya sea por un ROLLBACK o un comando COMMIT.

Lo que sigue es una revisión rápida de algunos de los principios del Paradigma de una base de datos relacional las cuales las bases de datos (no sólo Oracle) deben cumplir. Otros proveedores de bases de datos cumplen con los mismos estándares con sus propios mecanismos, pero con niveles de eficacia variable. En pocas palabras, cualquier base de datos relacional debe ser capaz de pasar la prueba ACID: Atomicidad, Coherencia, Aislamiento y Durabilidad.

A es para Atomicidad

El principio del Estado de Atomicidad, que todas las partes de una transacción se deben completar o ninguno de ellos. (El razonamiento detrás del término es que un átomo no puede ser dividido, ahora bien conocida por ser una suposición falsa). Por ejemplo, si los analistas de negocios han dicho que cada vez que cambie el salario de un empleado también debe cambiar el nivel del empleado, la transacción atómica constará de dos actualizaciones. La base de datos debe garantizar que ambos se ejecuten o no. Si sólo uno de los cambios tiene éxito, usted tiene un empleado con un salario que es incompatible con su Nivel: Corrupción de Datos, en términos de negocio. Si algo sale mal antes de que finalice la transacción, la base de datos en sí debe garantizar que las piezas que no se ejecuten correctamente pueden ser regresadas, lo que debe suceder automáticamente. Una transacción puede tener miles de de operaciones y actualizar cientos de tablas y puede tomar horas e realizarse. La reversión de una transacción incompleta puede ser manual (como cuando se emite el comando ROLLBACK), pero debe ser automática e imparable en el caso de un error.

C es para Consistencia

El principio del Estado de Consistencia afirma que los resultados de una consulta deben ser consistentes con el estado de la base de datos en el momento de la consulta comenzó. Imagine una consulta sencilla que promedia el valor de una columna de una tabla. Si la tabla es grande, se tardará varios minutos en pasar a través de la tabla. Si otros usuarios están actualizando la columna, mientras que la búsqueda está en curso, la consulta debe incluir los valores antiguos o nuevos? ¿Debería incluir filas que se insertan o se eliminan después de la consulta comenzó? El principio de Consistencia establece que la base de datos asegurarse de que los valores modificados no son vistos por la consulta, se le dará un promedio de la columna, ya que fue cuando comenzó la consulta, sin importar el tiempo que la consulta dure o qué otra actividad se esté produciendo en las tablas correspondientes. Oracle garantiza que si una consulta tiene éxito, el resultado será consistente. Sin embargo, si el administrador de la base de datos no ha configurado la base de datos adecuadamente, la consulta puede no tener éxito: hay un famoso error de Oracle "ORA-1555 snapshot too old", que se plantea. Esto solía ser un problema muy difícil de solucionar con las versiones anteriores de la base de datos, pero con las últimas versiones el administrador de la base siempre debe ser capaz de prevenir esto.

I es para Aislamiento

El principio del Estado de Aislamiento que una transacción incompleta (es decir, no confirmada)  debe ser invisible para el resto del mundo. Mientras la transacción está en progreso, sólo la sesión de que se está ejecutando la operación se le permite ver los cambios, todas las demás sesiones deben ver los datos sin cambios, no los nuevos valores. La lógica detrás de esto es en primer lugar, que la operación completa podría no ir a través y que por lo tanto  otros usuarios no deberían poder ver los cambios que podrían revertirse. Y en segundo lugar, durante el transcurso de una operación los datos son (en términos comerciales) incoherente: hay un corto tiempo en que el empleado ha tenido su salario cambiado pero no su grado. Aislamiento de transacciones requiere que la base de datos debe ocultar las transacciones en curso de otros usuarios. Ellos verán la versión PreUpdate de los datos hasta que se complete la transacción, cuando van a ver todos los cambios en un conjunto coherente. Oracle garantiza aislamiento de transacción: no hay manera alguna sesión puede ver datos no confirmados. Una lectura de datos no confirmados se conoce como una lectura sucia, que Oracle no permite (aunque algunas otras bases de datos lo hacen).

D es para Durable

El principio del Estado de Durabilidad que una vez que complete una transacción, debe ser imposible para la base de datos perderlo. Durante el tiempo que la transacción está en progreso, el principio de aislamiento requiere que nadie (aparte de la sesión en cuestión) puede ver los cambios que ha realizado hasta el momento. Pero en el instante en que la transacción se completa, debe ser transmitido al mundo, y la base de datos debe garantizar que el cambio nunca se pierde, una base de datos relacional, no se le permite perder datos.