1

MATERIAL PARA LA CLASE DE BASE DE DATOS II, MANEJO DE BLOQUEOS, LIC. EDUARDO SANTOS.
INFORMATICA ADMINISTRATIVA, UNAH

Monitoreo de bloqueo y Resolver conflictos de bloqueo

En cualquier base de datos que tenga más de un usuario, eventualmente tendrá que lidiar con conflictos de bloqueo
cuando dos o más usuarios intentan cambiar la misma fila en la base de datos. En esta sección, presentamos una
descripción general de cómo funciona el bloqueo en la base de datos Oracle, cómo los usuarios se ponen en cola para un
recurso en particular una vez que está bloqueado, y cómo Oracle clasifica los tipos de bloqueo en la base de datos.

Al final de esta sección, le mostramos varias formas de detectar y resolver problemas de bloqueo; También cubrimos un
tipo especial de situación de bloqueo: el deadlock.

Comprensión de bloqueos y transacciones

Los bloqueos evitan que varios usuarios cambien los mismos datos al mismo tiempo. Antes de uno o más filas de una tabla
se pueden cambiar, el usuario que ejecuta la instrucción DML debe obtener un bloqueo en la fila o filas: un bloqueo le da
al usuario control exclusivo sobre los datos hasta que el usuario se haya comprometido o revierte la transacción que está
cambiando los datos. En Oracle 10g, una transacción puede bloquear una fila, varias filas o una tabla completa. A pesar
de que puede bloquear filas manualmente, Oracle puede bloquear automáticamente las filas necesarias al mínimo posible
nivel para garantizar la integridad de los datos y minimizar los conflictos con otras transacciones que puedan necesitar
para acceder a otras filas en la tabla.

En la Tabla 8.1, ambas actualizaciones de la tabla EMPLEADOS vuelven al símbolo del sistema inmediatamente después
de la ACTUALIZACIÓN porque los bloqueos están en diferentes filas en la tabla EMPLEADOS y ninguno la sesión está
esperando que se libere el otro bloqueo.

CUADRO 8. 1 Transacciones concurrentes en diferentes filas de la misma tabla

Las consultas SELECT nunca requieren de un bloqueo. Incluso si otra transacción ha bloqueado varias filas o una tabla
completa, una consulta siempre tendrá éxito en traer los datos, utilizando la imagen de prebloqueo de los datos
almacenados en el UNDO Tablespace. Si varios usuarios requieren un bloqueo en una fila o filas en una tabla, el primer
usuario que solicita el bloqueo lo obtiene, y los usuarios restantes se ponen en cola usando un método de primero en
entrar, primero en salir (FIFO). En un SQL> símbolo del sistema, una instrucción DML (INSERT, UPDATE, DELETE o MERGE)
que está esperando por un bloqueo sobre un recurso pareciera que el programa está Colgado, a menos que la palabra
clave NOWAIT se use en una instrucción LOCK.

Al final de una transacción, cuando se emite un COMMIT o un ROLLBACK (ya sea explícitamente por el usuario o
implícitamente cuando la sesión termina de manera normal o anormal), todos los bloqueos son liberados.

Maximizando la concurrencia de datos

2
MATERIAL PARA LA CLASE DE BASE DE DATOS II, MANEJO DE BLOQUEOS, LIC. EDUARDO SANTOS.
INFORMATICA ADMINISTRATIVA, UNAH

Las filas de una tabla pueden bloquearse explícitamente por el usuario al comienzo de una transacción o implícitamente
por Oracle, generalmente a nivel de fila, dependiendo de la operación. Si una tabla debe ser
bloqueada por razones de rendimiento (lo cual es raro), puede usar el comando SELECT … FOR UPDATE,

Puede obtener explícitamente bloqueos en filas individuales utilizando la instrucción SELECT ... FOR UPDATE,
como puedes ver en el siguiente ejemplo:

SQL> select * from hr.employees

2 where manager_id = 100
3 for update;

Esta consulta no solo muestra las filas que satisfacen las condiciones de la consulta, sino que también bloquea las filas
seleccionadas y evita que otras transacciones bloqueen o actualicen estas filas hasta que un COMMIT o un ROLLBACK Se
produce.

Detectar y resolver conflictos de bloqueo

Aunque los bloqueos son una ocurrencia común y a veces inevitable en muchas bases de datos, generalmente se resuelven
esperando en la cola. En algunos casos, es posible que deba resolver el problema de bloqueo manualmente (por ejemplo,
si un usuario realiza una actualización a las 4:59 p.m. y no realiza un COMMIT antes de salir del trabajo ese día).
En las próximas secciones, describiremos con más detalle algunas de las razones porque ocurren los conflictos de bloqueo
y cómo detectar conflictos de bloqueo y discutir un tipo de conflicto de bloqueo más específico y serio: un punto muerto
(deadlock).

Comprender los conflictos de bloqueo

Además del usuario proverbial que hace un cambio a las 4:59 p.m. y se olvida de realizar un COMMIT antes de partir ese
día, otros conflictos de bloqueo más típicos son causados por transacciones de larga duración que realizan cientos, miles
o incluso cientos de miles de comandos DML en la ejecución por lotes durante la noche pero que no ha terminado de
actualizar las tablas cuando comienza el día hábil normal.

Las transacciones no confirmadas de los trabajos por lotes durante la noche pueden bloquear tablas que deben ser
actualizadas por el personal administrativo durante el día hábil, lo que provoca un conflicto de bloqueo.

Otra causa típica de conflictos de bloqueo es usar niveles de bloqueo innecesariamente altos. En la barra lateral
"Aplicaciones empaquetadas y bloqueo" anteriormente en este capítulo, describimos una aplicación de terceros que
rutinariamente bloqueaba recursos a nivel de tabla en lugar de a nivel de fila para ser compatible con todas las bases de
datos basadas en SQL del mercado. Los desarrolladores pueden codificar innecesariamente actualizaciones a tablas con
niveles de bloqueo más altos que los requeridos por Oracle.

Detectar conflictos de bloqueo

La detección de bloqueos en Oracle se hace consultando las vistas del diccionario de datos: V$SESSION,
V$TRANSACTION, V$LOCK y V$LOCKED_OBJECT para ver quién está bloqueando que recurso.

En la Figura 8.5, puede ver las tablas bloqueadas por el usuario SCOTT después de ejecutar la siguiente declaración:
3
MATERIAL PARA LA CLASE DE BASE DE DATOS II, MANEJO DE BLOQUEOS, LIC. EDUARDO SANTOS.
INFORMATICA ADMINISTRATIVA, UNAH

FIGURA 8 . 5 La pantalla Bloqueos de base de datos en EM Database Control

SCOTT tiene un bloqueo EXCLUSIVO en la tabla EMPLEADOS y DEPARTAMENTOS. Puedes explorar hacia abajo en el objeto
bloqueado haciendo clic en uno de los enlaces en la columna Nombre del objeto; similar, puede revisar otra información
sobre la sesión de SCOTT haciendo clic en uno de los enlaces de la sesión Columna de identificación.

Comprender y resolver los deadlocks

Al resolver un conflicto de bloqueo, el usuario puede dar COMMIT o ROLLBACK a la transacción actual. Si no puede
contactar al usuario que está causando el bloqueo y es una emergencia, puede seleccionar la sesión que mantiene el
bloqueo y matar la sesion (Kill Session) desde la pantalla Bloqueos de base de datos del EM Control (consulte Figura 8.5,
anteriormente en este capítulo) o bien por línea de comandos. La próxima vez que el usuario cuya sesión ha sido eliminada
4
MATERIAL PARA LA CLASE DE BASE DE DATOS II, MANEJO DE BLOQUEOS, LIC. EDUARDO SANTOS.
INFORMATICA ADMINISTRATIVA, UNAH

intente ejecutar un comando, el mensaje de error ORA-00028: su sesión ha sido cancelada será devuelto a ese usuario,
esta es una opción e último recurso: todas las sentencias ejecutadas en la sesión desde el último COMMIT se pierden.

Un tipo más grave de conflicto de bloqueo es un punto muerto (deadlock). Un punto muerto es un tipo especial de
conflicto de bloqueo en el que dos o más usuarios esperan un recurso bloqueado por ellos mismos mutuamente. Como
resultado, ninguna transacción puede completarse sin algún tipo de intervención: la sesión que primero detecta el punto
muerto (deadlock) revierte la sentencia que espera por el recurso bloqueado con el mensaje de error:
ORA-00060: Deadlock detected while waiting for resource.
En la Tabla 8.3, dos sesiones intentan actualizar una fila bloqueada por la otra sesión.

Tabla 8.3 Escenario de punto muerto (Deadlock)

Después de que se emite el mensaje de error a las 11:45, la segunda ACTUALIZACIÓN para la Sesión 1 no tiene éxito; sin
embargo, se completa la segunda ACTUALIZACIÓN para la Sesión 2, y el usuario en la Sesión 2 ahora puede enviar otra
declaración DML o emitir un COMMIT o ROLLBACK. El usuario en la sesión 1 tendrá que volver a emitir la segunda
ACTUALIZACIÓN, pues esta se pierde.