Conceptos Avanzados de Bases de Datos

Presentado por:

Sebastian Tauta Rodriguez

Carlos Wilches Rivera
Josthman Granados Vargas
Schneider Sarria Jimenez

SENA - Anlisis y Desarrollo de Sistemas de Informacin

Ficha 576038
2014

Conceptos Avanzados de Bases de Datos

Presentado por:

Sebastian Tauta Rodriguez

Carlos Wilches Rivera
Josthman Granados Vargas
Schneider Sarria Jimenez

Presentado a:
Ing. Frank Castillo

SENA - Anlisis y Desarrollo de Sistemas de Informacin

Ficha 576038
2014

TIPOS DE BLOQUEOS EN BASES DE DATOS

El mecanismo de bloqueo en la base de datos por defecto es un bloqueo a nivel de

fila. Las diferentes transacciones pueden actualizar diferentes filas dentro de la
misma tabla sin interferirse unas a otras. A pesar de que el modo por defecto de
bloque es a nivel fila, Oracle 10 permite bloqueos a un nivel superior si son
necesarios.

EXCLUSIVE MODE

Cualquier transaccin que intenta actualizar una fila en la tabla bloqueada debe
esperar encolada, hasta que la transaccin que ha bloqueado la tabla termine. Es
la forma ms estricta de bloqueo.

SQL> LOCK TABLE hr.employees IN EXCLUSIVE MODE;

ROW SHARE Permite el acceso concurrente a la tabla bloqueada, pero

prohbe a las sesiones hacer un bloqueo en EXCLUSIVE MODE.

ROW EXCLUSIVE Lo mismo que ROW SHARE, pero tambin prohbe hacer un
bloque ROW SHARE, Este es el tipo de bloqueo que se obtiene automticamente
cuando se hace un update, insert o delete.

SHARED
Permite concurrentes pero prohbe updates a una tabla bloqueada. Este tipo de
bloque se produce automticamente cuando se crea un ndice o una tabla. Prohbe
a otras sesiones bloquear la tabla en modo SHARE o actualizar registros.

SHARE ROW EXCLUSIVE:

Permite consultar toda la tabla y permite a los otros consultar registros dentro de la
tabla, preo prohbe a otros usuarios bloquear la tabla en modo SHARE o realizar
actualizaciones de registros.

 EXCLUSIVE

Permite consultar la tabla bloqueada, pero prohbe cualquier tipo de actividad en

ella. Este tipo de bloqueos se utiliza para el borrar una tabla (drop).

Como cualquier peticin de bloqueo, los bloqueos manuales esperan encolados

hasta que todas las sesiones previamente tenan bloqueos o que los haban
solicitado, los deshagan. El comando LOCK acepta un argumento NOWAIT que
permite regresar el control inmediatamente, si la tabla est bloqueada por otra
sesin.

SQL> LOCK TABLE hr.employees IN SHARE MODE NOWAIT;

LOCK TABLE hr.employees IN SHARE MODE NOWAIT
Bloqueos en sentencias DML
Las sentencias DML, realizan dos tipos de bloqueos:
Un bloqueo rew-exclusive en cada fila o filas que queremos actualizar, Habr un
solo bloqueo row-exclusive independientemente del nmero de filas que queramos
cambiar.
Y un bloqueo shared a nivel tabla en la tabla que vamos a actualizar. Esto para
prevenir que otra sesin bloquee la tabla completa, (puede darse el caso en un drop
y en trncate), mientras se realiza el cambio.

BLOQUEOS EN SENTENCIAS DDL

Para ejecutar una sentencia DDL requiere un bloqueo exclusivo en el objeto a

modificar. Este no se puede obtener hasta que todas las transacciones DML contra
la tabla hayan finalizado, liberando sus bloqueos exclusivos y shared. El bloqueo
exclusivo necesario para cualquier sentencia DDL se solicita automticamente, pero
si no se puede obtener, normalmente porque otra sesin tenga bloqueada la tabla
termina inmediatamente con error.

 BLOQUEOS COMPARTIDOS

Los bloqueos compartidos (S) permiten que varias transacciones simultneas lean
(SELECT) un recurso en situaciones de control de simultaneidad pesimista. Para
obtener ms informacin, vea Tipos de control de simultaneidad. Ninguna otra
transaccin podr modificar los datos mientras el bloqueo compartido (S) exista en
el recurso. Los bloqueos compartidos (S) en un recurso se liberan tan pronto como
finaliza la operacin de lectura, a menos que se haya establecido el nivel de
aislamiento de la transaccin como REPEATABLE READ o ms alto, o bien se
utilice una sugerencia de bloqueo para mantener los bloqueos compartidos (S)
durante la transaccin.

BLOQUEOS DE ACTUALIZACIN

Los bloqueos de actualizacin (U) evitan una forma comn de interbloqueo. En una
transaccin de lectura repetible o serializable, la transaccin lee los datos, adquiere
un bloqueo compartido (S) en el recurso (pgina o fila) y, a continuacin, modifica
los datos, lo que requiere una conversin del bloqueo en un bloqueo exclusivo (X).
Si dos transacciones adquieren bloqueos compartidos en un recurso y, a
continuacin, intentan actualizar los datos simultneamente, una de ellas intenta
convertir el bloqueo en un bloqueo exclusivo (X). La conversin de bloqueo
compartido en exclusivo debe esperar, ya que el bloqueo exclusivo de una
transaccin no es compatible con el bloqueo compartido de la otra. Por tanto, se
produce una espera de bloqueos. La segunda transaccin intenta adquirir un
bloqueo exclusivo (X) para realizar su actualizacin. Debido a que ambas
transacciones intentan convertir los bloqueos en exclusivos (X) y cada una espera
a que la otra libere su bloqueo de modo compartido, se produce un interbloqueo.
Para evitar este posible problema de interbloqueo, se utilizan los bloqueos de
actualizacin (U). Dos transacciones no pueden obtener simultneamente un
bloqueo de actualizacin (U) para un recurso. Si una transaccin modifica un
recurso, el bloqueo de actualizacin (U) se convierte en un bloqueo exclusivo (X).

BLOQUEOS EXCLUSIVOS

Los bloqueos exclusivos (X) evitan que transacciones simultneas tengan acceso a
un recurso. Al utilizar un bloqueo exclusivo (X), el resto de las transacciones no

pueden modificar los datos; las operaciones de lectura slo se pueden realizar si se
utiliza la sugerencia NOLOCK o el nivel de aislamiento de lectura no confirmada.
Las instrucciones para modificar datos, como INSERT, UPDATE y DELETE
combinan las operaciones de modificacin con las de lectura. En primer lugar, la
instruccin lleva a cabo operaciones de lectura para adquirir los datos antes de
proceder a ejecutar las operaciones de modificacin necesarias. Por tanto, las
instrucciones de modificacin de datos suelen solicitar bloqueos compartidos y
exclusivos. Por ejemplo, una instruccin UPDATE puede modificar las filas de una
tabla a partir de una combinacin con otra tabla. En este caso, la instruccin
UPDATE solicita bloqueos compartidos para la filas ledas en la tabla de
combinacin, adems de bloqueos exclusivos para las filas actualizadas.

BLOQUEOS CON INTENCIN

Motor de base de datos utiliza bloqueos con intencin para proteger la aplicacin de
un bloqueo compartido (S) o exclusivo (X) en un recurso inferior en la jerarqua de
bloqueos. Los bloqueos con intencin se denominan as porque se adquieren antes
que los bloqueos de los niveles inferiores y, por lo tanto, sealan la intencin de
aplicar bloqueos en un nivel inferior.
Los bloqueos con intencin se utilizan con dos fines:
Para evitar que otras transacciones modifiquen el recurso de nivel superior de forma
que invaliden el bloqueo del nivel inferior.
Para mejorar la eficacia de Motor de base de datos para detectar conflictos de
bloqueo en el nivel superior de granularidad.
Por ejemplo, un bloqueo con intencin compartida para el nivel de tabla se solicita
antes que los bloqueos compartidos (S) para las pginas o filas de la tabla.
Establecer un bloqueo con intencin en una tabla evita que otra transaccin
adquiera un bloqueo exclusivo (X) para la tabla que contiene esa pgina. Los
bloqueos con intencin mejoran el rendimiento, porque Motor de base de datos
examina los bloqueos con intencin slo en el nivel de tabla para determinar si una
transaccin puede adquirir un bloqueo de dicha tabla de forma segura. Esto elimina
la necesidad de examinar cada bloqueo de fila o de pgina de la tabla para
determinar si una transaccin puede bloquear toda la tabla.

 BLOQUEOS DE ESQUEMA

Motor de base de datos utiliza bloqueos de modificacin del esquema (Sch-M)

cuando se realiza una operacin de lenguaje de definicin de datos (DDL) en tablas
como, por ejemplo, agregar una columna o quitar una tabla. Mientras se conserva,
el bloqueo Sch-M evita el acceso simultneo a la tabla. Esto significa que el bloqueo
Sch-M bloquea todas las operaciones externas hasta que el bloqueo se libera.
Algunas operaciones del lenguaje de manipulacin de datos (DML), como el
truncamiento de tablas, utilizan los bloqueos Sch-M para impedir el acceso a las
tablas afectadas por operaciones simultneas.
Motor de base de datos usa bloqueos de estabilidad del esquema (Sch-S) al
compilar y ejecutar consultas. Los bloqueos Sch-S no impiden los bloqueos de
transacciones, incluidos los bloqueos exclusivos (X). Por tanto, otras transacciones,
incluidas las que tienen bloqueos X de una tabla, pueden seguir ejecutndose
mientras se compila una consulta. No obstante, en la tabla no se pueden realizar
operaciones DDL simultneas ni operaciones DML simultneas que adquieren
bloqueos Sch-M.

BLOQUEOS DE ACTUALIZACIN MASIVA

Motor de base de datos utiliza bloqueos de actualizacin masiva (BU) cuando se

copian datos en una tabla de forma masiva, y se especifica la
sugerencia TABLOCK o se establece la opcin de tabla table lock on bulk
load con sp_tableoption. Los bloqueos de actualizacin masiva (BU) permiten que
varios subprocesos copien datos de forma masiva y simultnea en la misma tabla,
pero impiden que otros procesos que no estn copiando datos de forma masiva
tengan acceso a la tabla.

BLOQUEOS DE INTERVALO DE CLAVES

Los bloqueos de intervalo de claves protegen un intervalo de filas incluidas

implcitamente en un conjunto de registros que se leen mediante una instruccin
Transact-SQL mientras se utiliza el nivel de aislamiento de transacciones
serializables. El bloqueo de intervalo de claves evita lecturas ficticias. Al proteger
los intervalos de claves entre filas, tambin se evitan inserciones o eliminaciones
ficticias en los conjuntos de registros a los que obtienen acceso las transacciones.

El bloqueo pesimista es la tcnica por la cual los datos son bloqueados previos a su
modificacin para evitar que nadie los modifique. Una vez que los datos a actualizar
han sido bloqueados la aplicacin puede acometer los cambios, con commit o
rollback, en ese caso el bloqueo es automticamente eliminado. Si alguien intenta
adquirir un bloqueo de los mismos datos durante el proceso ser obligado a esperar
hasta que la primera transaccin finalice.
Esta tcnica es muy simple pero tiene dos problemas fundamentales:
Bloqueo: un usuario selecciona un registro para actualizar, y entonces abandona
la operacin. Todos los usuarios que necesitan actualizar ese registro tienen que
esperar hasta que se complete la transaccin, o hasta que se mate y finalice el
bloqueo.
Deadlock: Si los usuarios A y B estn 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
quedaran en espera indefinidamente, dando lugar a un Deadlock.
En general los Sistemas RDBMS ofrecen clusulas para este bloqueo. Oracle
soporta bloqueo pesimista a nivel de fila. La sentencia estndar 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 adems tiene el bloqueo SELECT FOR UPDATE NO WAIT, de modo que
Oracle causar una excepcin cuando una fila bloqueada es seleccionada. Esto
puede ser til si no se quiere bloquear un usuario para un tiempo indefinido.

EL BLOQUEO OPTIMISTA

No bloquea los registros que se van a actualizar y asume que los datos que estn
siendo actualizados no van a cambiar desde que se han ledo. 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 estn siendo escritos son consistentes con los ledos en primera
instancia, es decir que ninguna otra transaccin ha actualizado los datos despus
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.

 PROCEDIMIENTOS ALMACENADOS

Un procedimiento almacenado es un programa (o procedimiento) almacenado

fsicamente en una base de datos. Su implementacin vara de un gestor de bases
de datos a otro.
La ventaja de un procedimiento almacenado es que al ser ejecutado, en respuesta
a una peticin de usuario, es ejecutado directamente en el motor de bases de datos,
el cual usualmente corre en un servidor separado. Como tal, posee acceso directo
a los datos que necesita manipular y slo necesita enviar sus resultados de regreso
al usuario, deshacindose de la sobrecarga resultante de comunicar grandes
cantidades de datos salientes y entrantes.

USOS TPICOS PARA PROCEDIMIENTOS ALMACENADOS

Validacin de datos siendo integrados a la estructura de base de datos (los

procedimientos almacenados utilizados para este propsito a menudo son llamados
disparadores; (triggers), o encapsular un proceso grande y complejo. El ltimo
ejemplo generalmente ejecutar ms rpido como un procedimiento almacenado
que de haber sido implementado como, por ejemplo, un programa corriendo en el
sistema cliente y comunicndose con la base de datos mediante el envo de
consultas SQL y recibiendo sus resultados.

USO

Se aplican en la validacin de datos, integrados dentro de la estructura del banco

de datos. Los procedimientos almacenados usados con tal propsito se llaman
comnmente disparadores, o triggers.

PROCEDIMIENTOS ALMACENADOS EN MYSQL

Los procedimientos almacenados requieren la tabla Proc en la base de

datos MySQL

 TRIGGERS (DISPARADORES) BASES DE DATOS

Es un procedimiento que se ejecuta cuando se cumple una condicin establecida al

realizar una operacin. Dependiendo de la base de datos, los triggers pueden ser
de insercin (INSERT), actualizacin (UPDATE) o borrado (DELETE). Algunas
bases de datos pueden ejecutar triggers al crear, borrar o editar usuarios, tablas,
bases de datos u otros objetos.

CARACTERSTICAS

Cada trigger implementa una interfaz concreta, as pues para gestionar un trigger
sobre un objeto que implemente la interfaz Device dispone de una interfaz
DeviceTrigger la cual define los siguientes mtodos.

Public void run (Device device)

Public void error (Device device)

Crear un Trigger para insertar un pedido de algn producto cuando la cantidad de

ste, en nuestro almacn, sea inferior a un valor dado

DISPARADORES EN MYSQL

El estndar SQL: 2003 requiere que los disparadores den a los programadores
acceso a las variables de un registro utilizando una sintaxis como REFERENCING
NEW AS n. Por ejemplo, si un disparador est monitoreando los cambios en la
columna salario.

Como en MySQL las sentencias se ejecutan luego de escribir el signo punto y coma
(;), cabe destacar que para crear un disparador en MySQL, antes se escribe la
sentencia DELIMITER seguida de un carcter tal como |, la cual asigna la funcin
del punto y coma (;) a otro carcter permitiendo que el disparador sea escrito usando
los punto y comas sin que se ejecute mientras se escribe; despus de escrito el
disparador se escribe nuevamente la sentencia DELIMITER ; para asignar al punto
y coma su funcin habitual.

DISPARADORES EN POSTGRESQL

Desde 1997 PostgreSQL soporta el uso de disparadores, estos pueden anexarse a

las tablas pero no a las vistas; aunque a las vistas se les pueden crear reglas.
Al igual que en MySQL los disparadores de PostgreSQL se pueden activar luego de
sentencias INSERT, UPDATE o DELETE
Cuando hay varios disparadores, se activan en orden alfabtico.
Adems de permitir el uso de funciones en el lenguaje nativo de PostgreSQL,
PL/PgSQL, los disparadores tambin permiten invocar funciones escritas en otros
lenguajes como PL/Perl.
En Postgres un disparador ejecuta una funcin la cual contiene el cdigo de lo que
se requiere, esto difiere del mtodo expuesto anteriormente para MySQL que
escribe el cdigo a ejecutarse dentro del mismo disparador.