4. Concurrencia

4. 1 Conceptos 4. 2 Propiedades de las transacciones 4 4.1 Conceptos 4.2 Propiedades de las transacciones 4.3 Grados de consistencia 4.4 Niveles de aislamiento 4.5 Commit y rollback

Conceptos No se puede hablar de Concurrencias en Base de datos sin el uso de las Transacciones. se ejecutan serialmente, una después de la otra, sin ninguna intercalación. Informalmente, una transacción es la ejecución de ciertas instrucciones que acceden a una base de datos compartida. Se llama Transacción a una colección de operaciones que forman una unidad lógica de trabajo en una BD realizada por una o más sentencias SQL estrechamente relacionadas.

Propiedades de las transacciones Una unidad lógica de trabajo debe exhibir cuatro propiedades, conocidas como propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad), para ser calificada como transacción.

Atomicity: siginifica que el sistema permite operaciones atómicas Atomicity: siginifica que el sistema permite operaciones atómicas. Una operación atómica es aquella que si está formada por operaciones más pequeñas, se consideran como un paquete indivisible. Deben ejecutarse todas correctamente, o en el caso de que alguna de ellas no pueda hacerlo, el efecto de las que ya se han ejecutado no debe hacerse notar, debe deshacerse, como si el conjunto de las operaciones no se hubieran realizado. No obstante, atomicidad y transacción no son sinónimos. Mientras atomicidad es una propiedad, la transacción es el mecanismo que utilizan los SGBD para lograr la atomicidad. Begin Transaction - Programa - End Transaction Responsable: El método de recuperación, de no completar todas las operaciones, devuelve la BD a su estado anterior a empezar esa Tx rollback).

Coherencia: Asegura que cualquier transacción llevará a la base de datos de un estado válido a otro estado válido. Después de terminar una transacción la Base de datos no viola ninguna de sus reglas: valores obligatorios, claves únicas, etc. Responsable: los programadores mediante la definición adecuada de la integridad referencial: check, triggers, primary key, foreign key,…

Aislamiento: Los efectos de una Tx no son visibles a otros usuarios mientras no se confirmen. Una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de finalizar. Más aun, si varias transacciones, se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado secuencialmente. Esto se conoce como seriabilidad debido a que su resultado es la capacidad de volver a cargar los datos iniciales y reproducir una serie de transacciones para finalizar con los datos en el mismo estado en que estaban después de realizar transacciones originales. Responsable: el método de concurrencia: mecanismos, reglas, protocolos

Durabilidad: Significa que en el mismo momento en que una operación ha terminado satisfactoriamente y el sistema informa de ello, sus efectos quedan ya registrados permanentemente. Si el sistema falla no debe permitir que se pierdan las operaciones realizadas por Tx ya confirmadas. Responsable: el método o gestor de recuperación.

Grados de consistencia Consistencia es un término más amplio que el de integridad. Podría definirse como la coherencia entre todos los datos de la base de datos. Cuando se pierde la integridad también se pierde la consistencia. Pero la consistencia también puede perderse por razones de funcionamiento. Una transacción finalizada (confirmada parcialmente) puede no confirmarse definitivamente (consistencia). Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos. Si se anula los cambios que ha efectuado son deshechos.

La ejecución de una transacción debe conducir a un estado de la base de datos consistente (que cumple todas las restricciones de integridad definidas). Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos. Si se anula los cambios que ha efectuado son deshechos. Una transacción que termina con éxito se dice que está comprometida (commited), una transacción que haya sido comprometida llevará a la base de datos a un nuevo estado consistente que debe permanecer incluso si hay un fallo en el sistema. En cualquier momento una transacción sólo puede estar en uno de los siguientes estados.

Activa (Active): el estado inicial; la transacción permanece en este estado durante su ejecución. Parcialmente comprometida (Uncommited): Después de ejecutarse la última transacción. Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal. Abortada (Rolled Back): después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción. Comprometida (Commited): tras completarse con éxito.

Aspectos relacionados al procesamiento de transacciones Los siguientes son los aspectos más importantes relacionados con el procesamiento de transacciones: Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas. Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit. Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales. Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas. Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).

Niveles de aislamiento Las transacciones especifican un nivel de aislamiento que define el grado en que se debe aislar una transacción de las modificaciones de recursos o datos realizadas por otras transacciones. Los niveles de aislamiento se describen en cuanto a los efectos secundarios de la simultaneidad que se permiten, como las lecturas desfasadas o ficticias. Control de los niveles de aislamiento de transacción: Controla si se realizan bloqueos cuando se leen los datos y qué tipos de bloqueos se solicitan. Duración de los bloqueos de lectura.

Si una operación de lectura que hace referencia a filas modificadas por otra transacción: Se bloquea hasta que se libera el bloqueo exclusivo de la fila. Recupera la versión confirmada de la fila que existía en el momento en el que empezó la instrucción o la transacción. Lee la modificación de los datos no confirmados.

El nivel de aislamiento para una sesión SQL establece el comportamiento de los bloqueos para las instrucciones SQL. El estándar ANSI/ISO SQL define cuatro niveles de aislamiento transaccional en función de tres eventos que son permitidos o no dependiendo del nivel de aislamiento. Estos eventos son: Lectura sucia. Las sentencias SELECT son ejecutadas sin realizar bloqueos, pero podría usarse una versión anterior de un registro. Por lo tanto, las lecturas no son consistentes al usar este nivel de aislamiento. Lectura norepetible. Una transacción vuelve a leer datos que previamente había leído y encuentra que han sido modificados o eliminados por una transacción cursada.

Lectura fantasma. Una transacción vuelve a ejecutar una consulta, devolviendo un conjuto de registros que satisfacen una condición de búsqueda y encuentra que otros registro que satisfacen la condición han sido insertadas por otra transacción cursada. Los niveles de aislamiento SQL son definidos basados en si ellos permiten a cada uno de los eventos definidos anteriormente. Es interesante notar que el estándar SQL no impone un esquema de cierre específico o confiere por mandato comportamientos particulares, pero más bien describe estos niveles de aislamiento en términos de estos teniendo muchos mecanismos de cierre/coincidencia, que dependen del evento de lectura.

Commit y rollback Estructura de una transacción Una transacción de base de datos consta de una o más instrucciones. Específicamente, una transacción consiste en una de las siguientes: Una o más sentencias DML que en conjunto constituyen un cambio atómica a la base de datos Una declaración DML Una transacción tiene un principio y un final.

Inicio de una transacción Una transacción comienza cuando se encuentra la primera sentencia de SQL ejecutable. Una sentencia de SQL ejecutable es una instrucción SQL que genera llamadas a una instancia de base de datos, incluyendo DML y DDL y la instrucción SET TRANSACCIÓN.

Final de una transacción Una transacción termina cuando se produce alguna de las siguientes acciones: Un usuario emite una sentencia COMMIT -guardar- o ROLLBACK - deshacer- sin una cláusula SAVEPOINT -punto de restauración. Mediante COMMIT, un usuario solicita explícitamente o implícitamente que los cambios en la transacción sean permanentes. Los cambios realizados por la transacción son permanentes y visibles para otros usuarios sólo después de una transacción. Un usuario ejecuta una sentencia DDL como CREATE, DROP, RENAMEZ o ALTER.

La base de datos emite una sentencia COMMIT implícito antes y después de cada instrucción DDL. Si la transacción actual contiene instrucciones DML, a continuación, Oracle Database primera confirma la transacción y luego corre y se compromete la sentencia DDL como una nueva, transacción de un único estado. Un usuario sale normalmente de la mayoría de las utilidades y herramientas de base de datos Oracle, haciendo que la transacción actual que se ha comprometido de forma implícita. El comportamiento AUTOCOMMIT cuando un usuario se desconecta depende de la aplicación y la configuración del gestor

http://www.prograweb.com.mx/tallerBD/0405COMMIT_y_ROLLBACK.php