ADMINISTRACIÓN DE

TRANSACCIONES Y
CONTROL DE
CONCURRENCIA
PRESENTAN:
Bautista Valencia David Alejandro
Cesar Alejandro Montaño Cortés
Javier León Orozco
Darwin Woytila Díaz Simón
Asesor:
Carlos Miguel López Martínez
OCTUBRE 25, 2017
ÍNDICE

I. PROPIEDADES DE LAS TRANSACCIONES

II. PROPIEDADES ACID
III. ESTADOS DE UNA TRANSACCION
IV. NIVELES DE AISLAMIENTO Y SECUENCIALIDAD
V. CONTROL DE CONCURRENCIA
VI. METODOS DE BLOQUEO
VII. RECUPERACIÓN DE LA BASE DE DATOS.
PROPIEDADES DE LAS
TRANSACCIONES
 I. PROPIEDADES DE LAS TRANSACCIONES

¿QUÉ ES UNA TRANSACCIÓN?

Una transacción es un conjunto de

operaciones que se ejecutan en una base de
datos, y que son tratadas como una única
unidad lógica por el SGBD.
Es decir, una transacción es una o varias
sentencias SQL que se ejecutan en una base
de datos como una única operación,
confirmándose o deshaciéndose en grupo.
 I. PROPIEDADES DE LAS TRANSACCIONES

OPERACIONES UTILIZADAS

No todas las operaciones SQL son transaccionales. Sólo son

transaccionales las operaciones correspondiente al DML, es
decir, sentencias

SELECT, INSERT, UPDATE , DELETE

 I. PROPIEDADES DE LAS TRANSACCIONES

OPERACIONES UTILIZADAS

Para deshacer una transacción se Para confirmar una transacción se

utiliza la sentencia utiliza la sentencia

ROLLBACK. COMMIT.

Cuando realizamos Rollback se Cuando realizamos COMMIT los

deshacen todas las modificaciones cambios se escriben en la base de
realizadas por la transacción en la datos.
base de datos, quedando la base de
datos en el mismo estado que antes
de iniciarse la transacción.
 I. PROPIEDADES DE LAS TRANSACCIONES

EJEMPLO

Un ejemplo clásico de Si en alguno de estos puntos se

transacción son las produce un fallo en el sistema
transferencias bancarias. Para podríamos hacer descontado el dinero
realizar una transferencia de de una de las cuentas y no haberlo
dinero entre dos cuentas ingresado en la otra. Por lo tanto,
bancarias debemos descontar todas estas operaciones deben ser
el dinero de una cuenta, correctas o fallar todas. En estos casos,
realizar el ingreso en la otra al confirmar la transacción (COMMIT)
cuenta y grabar las o al deshacerla (ROLLBACK)
operaciones y movimientos garantizamos que todos los datos
necesarios, actualizar los quedan en un estado consistente.
saldos.
 I. PROPIEDADES DE LAS TRANSACCIONES

OTRAS COSAS QUE DEBES SABER

En una transacción los datos modificados no son visibles

por el resto de usuarios hasta que se confirme la
transacción.
EN PL-SQL
PROPIEDADES ACID
 II. PROPIEDADES ACID

Se suele hacer referencia a estas como las propiedades ACID (por sus iniciales en inglés). En 1970,
Jim Gray definió las propiedades que necesitaba tener una transacción confiable, y desarrolló
tecnologías para automatizarlas. Más tarde, en 1983, Andreas Reuter y Theo Härder crearon el
término "ACID" para describir estas 4 propiedades.
ATOMICIDAD
Todas las operaciones de la transacción son ejecutadas por
completo, o no se ejecuta ninguna de ellas (si se ejecuta la
transacción, se hace hasta el final).
 II. PROPIEDADES ACID

CONSISTENCIA

Una transacción T transforma un estado consistente de
la base de datos en otro estado consistente, aunque T
no tiene por qué preservar la consistencia en todos los
puntos intermedios de su ejecución. Un ejemplo es el
de la transferencia de una cantidad de dinero entre dos
cuentas bancarias.
Cualquier dato que se escriba en la base de datos tiene que
ser válido de acuerdo a todas las reglas definidas,
incluyendo (pero no limitado a) los constraints, los cascades,
los triggers, y cualquier combinación de estos.
 II. PROPIEDADES ACID

AISLAMIENTO (ISOLATION)

Una transacción está aislada del resto de transacciones. Aunque

existan muchas transacciones ejecutándose a la vez, cualquier
modificación de datos que realice T está oculta para el resto de
transacciones hasta que T sea confirmada (realiza COMMIT).
Cada transacción es independiente de otra.
 II. PROPIEDADES ACID

DURABILIDAD

Una vez que se confirma una transacción, sus

actualizaciones sobreviven cualquier fallo del sistema.
Las modificaciones ya no se pierden, aunque el sistema
falle justo después de realizar dicha confirmación
ESTADOS DE UNA TRANSACCIÓN
 III. ESTADOS DE UNA TRANSACCIÓN

ESTADOS
Una transacción debe estar en uno de los siguientes estados:

• Activa (estado inicial): la transacción permanece en este estado durante su ejecución.

• Parcialmente Comprometida: la transacción pasa a este estado cuando acaba de

realizar la última instrucción.

• Fallida: la transacción pasa a este estado tras descubrir que no puede continuar la
ejecución normal.

• Abortada: la transacción pasa a este estado después de haber restablecido la base de

datos a su estado anterior.

• Comprometida: la transacción pasa a este estado tras completarse con éxito.

Una vez concluida una transacción, sus efectos son permanentes en el sistema. Las
modificaciones persisten aún en el caso de producirse un error del sistema.
III. ESTADOS DE UNA TRANSACCIÓN
NIVELES DE AISLAMIENTO Y
SECUENCIALIDAD
 IV. NIVELES DE AISLAMIENTO Y
SECUENCIALIDAD

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.
 IV. NIVELES DE AISLAMIENTO Y
SECUENCIALIDAD

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.
 IV. NIVELES DE AISLAMIENTO Y
SECUENCIALIDAD
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 no repetible. 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 conjunto 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.
 IV. NIVELES DE AISLAMIENTO Y
SECUENCIALIDAD

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.
 IV. NIVELES DE
AISLAMIENTO Y
SECUENCIALIDAD
 IV. NIVELES DE AISLAMIENTO Y
SECUENCIALIDAD

• Sintaxis general en SQL:

• SET TRANSACTION ISOLATION LEVEL <OPCION>
• Donde <OPCION> toma los valores correspondientes al nivel de aislamiento
que deseamos ocupar:
• READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ o
SERIALIZABLE.
CONTROL DE CONCURRENCIA
 V. CONTROL DE CONCURRENCIA

¿QUÉ ES CONCURRENCIA?

La concurrencia se refiere a la Este proceso deben garantizar

propiedad de los sistemas que
permiten que múltiples procesos
sean ejecutados al mismo
tiempo, y que potencialmente
puedan interactuar entre sí.
que las operaciones que se
ejecutan concurrentemente
den los mismos resultados
que si se ejecutaran en serie.
 V. CONTROL DE CONCURRENCIA

Niveles de bloqueo:

Las BD multi-usuarios utilizan bloqueos en el control de

concurrencia.
· Bloqueo exclusivo. No permite que un recurso sea compartido.
La primera transacción que lo bloquea es la única que puede
alterarlo.
· Bloqueo compartido. Permite que un recurso sea compartido.
Muchas transacciones pueden adquirir este tipo de bloqueo
sobre el mismo recurso.
 V. CONTROL DE CONCURRENCIA

EN ORACLE
• Provee automáticamente una consistencia de lectura un query
para que todos los datos que el query necesite provengan de
un solo lugar al mismo tiempo.

• Una consulta no verá ni datos basura ni cualquier cambio

hecho por alguna transacción que haya realizado commit
durante la ejecución del query (es decir, solo accede a los
datos que hayan sido modificados o agregados y su
transacción haya realizado commit antes de que la transacción
que se desea ejecutar se inicie) .
 V. CONTROL DE CONCURRENCIA

EN ORACLE

Oracle usa la información que

mantiene en su "segmento rollback"
para proveer la consistencia.

Este segmento contiene los valores

antiguos de los datos que han sido
cambiados por las transacciones
que no hayan realizado commit o
que ya lo hayan hecho.
 V. CONTROL DE CONCURRENCIA

EN ORACLE

Oracle proporciona tres niveles de aislamiento:

a) READ-COMMITTED: Nivel de aislamiento por defecto. Cada consulta

de una transacción solo ve los datos que fueron confirmados antes de
que la consulta comenzara. Se producen lecturas no reproducibles.
SET TRANSACTION ISOLATION LEVEL READ COMMITTED.
b) SERIALIZABLE TRANSACTIONS: Solamente se ven los cambios
realizados por transacciones confirmadas + cambios efectuados por ella
misma.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE.
c) READ-ONLY : transacciones de solo lectura ven datos confirmados
antes de empezar y no permiten modificaciones de los datos.
SET TRANSACTION ISOLATION LEVEL READ ONLY.
MÉTODOS DE BLOQUEO
 VI. MÉTODOS DE BLOQUEO

¿QUÉ ES UN BLOQUEO?

Los bloqueos son los que se utilizan para evitar que dos transacciones
accedan al mismo tiempo al mismo recurso.
Usa automáticamente diferentes tipos de bloqueos para el control del
acceso concurrente a los datos y prevenir la interacción destructiva entre
usuarios.
Bloquea automáticamente los datos fuente durante la transacción para evitar
que otras transacciones hagan algo requiriendo acceso exclusivo de los
mismos datos fuente.
 VI. MÉTODOS DE BLOQUEO

¿QUÉ ES UN BLOQUEO?
Se utilizan bloqueos a nivel de fila: Un Interbloqueo ocurre cuando
una transacción espera cuando dos o más usuarios están
intenta modificar una fila esperando datos bloqueados por
modificada por una transacción no los otros.
confirmada. ORACLE no escalona Oracle automáticamente detecta
los bloqueos. situaciones de interbloqueo y los
resuelve abortando una de las
transacciones. Se detectan
mediante grafos de esperas.
 VI. MÉTODOS DE BLOQUEO

EN ORACLE

ORACLE utiliza el nivel menos restrictivo guiándose por las siguientes

reglas:
·Operaciones de lectura no esperan a las de escritura sobre los
mismos datos.
·Operaciones de escritura no esperan a las de lectura sobre los
mismos datos.
·Operaciones de escritura solamente esperan a otras operaciones de
escritura que intentan modificar la misma tupla.
RECUPERACIÓN DE LA BASE DE
DATOS
 RECUPERACIÓN DE LA BASE DE DATOS

Las causas de error en una sistema de BD pueden agruparse en las siguientes

CAUSAS categorías:
*Físicas
son causadas por fallos del hardware, como por ejemplo del disco o de la
CPU.
*de Diseño
son agujeros en el software, ya sea en el SO o en el SGBD.
*de Funcionamiento
son causadas por la intervención humana, debidos a fallos del DBA,
configuraciones inapropiadas o mal planteamiento de los procedimientos
de backup.
*del entorno
como por ejemplo desastres naturales, fallos de corriente, temperatura
excesiva
 RECUPERACIÓN DE LA BASE DE DATOS

BACKUP

Los backups se pueden clasificar en físicos y lógicos. Los

físicos se realizan cuando se copian los ficheros que
soportan la BD. Entre estos se encuentran los backups del
SO, los backups en frio y los backups en caliente.Los
backups lógicos sólo extraen los datos de las tablas
utilizando comandos SQL y se realizan con la utilidad
export/import
RECUPERACIÓN DE LA BASE DE DATOS

Oracle proporciona diferentes modos de recuperar un fallo

en la BD, y es importante que el DBA conozca como
funciona cada uno de ellos para determinar cuando ha de
ser utilizado. Una de las mayores responsabilidades del DBA
consiste en tener la BD a punto, y prepararla ante la
posibilidad de que se produzca un fallo. Así, ante un fallo el
DBA podrá recuperar la BD en el menor tiempo posible. Los
procesos de recuperación dependen del tipo de error y de
las estructuras afectadas.
Así, los tipos de error que se pueden producir son:
RECUPERACIÓN DE LA BASE DE DATOS

Errores de Usuario
Como por ejemplo un usuario borrando una fila o
eliminando una tabla. Estos errores se solucionan
importando una tabla de una copia lógica anterior. Si no se
dispone de la copia lógica, se puede recuperar la BD en una
instancia auxiliar, exportar la tabla en cuestión de la
instancia auxiliar e importarla en la instancia operativa.
Fallos de Sentencias
RECUPERACIÓN DE LA BASE DE DATOS

Fallos de Sentencias
Se definen como la imposibilidad del SGBD Oracle de
ejecutar alguna sentencia SQL. Un ejemplo de esto se
produce cuando se intenta una selección de una tabla que
no existe. Estos fallos se recuperan automáticamente
mediante un rollback de la transacción que contenta la
sentencia fallida. El usuario necesitará volver a ejecutar otra
vez la transacción cuando se haya solucionado la causa del
problema.
 RECUPERACIÓN DE LA BASE DE DATOS

• El proceso PMON liberará recursos si un proceso de usuario falla (por

ejemplo, libera bloqueos de la base de datos).
• El mandato ROLLFORWARD DATABASE recupera una base de datos
aplicando las transacciones registradas en los archivos de anotaciones
cronológicas de base de datos.
• La sentencia ROLLBACK se utiliza para restituir los cambios que se han
hecho en la base de datos dentro de una unidad de trabajo o punto de
salvaguarda.
RECUPERACIÓN DE LA BASE DE DATOS

Fallos de Procesos
Es una terminación anormal de un proceso. Si el proceso
era un proceso de usuario, del servidor o de una aplicación
el PMON efectuará la recuperación del proceso. Si el
proceso era alguno de los de background, la instancia debe
de ser parada y arrancada de nuevo, proceso durante el
cual se recupera la caida efectuando un roll forward y
un rollback de las transacciones no confirmadas.
 RECUPERACIÓN DE LA BASE DE DATOS

Recuperación de la BD La BD debe estar montada pero no abierta. El comando de recuperación es el

siguiente:
RECOVER
[AUTOMATIC] [FROM 'localización'] [BD]
[UNTIL CANCEL]
[UNTIL TIME fecha]
[UNTIL CHANGE entero][USING BACKUP CONTROLFILE]
Las opciones entre corchetes son opcionales:
AUTOMATIC hace que la recuperación se haga automáticamente sin
preguntar al DBA por el nombre de los ficheros redo log. También se puede
utilizar para este cometido el comando set autorecovery on/off.
Los ficheros redo log deben estar en la localización fijada en
LOG_ARCHIVE_DEST y el formato del nombre de los ficheros debe ser el
fijado en LOG_ARCHIVE_FORMAT.FROM se utiliza para determinar el lugar
donde están los ficheros redo log, si es distinto del fijado en
LOG_ARCHIVE_DEST.UNTIL sirve para indicar que se desea realizar una
recuperación incompleta, lo que implica perder datos. Solo se dará cuando
se han perdido redo log archivados o el fichero de control.
• Cuando se ha realizado una recuperación incompleta la BD debe ser abierta con el
comando alter database open resetlogs, lo que produce que los redo log no
aplicados no se apliquen nunca y se inicialice la secuencia de redo log en el fichero
de control. Existen tres opciones para parar la recuperación:
• UNTIL CANCEL permite recuperar un redo log cada vez, parando cuando se teclea
CANCEL.
• UNTIL TIME permite recuperar hasta un instante dado dentro de un fichero de
redo log
• UNTIL CHANGE permite recuperar hasta un SCN dado. USING BACKUP
CONTROLFILE utiliza una copia de seguridad del fichero de control para gobernar
la recuperación
 RECUPERACIÓN DE LA BASE DE DATOS

• El SCN se incrementa cada vez que se hace un cambio en la base, marcando

de esta manera, un punto lógico en el tiempo. Por ejemplo, cada vez que
alguien hace un COMMIT en la base, el SCN se incrementa. El SCN permite
a Oracle dar un orden cronológico a los eventos que ocurren dentro de
la base de datos.
 BIBLIOGRAFÍA

• Transacciones con PL/SQL, Pedro Herrarte Sánchez, (2006), extraído de :

http://www.devjoker.com/contenidos/articulos/63/Transacciones-con-
PLSQL.aspx

• Transacciones, (2012), extraído de:

https://dosideas.com/noticias/base-de-datos/973-acid-en-las-bases-de-datos