1.

ADMINISTRACION DE UNA BASE DE DATOS

1. PRINCIPALES FUNCIONES DEL ADMINISTRADOR

A continuacin se presentan las principales responsabilidades del Administrador de
Bases de datos:

Definir procedimientos de respaldo y de recuperacin de las Bases de datos.
Definir los esquemas de seguridad y de integridad que tendrn las bases de datos.
Supervisar el desempeo de las aplicaciones que corren bajo la base de datos.
Colaborar con el equipo de desarrollo en la definicin del modelo lgico y fsico que
tendr la Base de datos, identificando las entidades que interesan a la empresa y
que atributos tendrn, restricciones que se implementarn, niveles de seguridad,
sistema de concurrencia, entre otros aspectos.
Asesorar al usuario canalizando sus inquietudes acerca de los datos contenidos en
las tablas y la forma de accederlos, concediendo o revocando los permisos
necesarios para manejar estos datos.
Asesorar a la empresa en la adquisicin de nueva tecnologa como: generadores de
informes ms giles, graficadores y herramientas de desarrollo.

La seguridad se refiere a la proteccin que se deber tener contra accesos de
usuarios no autorizados a la informacin contenida all. La integridad se refiere a los
controles que se deben disear para que las transacciones que realicen los usuarios
cumplan con condiciones preestablecidas y eviten posibles inconsistencias o errores de
digitacin para impedir que la base de datos tome estados invlidos.

El administrador de una base de datos, como recin se expres, debe supervisar el
desempeo de las aplicaciones sobre la base de datos para que el usuario final tenga la
informacin en forma oportuna. Hay muchos factores que pueden incidir en una baja
en el desempeo, como por ejemplo:

Una organizacin fsica inadecuada de la base de datos.
El crecimiento acelerado de las tablas que la componen.
Un sistema de concurrencia mal diseado.
Cambios en el hardware o en el software.

Por lo anterior, el administrador debe estar monitoreando la base de datos
constantemente para hacer los ajustes necesarios.
La Integridad

La integridad implica asegurarse de que la informacin contenida en la base de datos
est correcta. Se debe verificar que las transacciones que realicen los usuarios
autorizados para ello, cumplan con unas precondiciones o postcondiciones que
mantengan la base de datos en un estado vlido.

La integridad se puede clasificar en:

Integridad de dominio: significa que debemos velar porque cada valor o instancia de
un atributo est en el dominio o conjunto de valores posibles para ese atributo.

El dominio puede ser:

Continuo: se dice que un atributo tiene un dominio continuo cuando toma cualquier
valor en un rango dado. Ejemplos: el peso de un producto, el tiempo de
calentamiento y la demanda de energa.
Discreto: se dice que un atributo tiene un dominio discreto cuando puede tomar
valores de una lista dada. Ejemplos: el estado civil, el sexo, la profesin y la
dependencia donde trabaja un empleado.

El dominio tambin puede subdividirse en:

Dinmico: Se caracteriza porque puede variar a travs del tiempo. Ejemplo:
dependencia, sueldo.
Esttico: No varan con el tiempo. Ejemplos: el sexo (hay casos excepcionales) o la
cdula.

Para velar por la integridad de dominio podemos apoyarnos en el tipo de datos que le
asociemos a cada atributo y en las funciones de chequeos que se puedan definir con el
DBMS utilizado. Cuando tengamos atributos con dominio dinmico y discreto lo ms
aconsejable para velar por la integridad de dominio, consiste en crear tablas de
referencia y luego se crean restricciones de clave fornea. Cuando se trate de un
dominio dinmico y continuo, se pueden definir variables dentro de paquetes que se
usan dentro de disparadores o triggers.

Integridad de entidad: este tipo de integridad vigila que toda instancia de una
entidad se distinga de las dems, inequvocamente.
Las entidades dentro de una base de datos corresponden a entidades del mundo real
donde sus instancias son completamente diferenciables; por ello, cada instancia debe
poseer un identificador nico y no nulo denominado clave primaria en el modelo
relacional. El mecanismo empleado por casi todos los DBMS para garantizar la
integridad de entidad es la restriccin impuesta a los atributos que forman parte del
identificador nico de la entidad con la clusula PRIMARY KEY cuando se define una
tabla.

Otros identificadores nicos, que no se reconocen en el modelo E-R extendido por
Barker, se convierten en claves candidatas en el modelo relacional y se vigilan con la
restriccin UNIQUE cuando se define una relacin o tabla.

Integridad Referencial: Este tipo de integridad vigila que un dato que sirva de
referencia en una relacin o tabla del modelo relacional, de verdad exista en la tabla
referenciada. El dato (o conjunto de datos) de referencia es llamado clave fornea y
es clave primaria en otra entidad.

No todos los DBMS nos permiten definir la integridad referencial en el momento de
creacin de una tabla, a travs de la clusula FOREIGN KEY que se aade al atributo
que es una clave fornea. Entonces, en ese caso, es necesario crear una pieza de
cdigo o trigger que permita definir la regla de integridad necesaria.

Adicionalmente, se debe definir de antemano cmo vamos a proceder cuando se deba
eliminar o actualizar cuando existe una clave fornea.

Por ejemplo:

Qu sucedera si se tuviese que eliminar a un proveedor que por lo menos tiene un
pedido a su nombre?

Hay tres alternativas:

- El rechazo: La transaccin ser rechazada si al menos existe un pedido. Esto
significa que no se podr eliminar un proveedor que tenga pedidos.
- La eliminacin en cascada: se eliminan los pedidos que corresponden a ste y a
continuacin, se elimina al proveedor.
- Asignacin de nulos a los pedidos que tiene ste y posteriormente se elimina al
proveedor; pero esto no se podra hacer si previamente se ha fijado que ningn
pedido podr estar en el sistema sin tener un proveedor asociado.

Se escoger en cada caso particular, obviamente, la alternativa que ms se ajuste a las
reglas de la organizacin. ORACLE, admite que cuando especifiquemos un atributo
como clave fornea podamos elegir entre las opciones de rechazar la eliminacin con la
palabra RESTRICT que se coloca como calificador de una clave fornea cuando se crea
una tabla, que por defecto es la activa, o la eliminacin en cascada con la palabra
CASCADE.

En la siguiente definicin de la tabla de empleados, por ejemplo, se han definido varias
reglas de integridad:

CREATE TABLE estudiante ( cc VARCHAR2(8) PRIMARY KEY,
nombre VARCHAR2(40) NOT NULL,
idcarrera CHAR(2) NOT NULL,
fecha_ing DATE NOT NULL,
telefono VARCHAR2(7),
sexo CHAR(1) NOT NULL CONSTRAINT CHECK IN (F,M),
CONSTRAINT cfcarrera (idcarrera) FOREIGN KEY
REFERENCES carrera(id) ON DELETE CASCADE);

As mismo, como en el caso de la eliminacin, debemos decidir que accin tomar cuando
se actualiza un atributo clave fornea. Se debe especificar el rechazo o la
actualizacin en cascada. A continuacin se muestra un ejemplo de cmo sera una
actualizacin en cascada implementada con un trigger o disparador elaborado con
PL/SQL para una base de datos ORACLE.

CREATE TRIGGER cambio_cascada
BEFORE UPDATE OF id ON depto
FOR EACH ROW
BEGIN
UPDATE emp
SET iddepto = :new.id
WHERE iddepto = :old.id;
END;

Integridad Definida por el Usuario: son reglas establecidas por el propio diseador
de la base de datos y que corresponden a polticas o normas de la empresa.

Algunas de estas reglas se pueden especificar en la base de datos, sin tener que
definirlas en las aplicaciones. Esto sera lo ideal no slo para velar por la integridad
de la base de datos, sin importar el ambiente desde el cual se est teniendo acceso a
la base de datos, sino por la reutilizacin de cdigo que adems permite una mayor
adaptabilidad del sistema a los cambios organizacionales.

Ejemplos:

CREATE TRIGGER cambios_confiables
BEFORE INSERT OR UPDATE OR DELETE ON emp
FOR EACH ROW
BEGIN
IF (TO_CHAR (SYSDATE,'DY') IN ('SAT', 'SUN')
OR (TO_NUMBER (SYSDATE,'HH24') NOT BETWEEN 8 AND 18
THEN
RAISE_APPLICATION_ERROR (-20504,
'Solo pueden cambiar datos a los empleados en las horas hbiles del negocio');
END IF;
END;

CREATE TRIGGER chequeo_sueldo
BEFORE INSERT OR UPDATE OF sueldo ON emp
FOR EACH ROW
WHEN (:new.cargo <> '01') /*exceptuando al presidente*/
DECLARE
v_min guia_salarial.minimo%TYPE;
v_max guia_salarial.maximo%TYPE;
BEGIN
SELECT minimo,maximo
INTO v_min,v_max
FROM guia_salarial
WHERE cargo = :new.cargo;
IF :new.sueldo < v_min or :new.sueldo > v_max THEN
RAISE_APPLICATION_ERROR (-20505,
'El sueldo ' || TO_char (:new.sueldo) ||
' est fuera del permitido para el empleado con id ' || :new.id);
END IF;
END;


Seguridad

La seguridad se refiere a la proteccin de los datos contra acceso no autorizado.
El objeto de datos que puede requerir proteccin, va desde la base de datos completa,
de algunas tablas hasta una celda especfica de una tabla. El alcance de la proteccin
se conoce como granularidad.

Diferentes usuarios pueden tener diferentes derechos sobre los mismos objetos. Los
manejadores de bases de datos relacionales permiten que el administrador pueda
restringir el acceso a ciertos datos que no competen con las funciones del usuario.

La seguridad se logra utilizando bsicamente dos mecanismos:

Vistas: Permite que se limite la visin del usuario a ciertas columnas o filas de
determinadas tablas.

El sistema de privilegios: el cual el administrador puede conceder o revocar
privilegios sobre los objetos de la base de datos a los distintos usuarios.

La definicin de estos derechos, no es competencia del administrador, es ms parte
de las polticas de la empresa, l es un ejecutor y auditor de las mismas.
Los DBMS tienen los mecanismos que le permiten al administrador implementar estas
seguridades, usando principalmente ordenes SQL.

Otros dos mecanismos para la proteccin del acceso no autorizado, que tambin debe
ser tenidos en cuenta, son:

La criptografa: que consiste en cifrar los datos para hacerlos ilegibles mediante
algoritmos altamente sofisticados de tal manera que slo los usuarios autorizados
puedan descifrarlos. Para encriptar o cifrar los datos, entonces, se necesita de un
algoritmo de encriptamiento y de otro para el desencriptamiento.

El control de la inferencia: consiste en impedir que un usuario pueda deducir
informacin, sin tener autorizacin, a partir de los datos a los que s tiene acceso.

A continuacin se detallarn los mecanismos de seguridad mediante vistas y
privilegios.

VISTAS


Del mismo modo que una cmara solo captura una parte del escenario, una vista es una
presentacin restringida de los datos en una base de datos. Una vista es una orden de
consulta de datos almacenada que selecciona datos guardados en tablas. Esto es, una
vista es una orden SELECT sin la clusula ORDER BY. La vista no guarda datos, lo que
almacena realmente es el texto SQL de la orden SELECT.

El formato para la creacin de una vista es el siguiente:

CREATE VIEW <nombre vista> [ (nombrecol1, nombrecol2...) ]
AS SELECT ......
[WITH CHECK OPTION]

Algunos ejemplos son:

CREATE VIEW EMPLEADO
AS SELECT NOMBRE, CARGO, FECHA_ING FROM EMP;

CREATE VIEW V_VUELOS
(PROCEDENCIA, DESTINO, DURACION)
AS SELECT ORIGEN, DESTINO, FECHA_INI - FECHA_FIN
FROM VUELOS
WHERE ORIGEN NOT LIKE 'IB%'
WITH CHECK OPTION

Obsrvese, en el ltimo ejemplo, que en las vistas se pueden cambiar los nombres de
los atributos especificando los nuevos entre parntesis, despus del nombre de la
vista.

En Oracle, se puede utilizar el comando SQL*PLUS DESC, para describir una vista.
Los tipos de datos sern los mismos de las tablas bases.

Cuando se crea un vista, se puede usar en una orden SQL como una tabla bsica:


SELECT *
FROM V_VUELOS
WHERE ORIGEN<>'MADRID';


Sin embargo, el DBMS la interpreta esta misma orden, como aparece a continuacin.

SELECT *
FROM (SELECT ORIGEN, DESTINO
FROM VUELOS
WHERE NUM_VUELO NOT LIKE 'IB%' )
WHERE ORIGEN<>'MADRID';

Para la eliminacin de una vista se usa el comando DROP; as, por ejemplo:

DROP VIEW V_VUELOS;

Las vistas se utilizan principalmente con el propsito de ver datos pero tambin
permiten la actualizacin de datos en las tablas bsicas, dependiendo como hayan sido
construidas. Bajo ninguna circunstancia se puede borrar una tupla desde una vista.

Las vistas son tiles, adems, por otras razones:

Para simplificar comandos. Si los usuarios no saben plantear ordenes SQL
complejas o necesitan ver frecuentemente datos calculados o derivados, una vista
puede ser muy til.
Para lograr independencia lgica de datos, ocultando como est guardada la
informacin.

El sistema de privilegios

Para poder tener acceso a una base de datos, el DBA debe crear usuarios que sern
validados con una contrasea, cada vez intenten conectarse. Un nombre-de-usuario
(username) es el conjunto nominado de objetos que un usuario guarda juntos; llamado
tambin esquema. Cuando se crea un objeto en un esquema, los dems no tienen acceso
a l, a no ser que se concedan privilegios.

En Oracle existen tres roles predefinidos, segn el tipo de usuario que se desee
crear: CONNECT para un usuario final que no tiene que crear o eliminar objetos en la
base de datos, RESOURCE para aquellos que si tienen este derecho y DBA que es tipo
de usuarios que pueden no slo crear o destruir objetos propios sino tambin los
objetos de los dems usuarios. Estos permisos se deben dar en orden ascendente;
esto es, para dar el permiso RESOURCE, se debe haber concedido previamente el
permiso CONNECT y para ser usuario DBA, que es privilegio ms alto, se deben haber
concedido los dos anteriores.

Un usuario se crea con la orden SQL CREATE USER. Su sintaxis es:

CREATE USER <nombre-usuario> IDENTIFIED BY <contrasea>;

Tambin es posible crear ROLES propios (papeles) y PROFILES (perfiles) para
facilitar la administracin de los privilegios. Si se tienen definidos varios grupos de
usuarios a quienes se les deben conceder los mismos privilegios, estas dos opciones
son muy recomendables. Por ejemplo:

CREATE ROLE analista identified by an0020;

CREATE ROLE seguri_admin IDENTIFIED BY mencha;

Ahora, para conceder privilegios o roles a los usuarios, se utiliza la orden GRANT,
cuya sintaxis aparece en la pgina siguiente.

GRANT <lista de permisos|roles> ON <tabla|vista> TO <lista de usuarios o
roles|PUBLIC> [WITH GRANT OPTION]

Donde lista de permisos puede ser una serie de permisos separados por comas.
Adems de los roles ya enunciados, se tienen entre otros, los permisos o roles
siguientes:

SELECT
INSERT
DELETE
UPDATE
ALL (para abreviar)
INDEX
ALTER
CREATE USER
CREATE PROFILE
CREATE ROLE
IMP_FULL_DATABASE (importar o cargar datos de respaldos)
EXP_FULL_DATABASE (hacer respaldos)
EXECUTE (ejecutar un procedimiento)

Ejemplos:

GRANT SELECT, DELETE ON empleados TO analista WITH GRANT OPTION;

GRANT ALL ON notas TO jefe;

GRANT create profile, alter profile, drop profile,
create role, drop any role, grant any role, audit any,
audit system, create user, alter user, drop user
TO seguri_admin;

GRANT imp_full_database TO claudia;

GRANT seguri_admin TO claudia;

GRANT seguri_admin TO analista;


Para conocer cuales privilegios se han concedido se puede consultar la tabla
dba_sys_privs del usuario sys.

SELECT * FROM sys.dba_sys_privs;

Un usuario puede conceder privilegios a los roles, o a los usuarios sobre los objetos de
su esquema o de otros usuarios a los que se le hayan dado privilegios con la opcin
WITH GRANT OPTION.

Tambin es posible restringir un privilegio de insercin o de actualizacin de slo unas
columnas (las restantes deben admitir valores nulos o tener predefinidos valores por
defecto), por ejemplo:

GRANT INSERT (nombre, cargo) ON emp TO analista, jorge;
GRANT INSERT, UPDATE (act_nro) ON cuentas TO contador;

Para quitar los permisos concedidos, se utiliza la orden REVOKE, que tiene la sintaxis
siguiente:

REVOKE <privilegios> ON <tabla|vista>FROM <usuarios|roles>;

Las Transacciones

Una transaccin es una unidad lgica de trabajo que corresponde directamente a una
sola actividad de la organizacin. Un sistema de bases de datos puede tener
diferentes clases de transacciones, desde actualizaciones simples de manera
interactiva hasta transacciones altamente complejas que incluyen miles de
operaciones; pero la caracterstica en comn que deben tener stas es que no pueden
dejar ninguna de ellas, la base de datos en un estado inconsistente.

Esto significa que las operaciones realizadas deben conducir de un estado consistente
a otro que tambin lo sea; aunque despus de realizar algunas de las operaciones
existan estados intermedios que pueden ser inconsistentes. Por lo tanto, para
garantizar la consistencia de la base de datos, se requiere que las operaciones dentro
de una transaccin se efecten todas o ninguna de ellas (las transacciones deben
considerarse atmicas). Una transaccin que no se hizo completamente, debido a una
falla en software o en el hardware, debe ser devuelta a su estado inicial y cualquier
cambio que se haya grabado debe ser deshecho.

En ORACLE los comandos SQL COMMIT y ROLLBACK son usados para finalizar una
transaccin y comenzar otra (COMMIT hace los cambios permanentes y ROLLBACK
deshace todos los cambios hechos en esa transaccin).

Una unidad lgica de trabajo o transaccin se da por finalizada en los siguientes casos:

Cuando se da un comando COMMIT o ROLLBACK explcitamente.
Cuando se da una orden de definicin de datos.
La salida del sistema ("exit" hace Commit y "quit" hace Rollback)
Una terminacin anormal.

Para el manejo de las transacciones los DBMS, como ORACLE, construyen
automticamente los archivos imgenes anteriores (before image file, BI) donde se
guardan los valores "viejos" de los datos afectados por una transaccin y de imgenes
posteriores (after image file, AI) donde se guardan los valores "nuevos". Es decir, las
bases de datos necesitan un lugar en donde guardar la informacin para deshacer una
transaccin cuando se requiera.

Cuando una transaccin se confirma (se da la orden COMMIT), ya sea implcitamente o
explcitamente, se graban todos los valores anteriores de los bloques que no an se
haban escrito en el archivo de imgenes anteriores; luego, los bloques actualizados se
escriben en la base de datos, la transaccin se marca como completa y, por ltimo, se
liberan los bloqueos que se tengan a las filas y a las tablas afectadas por la
transaccin.

El archivo BI copia los bloques antes de la transaccin para poder facilitar que un
usuario se arrepienta y pueda deshacer los cambios. Esto hara que los bloques del
archivo BI sean vuelvan a escribir en la base de datos, deshaciendo efectivamente la
transaccin. Hasta que el trabajo del usuario no se comprometa, los otros usuarios que
consulten los mismos datos, los leern del archivo BI.

Adicionalmente, en ORACLE, se pueden definir marcas de puntos de grabacin
(savepoint markers) para deshacer una transaccin hasta un punto especfico de ella
con el comando SAVEPOINT. Por ejemplo, en el programa siguiente se colocan varias
marcas.

BEGIN
INSERT INTO emp
VALUES(10, JARAMILLO, LUIS, ANALISTA, 800000);
SAVEPOINT A;
INSERT INTO emp
VALUES (11,VELASQUEZ,ANA,ANALISTA, 980000);
SAVEPOINT B;
INSERT INTO emp
VALUES (12,ARANGO,JULIO,DIGITADOR, 210000);
......
ROLLBACK TO SAVEPOINT B; COMMIT;
END;

En este ejemplo quedaran en la tabla emp, slo los registros de Luis y Ana.

CONCURRENCIA

Las bases de datos relacionales poseen un sistema de manejo de concurrencia, que
permite que mltiples usuarios compartan los mismos recursos al mismo tiempo. Los
recursos son objetos de la base de datos.

Los objetivos de un sistema de concurrencia son:

- Que el acceso a los objetos en forma simultnea, por los usuarios, sea coordinado.

- Consistencia de los datos: Un usuario siempre debe tener una vista consistente de
los datos que est manipulando.

Cuando varias transacciones son ejecutadas concurrentemente en una base de datos
compartida, sus ejecuciones deben ser sincronizadas. Esto es, el efecto de una
transaccin debe ser el mismo que sera si no existiera ninguna otra transaccin que
se estuviera ejecutando concurrentemente. El efecto de ejecutar varias
transacciones al tiempo, debe ser el mismo que si fueran ejecutadas en serie con
algn orden. Si esto se puede lograr, se dice que las transacciones son serializables.

La necesidad de un control de la concurrencia se ilustra con el siguiente ejemplo:

Suponga una compaa de viajes que mantiene una base de datos con la informacin de
los vuelos y alguien llama a reservar un nmero dado de asientos para determinada
fecha. Esta transaccin implica mirar la tabla de vuelos para ver cul cantidad de
asientos disponibles existe, luego registrar los nuevos pasajeros y por ltimo
actualizar los asientos disponibles. Una dificultad que se puede presentar con esta
transaccin es que otra persona tambin est haciendo otra reservacin y se pueda
sobrecargar el vuelo.

Los tipos de problemas que pueden surgir, se pueden describir as:

La actualizacin perdida. Considere la siguiente secuencia de eventos, donde las
transacciones T1 y T2 se estn ejecutando concurrentemente, que aparece a
continuacin.
1. T1 lee el objeto O de la base de datos.
2. T2 lee el objeto O de la base de datos.
3. T1 actualiza el objeto O y lo compromete.
4. T2 actualiza el objeto O y lo compromete.

El resultado de estos eventos es que la actualizacin hecha por T1 se pierde.

La lectura desactualizada. Considere la siguiente secuencia de eventos:

1. T1 lee el objeto O de la b.d con el propsito de actualizarlo.
2. T2 lee el objeto O de la b.d con el propsito de mirarlo.
3. T1 modifica el objeto O y lo compromete.

El resultado de estos eventos es que T2 ha trado un objeto desactualizado.

La solucin obvia a estos problemas sera permitirle a una transaccin bloquear un
objeto durante una actualizacin y liberarlo apenas culmine. Sin embargo, el
mecanismo de bloqueo puede l mismo, generar serios problemas en el sistema y por lo
tanto debe ser monitoreado y controlado cuidadosamente.

Los mecanismos de control de concurrencia son, entonces, los bloqueos (tambin
llamados candados) que son usados para alcanzar dos objetivos importantes: la
consistencia y la integridad de la base de datos.

Se pueden diferenciar dos clases de bloqueos:

1. Un bloqueo de lectura que da acceso de slo lectura a un objeto y evita que
cualquier otra transaccin actualice el objeto. Esta clase de bloqueo se llama, a
menudo, de lectura compartida puesto que varias transacciones pueden tener este
tipo de bloqueo al mismo tiempo.

2. Un bloqueo de escritura que otorga un acceso exclusivo de lecto-escritura y
previene a la fuerza que otras transacciones lean o escriban sobre el mismo
objeto.

Un tem de dato, por supuesto, no necesariamente se requiere bloquear durante toda
duracin de la transaccin y el nivel de concurrencia podra incrementarse
bloquendolo nicamente durante el acceso real al objeto; aunque este procedimiento
incrementara la probabilidad de que ocurra un bloqueo mutuo (deadlock).

Bloqueo Mutuo o Abrazo Mortal

Considere el siguiente ejemplo:

1. T1 efecta un bloqueo de escritura al objeto A.
2. T2 efecta un bloqueo de escritura al objeto B.
3. T1 solicita un bloqueo sobre el objeto B pero debe esperar porque T2 lo
tiene bloqueado.
4. T2 solicita un bloqueo sobre el objeto A pero debe esperar porque T1 lo
tiene bloqueado.

En este punto ni T1 ni T2 pueden proceder porque estn bloqueadas mutuamente. La
estrategia para resolver este tipo de conflicto consiste en permitir que los bloqueos
mutuos ocurran, detectarlos y resolverlos. Para detectarlos el sistema mantiene un
grafo en cuyos nodos mantiene las transacciones concurrentes y cuyos arcos son
determinados de la siguiente manera: Si la transaccin Ti solicita un bloqueo sobre el
objeto bloqueado por Tj, se dibuja un arco del nodo Ti al Tj, el arco se quita cuando Tj
libera el objeto. Un bloqueo mutuo se observa como un ciclo en el grafo. La tcnica de
deteccin de un bloqueo mutuo puede ser muy costosa si el nivel de granularidad es
alto en el sistema.








Para resolver el conflicto de bloqueo mutuo se pueden emplear diferentes tcnicas
pero la ms usual es deshacer alguna de las transacciones en conflicto. En ORACLE se
escoge aquella que tenga la menor cantidad de trabajo realizado.

Es general, el propsito es reducir la contencin de los recursos. Especficamente es
deseable minimizar el tiempo entre una actualizacin y un COMMIT o ROLLBACK y los
bloqueos mutuos tambin pueden evitarse si los procesos hacen bloqueos a estas
tablas en el mismo orden cada uno ya sean implcitos o explictos.

T
1


Tj
T
2

El bloqueo en ORACLE y en otros DBMS es completamente automtico y no requiere
intervencin del usuario. No obstante, tambin se le permite al usuario bloquear
cuando lo considere necesario, desahabilitando el bloqueo por defecto.

La forma de hacerlo es:

LOCK TABLE tabla1 [, tabla2, ...] IN
{ SHARE | SHARE UPDATE | EXCLUSIVE } MODE [NOWAIT]


IN SHARE MODE impide que otra transaccin actualice los datos de la tabla que ha
sido bloqueada para lectura hasta que haya una orden COMMIT, ROLLBACK o con otra
terminacin de la transaccin, como se expres anteriormente. IN EXCLUSIVE MODE
permite cambiar los datos de la tabla e impide, a otra transaccin cualquiera,
actualizar los datos al mismo tiempo; pero si le permite verlos excluyendo otros
bloqueos. IN SHARE UPDATE MODE permite a otras transacciones consultar la tabla
o bloquearla en modo SHARE UPDATE reservndose el derecho de actualizar una(s)
fila(s) en una tabla e impidiendo a las otras cambiar las mismas filas; tampoco permite
bloqueos exclusivos.

La transaccin se termina cuando se le hace un commit en cuyo caso actualiza la base
de datos y libera las llaves o candados que tiene reservadas. La transaccin se
deshace cuando se le efecta un rollback en cuyo caso tambin libera los candados
que tenga asignados.

Candados: Impide que la transaccin t2 accede un tem reservado previamente por la
transaccin t1, hasta que t1 lo libere.

Granularidad: Es el tamao del tem sobre el cual se ejerce un bloqueo. Este tem
puede ser una pgina, bloque, una tabla o toda la base de datos.

Alcance de los candados:

- Exclusivo: Prohbe el compartir un recurso. La primera transaccin que asigna
esta llave puede accederlo, mientras que la segunda debe esperar hasta que ste
sea liberado.
- Compartidos: Dependiendo de las operaciones involucradas permite que los
recursos sean compartidos por varios usuarios.


Deteccin de situaciones de abrazo mortal (deadlock ):

Esta situacin se presenta cuando una transaccin t1 est esperando por un recurso
que tiene la transaccin t2 y sta a su vez est esperando por un recurso que tiene la
t1.

Ejemplo:

Transaccin 1 (t1) Transaccin 2 (t2)

update socio update socio
set fecha_nac = '18-Aug-1960' set fecha_ing = '1-aug-1996'
where cdigo = 200; where cdigo = 245;


update socio update socio
set fecha_nac = '11-Sep-1961' set fecha_ing = '5-May-1995'
where cdigo = 245; where cdigo = 200;



Muchos manejadores de bases de datos, optan por deshacer la transaccin que tenga
menos instrucciones y le informa al usuario que se ha detectado una situacin de este
tipo. Cada aplicacin deber manejar estas situaciones dentro de su programacin.

2.2.4. Respaldo

En todo sistema manejador de base de datos existe la posibilidad de que ocurran
fallas que generen prdida de informacin, estas fallas pueden ocurrir por:

Errores del usuario: Como por ejemplo,

- Actualizacin indebida de una tabla.
- Fallas en el Hardware: Como por ejemplo un aterrizaje de discos.
- Fallas en el software: Errores en el cdigo de una aplicacin.

Todos los manejadores de bases de datos ofrecen mecanismos de respaldo, que
permite hacer copias totales, parciales o incremntales de la base de datos.

Los respaldos pueden ser:

En lnea: Mientras se est respaldando, los datos sigue estando disponible para los
usuarios. Esto es muy til para bases de datos que deben estar en servicio las 24
horas.

Fuera de lnea: Requiere que la base de datos est fuera de servicio, mientras se est
respaldando.
2.2.5. Recuperacin

El sistema de recuperacin que ofrecen los manejadores de bases de datos, permite,
que en el caso de que ocurra una falla, la base de datos pueda ser restaurada, con un
mnimo impacto para el usuario; es decir, que se puedan recuperar todas las
transacciones que se haban hecho, hasta momentos antes de que la falla haya
ocurrido.

Esta recuperacin puede ser:

- Esttica: Es decir la base de datos se restaura hasta el estado en que se
encontraba cuando se tom la ltima copia.

- Dinmica: No slo restaura la base desde la copia ms reciente que se tenga, sino
que tambin es capaz de recuperar las transacciones que se hayan hecho desde
ese entonces.