Transacción (base de datos)
Una transacción en un Sistema de Gestión de Bases de Datos
(SGBD), es un conjunto de órdenes que se ejecutan formando una
unidad de trabajo, es decir, en forma indivisible o atómica.
Un SGBD se dice transaccional, si es capaz de mantener la
integridad de los datos, haciendo que estas transacciones no puedan
finalizar en un estado intermedio. Cuando por alguna causa el sistema
debe cancelar la transacción, empieza a deshacer las órdenes
ejecutadas hasta dejar la base de datos en su estado inicial (llamado
punto de integridad), como si la orden de la transacción nunca se
hubiese realizado.
La Recuperación deinformacion por medio de Transiciones
vence los defectos de recuperación tradicionales eliminando el tiempo
de indisponibilidad y evitando la pérdida de datos buenos. La
Recuperación de Transacción es “el proceso de borrar los efectos
indeseados de transacciones específicas de la base de datos”. La
recuperación tradicional está en el nivel de objeto de base de datos:
por ejemplo, en el espacio de datos, espacio de mesa o nivel de
índice. Realizando una recuperación tradicional, un objeto de base de
datos específico es elegido. Entonces, una copia de seguridad de
aquel objeto es aplicada, seguida volviendo a aplicar entradas de
registro para cambios que ocurrieron después de que la copia de
imagen fue tomada. Recuerde que todos los cambios hechos a una
base de datos relacional son capturados en el registro de base de
datos. De este modo, si los detalles de cambio pueden ser leídos del
registro, la recuperación puede ser conseguida invirtiendo el impacto
de los cambios registrados.
Una de las formas de la Recuperación de Transacción es el Registro
la recuperación de transacción basada toma dos forma: DESHAGA la
recuperación o REHAGA la recuperación. Para DESHACEN la
recuperación, el registro de base de datos es leído para encontrar las
modificaciones de datos que fueron aplicadas durante un margen de
tiempo dado y : el ENCARTE es girado en BORRAR. La
ACTUALIZACIÓN es girada para ACTUALIZAR al viejo valor en
Efecto, una recuperación DESHARÉ invierte modificaciones de base de datos usando SQL.
DESHAGA la Recuperación de Transacción es
la recuperación de base de datos en línea. Por supuesto, si es
deseable conservarse la base de datos en línea durante una
Recuperación de Transacción dependerá en la naturaleza y la
severidad del problema de base de datos.
El segundo tipo de la Recuperación de Transacción es REHACEN la
Recuperación de Transacción. Ya que el proceso REHACER no
genera las transacciones de problema, realizando una recuperación y
luego ejecutando REHACER SQL puede restaurar los datos a un
estado corriente que no incluye las transacciones de problema. Una
Recuperación de Transacción REHARÉ requiere una interrupción para
la recuperación de HOYO. Rehaciendo transacciones en un ambiente
donde la disponibilidad es crucial, la base de datos puede ser rebajada
durante la recuperación de HOYO y cuando hecho, la base de datos
puede devuelto en línea. Rehacer subsecuente de las transacciones
válidas para completar la recuperación puede ser hecho con los datos
en línea, así reduciendo el tiempo de indisponibilidad de aplicación.
La Recuperación de Transacción permite que un usuario recupere una
parte específica de los datos basados en criterios definidos por el
usuario. Una recuperación tradicional es realizada objeto por el objeto
por la base de datos. Una transacción es un juego de operaciones
relacionadas que, cuando agrupado juntos, definen una unidad lógica
del trabajo dentro de una aplicación. Las transacciones son definidas
por la vista del usuario del proceso. Mientras la Recuperación de
Transacción puede parecer a la respuesta a todos sus problemas de
recuperación de base de datos, hay tiempos cuando no es posible o
no aconsejable. El coste tenía que equilibrar contra el coste de
exploraciones largas de los juegos de datos de registro para aislar
datos para deshacer y el coste de aplicación de aquellos datos usando
SQL.
La solución de recuperación de base de datos última debería analizar
su ambiente total y las transacciones que tienen que ser recuperado, y
recomendar que el tipo de la recuperación funcionar. Además, esto
debería generar automáticamente los empleos apropiados para
realizar la recuperación para evitar los errores que están seguros para
ser introducido con escrituras a mano desarrolladas y empleos.
Protocolo de prevención de
Bloqueo por adelantado: obliga a que las
transacciones bloqueen todos los elementos que
necesitan por adelantado. En caso de no poder
conseguir todos esos elementos no bloquea
ninguno y se queda en espera hasta volver a
intentarlo.
Ordenación: Ordena todos los elementos de la
base de datos y una transacción que necesite
varios de esos elementos los bloqueará en ese orden. Esto no es muy práctico.
B. Manejo de Concurrencia.
. CONTROL DE CONCURRENCIA EN BASES DE DATOS
El control de transacciones concurrentes en una base de datos brinda
un eficiente desempeño del Sistema de Base de Datos, puesto que
permite controlar la ejecución de transacciones que operan en
paralelo, accesando a información compartida y, por lo tanto,
interfiriendo potencialmente unas con otras.
El hecho de reservar un asiento en una avión mediante un sistema
basado en aplicaciones web, cuando decenas de personas en el
mundo pueden reservarlo también, nos da una idea de lo importante y
crucial que es el control de concurrencia en un sistema de base de
datos a mediana o gran escala.
Otro ejemplo en el que podemos observar la incidencia del control de
concurrencia en el siguiente: en una Base de Datos bancaria podría
ocurrir que se paguen dos cheques en forma simultánea sobre una
cuenta que no tiene saldo suficiente para cubrirlos en su totalidad, esto
es posible evitarlo si se tiene un control de concurrencia.
Técnicas de bloqueo sobre Base de Datos: Bloqueo Pesimista y
Bloqueo Optimista
10 enero 2011 — Luis Miguel Gracia Luis
(SGBD), es un conjunto de órdenes que se ejecutan formando una
unidad de trabajo, es decir, en forma indivisible o atómica.
Un SGBD se dice transaccional, si es capaz de mantener la
integridad de los datos, haciendo que estas transacciones no puedan
finalizar en un estado intermedio. Cuando por alguna causa el sistema
debe cancelar la transacción, empieza a deshacer las órdenes
ejecutadas hasta dejar la base de datos en su estado inicial (llamado
punto de integridad), como si la orden de la transacción nunca se
hubiese realizado.
La Recuperación deinformacion por medio de Transiciones
vence los defectos de recuperación tradicionales eliminando el tiempo
de indisponibilidad y evitando la pérdida de datos buenos. La
Recuperación de Transacción es “el proceso de borrar los efectos
indeseados de transacciones específicas de la base de datos”. La
recuperación tradicional está en el nivel de objeto de base de datos:
por ejemplo, en el espacio de datos, espacio de mesa o nivel de
índice. Realizando una recuperación tradicional, un objeto de base de
datos específico es elegido. Entonces, una copia de seguridad de
aquel objeto es aplicada, seguida volviendo a aplicar entradas de
registro para cambios que ocurrieron después de que la copia de
imagen fue tomada. Recuerde que todos los cambios hechos a una
base de datos relacional son capturados en el registro de base de
datos. De este modo, si los detalles de cambio pueden ser leídos del
registro, la recuperación puede ser conseguida invirtiendo el impacto
de los cambios registrados.
Una de las formas de la Recuperación de Transacción es el Registro
la recuperación de transacción basada toma dos forma: DESHAGA la
recuperación o REHAGA la recuperación. Para DESHACEN la
recuperación, el registro de base de datos es leído para encontrar las
modificaciones de datos que fueron aplicadas durante un margen de
tiempo dado y : el ENCARTE es girado en BORRAR. La
ACTUALIZACIÓN es girada para ACTUALIZAR al viejo valor en
Efecto, una recuperación DESHARÉ invierte modificaciones de base de datos usando SQL.
DESHAGA la Recuperación de Transacción es
la recuperación de base de datos en línea. Por supuesto, si es
deseable conservarse la base de datos en línea durante una
Recuperación de Transacción dependerá en la naturaleza y la
severidad del problema de base de datos.
El segundo tipo de la Recuperación de Transacción es REHACEN la
Recuperación de Transacción. Ya que el proceso REHACER no
genera las transacciones de problema, realizando una recuperación y
luego ejecutando REHACER SQL puede restaurar los datos a un
estado corriente que no incluye las transacciones de problema. Una
Recuperación de Transacción REHARÉ requiere una interrupción para
la recuperación de HOYO. Rehaciendo transacciones en un ambiente
donde la disponibilidad es crucial, la base de datos puede ser rebajada
durante la recuperación de HOYO y cuando hecho, la base de datos
puede devuelto en línea. Rehacer subsecuente de las transacciones
válidas para completar la recuperación puede ser hecho con los datos
en línea, así reduciendo el tiempo de indisponibilidad de aplicación.
La Recuperación de Transacción permite que un usuario recupere una
parte específica de los datos basados en criterios definidos por el
usuario. Una recuperación tradicional es realizada objeto por el objeto
por la base de datos. Una transacción es un juego de operaciones
relacionadas que, cuando agrupado juntos, definen una unidad lógica
del trabajo dentro de una aplicación. Las transacciones son definidas
por la vista del usuario del proceso. Mientras la Recuperación de
Transacción puede parecer a la respuesta a todos sus problemas de
recuperación de base de datos, hay tiempos cuando no es posible o
no aconsejable. El coste tenía que equilibrar contra el coste de
exploraciones largas de los juegos de datos de registro para aislar
datos para deshacer y el coste de aplicación de aquellos datos usando
SQL.
La solución de recuperación de base de datos última debería analizar
su ambiente total y las transacciones que tienen que ser recuperado, y
recomendar que el tipo de la recuperación funcionar. Además, esto
debería generar automáticamente los empleos apropiados para
realizar la recuperación para evitar los errores que están seguros para
ser introducido con escrituras a mano desarrolladas y empleos.
Protocolo de prevención de
Bloqueo por adelantado: obliga a que las
transacciones bloqueen todos los elementos que
necesitan por adelantado. En caso de no poder
conseguir todos esos elementos no bloquea
ninguno y se queda en espera hasta volver a
intentarlo.
Ordenación: Ordena todos los elementos de la
base de datos y una transacción que necesite
varios de esos elementos los bloqueará en ese orden. Esto no es muy práctico.
B. Manejo de Concurrencia.
. CONTROL DE CONCURRENCIA EN BASES DE DATOS
El control de transacciones concurrentes en una base de datos brinda
un eficiente desempeño del Sistema de Base de Datos, puesto que
permite controlar la ejecución de transacciones que operan en
paralelo, accesando a información compartida y, por lo tanto,
interfiriendo potencialmente unas con otras.
El hecho de reservar un asiento en una avión mediante un sistema
basado en aplicaciones web, cuando decenas de personas en el
mundo pueden reservarlo también, nos da una idea de lo importante y
crucial que es el control de concurrencia en un sistema de base de
datos a mediana o gran escala.
Otro ejemplo en el que podemos observar la incidencia del control de
concurrencia en el siguiente: en una Base de Datos bancaria podría
ocurrir que se paguen dos cheques en forma simultánea sobre una
cuenta que no tiene saldo suficiente para cubrirlos en su totalidad, esto
es posible evitarlo si se tiene un control de concurrencia.
Técnicas de bloqueo sobre Base de Datos: Bloqueo Pesimista y
Bloqueo Optimista
10 enero 2011 — Luis Miguel Gracia Luis
Bloqueo pesimista
El bloqueo pesimista es la técnica por la cual los datos son
bloqueados previos a su modificación para evitar que nadie los
modifique. Una vez que los datos a actualizar han sido bloqueados la
aplicación puede acometer los cambios, con commit o rollback, en ese
caso el bloqueo es automáticamente eliminado. Si alguien intenta
adquirir un bloqueo de los mismos datos durante el proceso será
obligado a esperar hasta que la primera transacción finalice.
Esta técnica es muy simple pero tiene dos problemas fundamentales:
Ø Bloqueo: un usuario selecciona un registro para actualizar, y
entonces abandona la operación. Todos los usuarios que necesitan
actualizar ese registro tienen que esperar hasta que se complete la
transacción, o hasta que se mate y finalice el bloqueo.
Ø Deadlock: Si los usuarios A y B están ambos actualizando la base
de datos a la vez y A bloqueo un registro e intenta adquirir un bloqueo
mantenido por B, que a su vez está esperando a adquirir un bloqueo
mantenido por A ambas transacciones quedarían en espera
indefinidamente, dando lugar a un Deadlock.
En general los Sistemas RDBMS ofrecen cláusulas para este bloqueo.
Oracle soporta bloqueo pesimista a nivel de fila. La sentencia estándar
para el bloqueo es SELECT FOR UPDATE que hace que todas las
sentencias UPDATE o SELECT FOR UPDATE de otras conexiones se
bloqueen hasta que un commit, rollback o deadlock se produzca. Se
produce un deadlock cuando un usuario que tiene la fila A bloqueada
intenta bloquear la fila B, mientras que otro usuario tiene la fila B
bloqueada e intenta bloquear la A. En este caso Oracle deshabilita uno
de los bloqueos del usuario permitiendo al otro usuario bloquear
ambas filas.
Oracle además tiene el bloqueo SELECT FOR UPDATE NO WAIT, de
modo que Oracle causará una excepción cuando una fila bloqueada
es seleccionada. Esto puede ser útil si no se quiere bloquear un
usuario para un tiempo indefinido.
bloqueados previos a su modificación para evitar que nadie los
modifique. Una vez que los datos a actualizar han sido bloqueados la
aplicación puede acometer los cambios, con commit o rollback, en ese
caso el bloqueo es automáticamente eliminado. Si alguien intenta
adquirir un bloqueo de los mismos datos durante el proceso será
obligado a esperar hasta que la primera transacción finalice.
Esta técnica es muy simple pero tiene dos problemas fundamentales:
Ø Bloqueo: un usuario selecciona un registro para actualizar, y
entonces abandona la operación. Todos los usuarios que necesitan
actualizar ese registro tienen que esperar hasta que se complete la
transacción, o hasta que se mate y finalice el bloqueo.
Ø Deadlock: Si los usuarios A y B están ambos actualizando la base
de datos a la vez y A bloqueo un registro e intenta adquirir un bloqueo
mantenido por B, que a su vez está esperando a adquirir un bloqueo
mantenido por A ambas transacciones quedarían en espera
indefinidamente, dando lugar a un Deadlock.
En general los Sistemas RDBMS ofrecen cláusulas para este bloqueo.
Oracle soporta bloqueo pesimista a nivel de fila. La sentencia estándar
para el bloqueo es SELECT FOR UPDATE que hace que todas las
sentencias UPDATE o SELECT FOR UPDATE de otras conexiones se
bloqueen hasta que un commit, rollback o deadlock se produzca. Se
produce un deadlock cuando un usuario que tiene la fila A bloqueada
intenta bloquear la fila B, mientras que otro usuario tiene la fila B
bloqueada e intenta bloquear la A. En este caso Oracle deshabilita uno
de los bloqueos del usuario permitiendo al otro usuario bloquear
ambas filas.
Oracle además tiene el bloqueo SELECT FOR UPDATE NO WAIT, de
modo que Oracle causará una excepción cuando una fila bloqueada
es seleccionada. Esto puede ser útil si no se quiere bloquear un
usuario para un tiempo indefinido.
Bloqueo optimista con control de concurrencia
El bloqueo optimista no bloquea los registros que se van a actualizar
y asume que los datos que están siendo actualizados no van a
cambiar desde que se han leído. Puesto que en nuestro caso no se
puede asumir esto es necesario un control de la concurrencia, de
esta manera el bloqueo optimista con control de
concurrencia asegura que los datos que están siendo escritos son
consistentes con los leídos en primera instancia, es decir que ninguna
otra transacción ha actualizado los datos después de la lectura. El
procedimiento para asegurar la consistencia es muy sencillo: se leerá
un valor junto al registro, se actualizará ese valor a la BD cuando el
registro es actualizado.
Existen varios mecanismos asegurar el control de la concurrencia, el
más común es el uso de un timestamp modificado. Este mecanismo
sólo ofrece una resolución de un segundo.
y asume que los datos que están siendo actualizados no van a
cambiar desde que se han leído. Puesto que en nuestro caso no se
puede asumir esto es necesario un control de la concurrencia, de
esta manera el bloqueo optimista con control de
concurrencia asegura que los datos que están siendo escritos son
consistentes con los leídos en primera instancia, es decir que ninguna
otra transacción ha actualizado los datos después de la lectura. El
procedimiento para asegurar la consistencia es muy sencillo: se leerá
un valor junto al registro, se actualizará ese valor a la BD cuando el
registro es actualizado.
Existen varios mecanismos asegurar el control de la concurrencia, el
más común es el uso de un timestamp modificado. Este mecanismo
sólo ofrece una resolución de un segundo.
Bloqueo y Motores ORM
Hibernate, y en general los motores de persistencia, y por supuesto
JPA soportan el bloqueo optimista simplificando su uso. Algunos
motores como Hibernate o JPA 2 soportan incluso el bloqueo
pesimista.
En este post hay un artículo sobre cómo gestiona JPA 2 la
concurrencia.
Técnicas de bloqueos
impidiendo a otros usuarios la recuperación o
actualización de los elementos bloqueados.
JPA soportan el bloqueo optimista simplificando su uso. Algunos
motores como Hibernate o JPA 2 soportan incluso el bloqueo
pesimista.
En este post hay un artículo sobre cómo gestiona JPA 2 la
concurrencia.
Técnicas de bloqueos
impidiendo a otros usuarios la recuperación o
actualización de los elementos bloqueados.
No hay comentarios:
Publicar un comentario