Controles en
Base de Datos
Base de Datos
Dra. Elsa Estévez
Departamento de Ciencias e Ingeniería de la Computación
Universidad Nacional del Sur
Introducción
Históricamente, lo datos mantenidos en un sistema de Base de Datos han sido datos declarativos.
Los datos declarativos describen aspectos estáticos de objetos del mundo real y sus asociaciones.
Ejemplo: Ejemplo:
1) un archivo de cuentas corrientes
Introducción
También se pueden almacenar datos procedurales.
Los datos procedurales describen los aspectos dinámicos de los objetos del mundo real y sus asociaciones.
Ejemplo:
1) conjunto de reglas de descripción de toma decisiones 1) conjunto de reglas de descripción de toma decisiones sobre qué stocks y límites se eligen para abastecer un depósito.
Cuando se almacenan ambos tipos de datos, declarativos y
Algunos Conceptos
Una BD es una colección estructurada de elementos de datos interrelacionados, a fin de modelar parte del mundo real.
Hace a los fines de una organización, y sirve para compartir recursos.
Un Sistema de Administración de BD hace referencia: 1) al software,
2) a las personas responsables de: a) un almacenamiento eficiente,
b) ejecución de operaciones válidas y c) manipulación de datos desde la BD.
Algunos Conceptos ...
Parte de los servicios que provee un sistema de administración de BD son:
1) Lenguajes de definición de datos: operan sobre la definición de la BD. Proveen un diccionario de
datos, metadatos, estructuras de almacenamiento y los métodos de acceso usados.
y los métodos de acceso usados.
2) Lenguajes de manipulación de datos: permiten
realizar acciones sobre la BD en sí misma: obtener información almacenada, agregar, eliminar, y
Introducción
El sistema de Base de Datos se puede ampliar almacenando: 1) datos sobre diseños, en los cuales el foco son los
objetos de diseño. Pueden ser compuestos o descompuestos en otros objetos de diseño.
2) imágenes, gráficos, audio, y video. Pueden ser usados para soportar una aplicación de multimedia.
para soportar una aplicación de multimedia.
Se debe realizar un trabajo de sistema de administración de BD orientado a objetos para:
1) soportar estos nuevos tipos de aplicaciones.
Introducción
Definiciones:
1) Data Warehouse: enormes BD que contienen datos integrados, detallados y sumarizados, históricos, y metadatos.
2) Data Marts: BD que contienen una selección de 2) Data Marts: BD que contienen una selección de datos de un data warehouse, que sirven a una única función o departamento.
3) Data Mining: el proceso de reconocer patrones en los datos de data warehouses o data marts.
Introducción
Inicialmente, las principales componentes en un Sistema de Base de Datos (SBD) eran:
1) Sistema de administración de BD: usado para manipular datos
2) Programas de aplicación: definidos para crear, modificar y eliminar datos
3) Sistemas operativos: para realizar las operaciones básicas de E/S para mover datos a y desde medios de almacenamiento
4) Procesador central y almacenamiento primario: donde se ejecutan las actividades
Introducción
Sin embargo, por razones de eficiencia y eficacia han ocurrido algunos cambios en las componentes usadas.
Por ejemplo:
1) actividades previamente realizadas por programas de aplicación y por el SO, han sido migradas al sistema de administración de la BD.
sistema de administración de la BD.
2) se han desarrollado máquinas especiales para soportar sistemas de bases de datos.
3) se han desarrollado sistemas expertos para
Controles de Acceso
Los controles de acceso en el SBD previenen de accesos no autorizados a los datos.
Se especifican mediante:
1) Una política de seguridad para el subsistema
2) Eligiendo un mecanismo de control de acceso que sea efectivo para tal política.
sea efectivo para tal política.
En SBD, los usuarios dueños deben especificar: 1) quién puede acceder a los datos
2) qué acciones de privilegio pueden tener respecto de los datos.
Controles de Acceso
Los controles de acceso pueden ser:
1) Control de acceso discrecional
Control de Acceso Discrecional
Los privilegios frecuentemente son dados a usuarios que son designados como propietarios.
En el SBD pueden variar considerablemente.
Ejemplo: en una BD relacional, un usuario puede ser autorizado a:
autorizado a:
1) crear un esquema.
2) crear, modificar, o eliminar vistas asociadas al esquema 3) crear, modificar, o eliminar relaciones asociadas al
esquema.
4) crear, modificar, o eliminar tuplas en las relaciones asociadas con el esquema.
Control de Acceso Discrecional
Los usuarios no propietarios del dato pueden ser sujetos a 4 tipos de restricciones de acceso:
1) Control de acceso dependiente de nombre, 2) Control de acceso dependiente de contenido, 3) Restricción dependiente de contexto,
3) Restricción dependiente de contexto, 4) Acceso dependiendo de la historia.
Estos tipos de restricciones pueden ser implementados por
Control de Acceso Discrecional
Restricciones dependientes del nombre:
Se refiere al acceso que se le puede dar o no a un
usuario, con respecto a un recurso de dato nombrado.
Si los usuarios tienen acceso al recurso de dato, Si los usuarios tienen acceso al recurso de dato, también se debe especificar la acción de privilegio.
Ejemplo: acceder al atributo “sueldo”.
Estos tipos de acceso de control son también conocidos como ‘control de acceso independiente de contenido’.
Control de Acceso Discrecional
Restricciones dependientes del contenido:
Los usuarios tendrán acceso permitido o denegado para acceder a recursos de dato dependientes del contenido.
Control de Acceso Discrecional
Restricciones dependientes del contexto:
Los usuarios pueden ser autorizados o no a acceder al recursos de datos, dependiendo del contexto en el cual ellos quieren tener acceso.
Ejemplo: acceden a leer el atributo “sueldo” para emitir
Ejemplo: acceden a leer el atributo “sueldo” para emitir informe de estadísticas.
Control de Acceso Discrecional
Restricciones dependientes de la historia:
Se refiere que el acceso se autoriza o no, dependiendo de los accesos y las acciones realizados anteriormente sobre los recursos de datos.
Ejemplo: los empleados podrían no ser permitidos para leer
Ejemplo: los empleados podrían no ser permitidos para leer
los nombres de empleados con salarios superiores a los $3.000.
Pero este efecto se lograría sólo si a ellos tampoco se les permite acceder a la lectura de salarios ó a los nombres de empleados.
Control de Acceso Discrecional
Una forma de implementar estos 4 tipos de restricciones es mediante la construcción de vistas (subesquemas).
Una vista presenta sólo un subconjunto de la BD al usuario.
Los datos presentados a un usuario en una vista también pueden ser restringidos usando algún tipo de expresión pueden ser restringidos usando algún tipo de expresión condicional.
En este caso, las restricciones también pueden ser
Control de Acceso Discrecional
Privilegios propagados: es la habilidad de un usuario para conceder u otorgar sus privilegios, o algún subconjunto de ellos, a otro usuario.
Ejemplo: el propietario de una vista otorga privilegios a otro usuario, que en su momento este se los concede a un tercero. usuario, que en su momento este se los concede a un tercero.
Para prevenir la extensión de la propagación, se requiere: 1) Control de propagación horizontal
2) Control de propagación vertical 3) Revocación de privilegios
Control de Acceso Mandatorio
En un control de acceso mandatorio los recursos son
clasificados en niveles, y a los usuarios se les asigna un nivel.
El acceso de usuarios a los recursos es manejado por una
política de seguridad.
Por eso, este control de acceso es considerado como una Por eso, este control de acceso es considerado como una política de seguridad.
Esta política puede ser especificada por varios modelos: 1) Modelo de Bell
2) Modelo de LaPadula 3) Modelo de Biba
Control de Acceso Mandatorio
Ejemplo: los usuarios pueden no ser autorizados a leer un recurso, a menos que su nivel asignado sea mayor o igual al nivel de clasificación del recurso.
En los SBD una manera para implementar esta
aproximación es asignar un nivel de clasificación para cada aproximación es asignar un nivel de clasificación para cada atributo, ítem de dato, o registro de una relación.
Controles de Acceso
Los usuarios no son autorizados a ver o, a actualizar todos los datos en la BD.
Por eso, las reglas de seguridad y de integridad presentan una vista de la BD para un usuario.
Controles de Acceso
Hay dos aproximaciones para crear estas vistas:
1) Implementar vistas por filtrado de datos en una tupla o instancia de registro en una relación:
a) en este caso se almacena una única tupla
b) se aplican sentencias condicionales para determinar b) se aplican sentencias condicionales para determinar
qué dato de la tupla será disponible al usuario.
2) Crear múltiples tuplas que satisfacen las reglas de seguridad e integridad, aplicables a cada nivel:
a) esta aproximación se la conoce como poli-instanciación
Algunas Implementaciones
Un factor importante que afecta la confiabilidad de los mecanismos de control de acceso es la extensión en la que es localizada, ya sea en un solo componente o múltiples componentes.
Dos posibles enfoques son:
1) Enfoque 1: embebida dentro de un único, seguro y 1) Enfoque 1: embebida dentro de un único, seguro y
verificado componente, como es el kernel del sistema operativo (SO).
2) Enfoque 2: embebida tanto en los componentes de administración de BD, como también en el SO.
Algunas Implementaciones
Enfoque 1:
(+) La confiabilidad de mecanismos de control de acceso se incrementa si la realiza el kernel del SO.
(+) Las reglas de control de acceso mejoran la consistencia si son ejecutadas por un único componente.
son ejecutadas por un único componente.
Los contrastes prácticos hacen que esta función sea distribuida en varios componentes.
(-) El tamaño y complejidad del kernel se incrementarían.
Algunas Implementaciones
Enfoque 2: por las razones anteriores, las reglas de control de acceso en un SBD son frecuentemente ejecutadas tanto por los componentes del sistema de administración de BD como también del SO.
Por ejemplo:
Por ejemplo:
1) el SO podría restringir quién tiene acceso al sistema de administración de BD.
2) los usuarios tendrían que identificarse y autenticarse a sí mismos frente al sistema de administración de BD para obtener acceso a los datos y para obtener ciertos privilegios de acción sobre los datos.
Algunas Implementaciones
En una BD distribuida, es siempre más difícil asegurar que, la seguridad e integridad de los mecanismos de control de acceso, sea mantenida.
Debe ubicarse en el SBD un conjunto completo y consistente de reglas de control de acceso.
Independientemente que la BD sea replicada en múltiples sitios, o particionada en diferentes partes, y distribuida en diferentes sitios, por consideraciones de eficiencia se deben usar mecanismos de control de acceso múltiple para
Algunas Implementaciones
En BD replicadas se deben imponer las mismas reglas de control para asegurar los mecanismos de control de acceso a cada sitio.
En BD particionadas los requerimientos de los usuarios deben rutear los mecanismos de control de acceso en deben rutear los mecanismos de control de acceso en
forma consistente y completa mediante recursos de datos que han sido requeridos.
Controles de Integridad
Un buen Sistema de Administración de BD (DBMS) deberá realizar varios tipos de restricciones de integridad
dentro del SBD.
Las restricciones de integridad son establecidas para mantener: 1) la consistencia,
2) la completitud, y 2) la completitud, y 3) la unicidad
de las instancias de las estructuras usadas dentro del
Controles de Integridad
Los tipos específicos de restricciones provistos por el sistema dependerán de:
1) alguna extensión del modelo conceptual y
2) la aproximación del modelado de datos que este soporta.
Para ilustrar la naturaleza de los controles de integridad que podrían realizarse, proveemos una visión de los
mismos asociados con:
1) el modelo entidad-relación (MER), 2) el modelo de datos relacional, y 3) el modelo de datos de objetos.
Controles de Integridad
Las construcciones fundamentales del modelo son: 1) entidades,
2) relaciones entre entidades, y 3) atributos de entidades.
Las entidades son tipos básicos o clases de objetos del mundo real que deben ser modelados.
Dentro del SBD se pueden aplicar, a las entidades, las siguientes restricciones de integridad:
Entidades: Restricciones de Integridad
Restricción de Integridad
Descripción
Unicidad Cada instancia de una entidad debe ser única
Cardinalidad máxima Especifica el número máximo de instancias de una entidad que puede existir en la
base de datos
Cardinalidad mínima Especifica el número mínimo de instancias de una entidad que puede existir en la BD
Restricción de integridad
Descripción
Identificador de entidad
Especifica los atributos cuyos valores únicos identifican cada instancia de una entidad.
Entidades: Restricciones de Integridad
Tipo de valor de un identificador
Especifica los tipos de valores permitidos para los atributos que comprenden un identificador de entidad (ej: número real, entero, string
alfanumérico).
Conjunto de valores de un identificador
Especifica el conjunto permitido de valores para los atributos que comprenden el identificador de una entidad
Restricción de integridad Descripción
Tipo de valor de un atributo
Especifica los tipos de valores permitidos para un atributo (real, alfanumérico)
Entidades: Restricciones de Integridad
Conjunto de valores de un atributo
Especifica el conjunto permitido de valores para un atributo
Leyes de transición Especifica las relaciones entre valores previos de atributos y sus nuevos valores
Dentro del SBD, una restricción de integridad que se aplica a las relaciones es el control de cardinalidad, que especifica una de las siguientes dos posibilidades:
1) El número máximo de instancias de una entidad que puede ser asociado con una instancia de otra
Relaciones: Restricciones de Integridad
que puede ser asociado con una instancia de otra entidad (o tupla de instancias de entidades
múltiples), o
2) El número mínimo de instancias de una entidad que puede ser asociado con una instancia de otra
entidad (o tupla de instancias de entidades múltiples).
Restricción de integridad
Descripción
Llaves o Claves Especifica las llaves candidatas de una relación. Estos valores deben identificar únicamente cada tupla de la relación
Relaciones: Restricciones de Integridad
tupla de la relación
Entidad Se establecen para asegurar que las claves primarias nunca tienen valores nulos.
Restricción de integridad
Descripción
Referencias Son establecidos para mantener consistencia sobre tuplas de la relación.
Si una tupla en la relación refiere a un dato en otra
Relaciones: Restricciones de Integridad
Si una tupla en la relación refiere a un dato en otra tupla de la relación o a una tupla de otra relación, este control asegura que la tupla referenciada debe existir.
Los constructores fundamentales en este modelo son los
objetos y sus relaciones.
Los objetos poseen:
1) propiedades estructurales que reflejan
características estáticas del objeto. Atributos.
Modelo de Datos de Objetos
características estáticas del objeto. Atributos.
2) propiedades dinámicas que reflejan como un objeto cambia de estado. Métodos y procedimientos
Dentro del SBD se pueden aplicar, a las propiedades
estructurales de los objetos, las siguientes restricciones de integridad:
Estructuras: Restricciones de Integridad
Restrición Descripción Identificador
único
Cada objeto debe ser único. El sistema de BD puede generar un identificador de objeto que lo identifica a través de su vida.
Llave o clave única
Las claves de objetos son distintas de los identificadores de objetos. Diferentes restricciones podrían aplicarse. Por ej: las llaves podrían ser únicas dentro de un tipo de
objeto o dentro de todos los subtipos de un tipo.
Tipos de valores de atributos
Especifica los tipos de valores permitidos para un
atributo de un objeto (número real, string alfanumérico, lista, etc)
Restricción Descripción
Conjunto de valores de un atributo
Especifica el conjunto de valores permitido para un atributo de un objeto. Podrían ser definidos
proceduralmente (a través de un método) como una función de los valores de otros atributos de objetos
Estructuras: Restricciones de Integridad
función de los valores de otros atributos de objetos
Tipos y herencia
Aseguran que un objeto de un subtipo comparte todas las restricciones de integridad asociados con su super-tipo.
En el modelo de objetos, las propiedades dinámicas se
reflejan mediante los procedimientos que operan sobre los objetos.
Estas propiedades facilitan la encapsulación, donde las
características estructurales de un objetos son mantenidas
Mas Restricciones de Integridad
características estructurales de un objetos son mantenidas ocultas y sólo los métodos y procedimientos son hechos públicos.
En el modelo de datos de objetos, las relaciones sobre objetos indican:
1) que los valores de las propiedades de al menos uno de los objetos dependen de los valores de las propiedades de otros objetos en la relación, o
2) que un objeto es una componente de otro objeto
Relaciones: Restricciones de Integridad
2) que un objeto es una componente de otro objeto (agregación o composición).
Dentro del SBD se pueden aplicar, a las relaciones, las siguientes restricciones de integridad:
Restricción Descripción
Referencial Si un objeto hace referencia a otro objeto, éste debe existir y ser del tipo correcto
Relaciones: Restricciones de Integridad
Compo-sición
Especifica las acciones que deben entenderse sobre la inserción y eliminación de objetos que participan en relaciones. Ejemplo, si una clase es eliminada desde la base de datos, todas sus subclases también deben ser eliminadas.
Cardinalidad Especifica el número mínimo o máximo de objetos de una clase particular que puede participar en una relación.
Controles del Software de Aplicación
La integridad del SBD también depende de los controles
implementados en los programas de aplicación que usan la BD.
A continuación veremos distintos tipos de protocolos de
actualización y reporte que podrían ser implementados en una aplicación de software para proteger la integridad de la BD.
aplicación de software para proteger la integridad de la BD.
Los protocolos de actualización: buscan asegurar que los
cambios en la BD reflejen los cambios ocurridos a las entidades y sus asociaciones en el mundo real.
Controles del Software de Aplicación
Los protocolos de actualización más importantes consideran:
1) control de la secuencia de los archivos de transacciones y maestro
2) asegurar que todos los registros de un archivo sean procesados
3) procesamiento de múltiples transacciones para un único registro en el orden correcto
Secuencia de Transacciones y Maestro
Estas situaciones se pueden deber a:
1) algunos “parches” sobre el archivo de transacciones, debido a errores previos, pueden ser incorrectos y el
archivo podría tener una secuencia incorrecta respecto al maestro.
2) un programa erróneo podría insertar registros en una 2) un programa erróneo podría insertar registros en una
secuencia incorrecta
3) clasificaciones utilitarias que incorrectamente clasifican un archivo, o un error del sistema de sw o hw que
corrompe la secuencia de un archivo y no es detectado. 4) corrupción no detectada de datos podría ocurrir cuando
Todos los Registros Son Procesados
Si un archivo maestro es mantenido en orden secuencial, el ‘programa de actualización’ debe implementar protocolos de fin de archivo (EOF) correctos, para asegurar que no se pierdan registros desde el archivo de transacciones o desde el archivo maestro.
Esto puede ser una tarea especialmente compleja si se
procesan múltiples archivos de transacciones con múltiples archivos maestros, concurrentemente.
Procesamiento de Múltiples Transacciones
El orden en el cual las transacciones son procesadas frente al registro maestro puede ser importante.
Mantenimiento de Cuentas Transitorias
Siempre que una transacción monetaria deba ser procesada frente a un archivo maestro (tablas), el programa de
actualización debe mantener una cuenta transitoria (en
suspenso), para imputar ahí las actualizaciones en caso que no se encuentre la cuenta requerida.
Estos casos pueden producirse porque:
1) El código de cuenta está mal imputado en las transacciones.
2) No se dio de alta correctamente la cuenta en el archivo maestro.
3) Se imputó la transacción, previo al alta de la cuenta en el archivo maestro.
Protocolos de Reportes
Los protocolos de reporte proveen información a los
usuarios de las BD, que les permite identificar errores o irregularidades que han ocurrido en actualizaciones.
Los protocolos más importantes son:
1) Imprimir datos de control para tablas internas: muchos 1) Imprimir datos de control para tablas internas: muchos
programas usan tablas internas. Se debe tener en cuenta:
imprimirlas periódicamente.
controlar la autenticidad, exactitud y completitud de los cambios realizados.
Protocolos de Reportes
2) Imprimir totales de control corrida a corrida: muchas aplicaciones ejecutan múltiples programas que se pasan archivos entre ellos.
En estos casos es conveniente imprimir totales de control luego de la ejecución de cada programa a fin de poder luego de la ejecución de cada programa a fin de poder
identificar irregularidades o errores que hayan ocurrido en la BD.
Protocolos de Reportes
3) Imprimir las entradas de las cuentas en suspenso: se registran en estas cuentas las transacciones que no pudieron actualizarse correctamente contra el archivo maestro.
Se debe imprimir periódicamente el contenido de estas Se debe imprimir periódicamente el contenido de estas cuentas, a fin de asegurar que las transacciones se vayan depurando a medida que se van corrigiendo los errores.
Controles de Concurrencia
La principal meta es permitir al usuario de la BD compartir
los mismos recursos de datos.
De otra manera, se deberían mantener múltiples versiones de un mismo ítem de dato, y como resultado, habría un
incremento inevitable de inconsistencias sobre las diferentes versiones.
diferentes versiones.
El compartir los recursos de datos produce un nuevo conjunto de problemas que deben ser tratados por el SBD para
Problemas al Compartir Datos
Veamos un ejemplo: una aplicación de stock en una empresa en la cual:
1) un ‘empleado de ventas’ vende un productoy
2) una ‘empleada de compras’ recibe el mismo producto tienen acceso on-line a la tabla de productos.
Asumamos, que ellos tienen acceso concurrente al archivo, es decir, ambos pueden acceder al archivo al mismo tiempo.
1. Vende
60
Art.1
100 unid.
100
Art.1
40 unid.
Art.1
110 unid.
Ejemplo ....
2. Compra
10
Stock Inicial... 100
Vende 60-Stock.. 40
Compra 10–Stock.. 50
40
100
100
110
Podemos ver que accesos concurrentes no controlados pueden causar problemas de integridad de datos.
Programas de sólo lectura pueden tener resultados
erróneos si operan concurrentemente con un programa de actualización.
Problemas al Compartir Datos
actualización.
La solución obvia para el problema de integridad causado por el procesamiento concurrente es el lock-out o
bloqueo del recurso.
Se bloquea a uno de los procesos, mientras el otro lo usa. Desafortunadamente esta solución lleva a otro tipo de
Supongamos que un proceso puede ‘bloquear’ el acceso a un recurso.
Veamos un problema que se presenta:
1) Al tiempo t, el proceso P adquiere un control exclusivo del recurso dato_1, y el proceso Q también adquiere un control exclusivo del recurso dato_2.
El Problema de Deadlock
control exclusivo del recurso dato_2.
2) Al tiempo t+1, el proceso P hace un requisito sobre el recurso dato_2, y el proceso Q también requiere el recurso de dato_1.
Ninguno de los procesos podrá continuar hasta que se haya liberado alguno de los recursos adquiridos al tiempo t.
Deadlock: Condiciones Necesarias y Suficientes
Condición Descripción
Lock-out Un proceso excluye a otro de un recurso.
Concurrencia Dos o mas procesos compiten concurrentemente por control exclusivo de dos o más recursos.
Requerimiento adicional
Un proceso mantiene control exclusivo de un recurso, y requiere control exclusivo de otro. Sin apropiación Un proceso no puede forzar a otro proceso para
liberar un recurso.
Soluciones de Deadlock
Cómo podemos resolver una situación de deadlock?
La primera solución, para algunos casos, sería forzar a uno de los dos procesos a liberar el recurso del cual mantiene control exclusivo.
Desafortunadamente esto no siempre resuelve los problemas. Desafortunadamente esto no siempre resuelve los problemas.
Soluciones de Deadlock
1) El empleado E1 recibe una orden de pedido y no toma la orden a menos que todas las partes existan en stock:
80 unidades del producto A 90 unidades del producto B
2) El empleado E2 recibe una orden similar: 50 unidades del producto A
100 unidades del producto B
Ambos vendedores, inicialmente consultan la BD para verificar el stock de todas las partes requeridas en un proceso de sólo lectura.
Soluciones de Deadlock
1) El empleado E1 tomó control exclusivo del registro de partes A (total de 100) y le quita 80, quedando 20
2) Al mismo tiempo, el empleado E2 adquiere control exclusivo del registro de partes de B (que estaba en 150) y le resta 100, quedando 50 unidades en B
150) y le resta 100, quedando 50 unidades en B
3) Al tiempo t+1 ocurre una situación de deadlock
Consideremos qué sucede si al vendedor E1 se le permite expropiar recursos de otros vendedores: Al acceder al
registro B, encontrará sólo 50 unidades, y la orden requería 90 unidades de B, en consecuencia la orden entera debe ser cancelada.
Prevención
de Deadlock
Varias soluciones han sido propuestas para resolver los problemas de deadlocks.
La más ampliamente aceptada es el lockeo de dos fases (two phase locking) y se aplica a transacciones que están siendo procesadas frente a la BD.
procesadas frente a la BD.
Prevención de Deadlock
Una transacción es una unidad de ejecución de programa que accede y posiblemente actualiza varios items de dato.
Una transacción es una colección de operaciones que realiza una única función lógica en una aplicación de Base de Datos.
Prevención de Deadlock
Atomicidad: todas las acciones tomadas por una transacción deben ser indivisibles. Se ejecutan todas o ninguna.
Consistencia: una transacción debe preservar la consistencia de la BD. Su efecto no se reflejará en la BD hasta que la
transacción ejecute un commit.
Es decir, todos los cambios son hechos en un espacio temporario Es decir, todos los cambios son hechos en un espacio temporario hasta que son escritos permanentemente, como una unidad
indivisible, en la BD.
Aislación: Los eventos que ocurren en una transacción deben ser transparentes a otras transacciones, que se están ejecutando
Prevención de Deadlock
El lockeo de dos fases usa el siguiente.protocolo:
1) para que una transacción pueda leer un ítem de dato debe poseer un lockeo de read para el ítem de dato
2) para que una transacción pueda grabar un registro debe
poseer un lockeo de write para el ítem de dato
3) no se les permite a distintas transacciones poseer 3) no se les permite a distintas transacciones poseer
simultáneamente lockeos conflictivos. Ejemplo: dos transacciones pueden tener lockeos de read sobre el mismo ítem de dato. No se permiten que ocurran
simultáneamente un lockeo de read y uno de write o dos de write.
4) si una transacción libera la propiedad de un lockeo, no puede volver a solicitar un lockeo sobre el mismo recurso 5) una transacción debe hacer el commit de la base antes
Prevención de Deadlock
El protocolo consta de dos fases:
1) Fase de crecimiento: la transacción realiza todos lockeos (y no libera ningún dato). Cuando la
transacción libera un lockeo, entra en la segunda fase. 2) Fase de encogimiento: libera todos los lockeos.
2) Fase de encogimiento: libera todos los lockeos.
Los lockeos pueden ser liberador porque: 1) La transacción hizo commit
Controles de Concurrencia
Una BD distribuida tiene su contenido almacenado en múltiples sitios.
Se utilizan diferentes estrategias de distribución, donde los extremos serían:
1) Una copia replicada de la BD puede almacenarse en 1) Una copia replicada de la BD puede almacenarse en
todos los sitios.
2) La BD puede fragmentarse en particiones no
solapadas. Cada partición es almacenada en sólo un sitio.
Los problemas de concurrencia y deadlock son una amenaza para la integridad de las BD distribuidas, a menos que el
Controles de Concurrencia
En el caso de una BD replicada, el sistema debe asegurar que todas las versiones de un ítem de dato se mantienen en un estado consistente.
Algunas estrategias de deadlock y concurrencia requieren que se lockeen todas las instancias de un ítem antes de su
actualización. actualización.
En el caso de una BD particionada, se debe identificar la
ubicación del ítem de dato requerido. Luego se debe activar su lockeo.
Controles de Concurrencia
Para ilustrar los controles de concurrencia en una BD distribuida, consideremos el lockeo de dos fases.
En este caso, primero se debe construir un planificador de dos fases para procesar y administrar los protocolos de lockeos.
En una BD replicada se debería implementar alguna de las siguientes dos estrategias:
Controles de Concurrencia
1) Estrategia 1: los planificadores son replicados y almacenados con cada versión del ítem de dato.
a) Si se requiere un lockeo de read, la transacción sólo requiere el lockeo al planificador más conveniente.
b) Si se requiere un lockeo de write, la transacción debe requerir el lockeo a todas las versiones del planificador requerir el lockeo a todas las versiones del planificador del ítem de dato requerido.
2) Estrategia 2: una versión del ítem de dato y su planificador asociado es designado como la copia primaria. Antes de
acceder a un ítem de dato se debe conseguir el lockeo de la copia primaria. La ubicación de la copia primaria se hace optimizando el tráfico del sistema. Se puede disponer de
Controles de Concurrencia
En una BD particionada, una transacción antes de conseguir el lockeo de read o write, debe ubicar al planificador del ítem de dato requerido. Luego debe activar el lockeo.
Surgen dificultades si el planificador está corrupto o perdido.
Existen otras estrategias para implementar estos controles. Existen otras estrategias para implementar estos controles.
Es difícil determinar si los controles implementados aseguran la integridad de la BD, para todas las posibles situaciones de conflictos de recursos.
Controles Criptográficos
Los controles criptográficos también son utilizados para proteger la integridad de datos almacenados en una BD.
La encriptación de bloque opera sobre bloques de datos
individuales, y difiere de la encriptación de stream, en la cual los valores criptográficos de un bloque de datos depende de los los valores criptográficos de un bloque de datos depende de los valores de otros bloques de datos.
La encriptación stream es útil para transferir archivos enteros entre dos usuarios.
Controles Criptográficos
Los datos almacenados en medios de almacenamiento portables también pueden ser protegidos mediante la implementación de un dispositivo de encriptación en los controladores de cada tipo de dispositivo.
Los datos son encriptados automáticamente cada vez que son Los datos son encriptados automáticamente cada vez que son escritos, y desencriptados automáticamente cada vez que son leídos.
Este tipo de encriptación protege la privacidad de datos cuando el medio de almacenamiento es robado.
No lo protege entre distintos usuarios del mismo sistema, porque la llave criptográfica es común a todos los usuarios.
Controles Criptográficos
Cuando no se comparten datos entre usuarios, o sólo se
comparten muy pocos datos, los usuarios individuales pueden proteger sus propios archivos usando una llave criptográfica personal.
Cada usuario deben presentar sus llaves al sistema cuando Cada usuario deben presentar sus llaves al sistema cuando desean realizar operaciones sobre sus archivos.
Este mecanismo no es aconsejable cuando los datos son compartidos, porque los usuarios propietarios deben dar a
conocer sus llaves a otros usuarios que requieren acceso a sus archivos.
Controles Criptográficos
El uso de controles criptográficos en SBD se hace más complejo en BD distribuidas:
Si la BD es replicada, se debe decidir si se mantendrán las mismas llaves con cada réplica de BD.
Alternativa 1: Se mantienen las mismas llaves
Ventajas: Si una réplica se pierde o destruye es relativamente fácil obtener una copia. Más aún, es relativamente fácil rutear una transacción de un usuario para otro sitio. Si un sitio tiene sobrecarga de trabajo se puede balancear la carga del sistema.
(!) Las llaves deberían ser distribuidas de una forma segura.
Desventajas: como residen en más sitios, crece el riesgo.
Controles Criptográficos
Ventaja: las llaves serán más seguras.
Desventajas: Es más dificultoso usar réplicas como back-up, y
Alternativa 2: Cada sitio tiene sus propias llaves
Desventajas: Es más dificultoso usar réplicas como back-up, y es también más dificultoso procesar transacciones en sitios
Controles Criptográficos
Si la BD es particionada, en algunos casos, los datos de un usuario podrían localizarse en múltiples sitios:
Ventaja: es fácil obtener el acceso. Cuando una transacción de
Alternativa 1: Se mantienen las mismas llaves
Ventaja: es fácil obtener el acceso. Cuando una transacción de un usuario obtiene la llave, se puede acceder al dato en
cualquier sitio.
Ventaja: los datos de cada sitio son más seguros
Desventaja: hay un alto overhead cuando las transacciones deben acceder a datos en múltiples sitios.
Controles de Manejo de Archivos
Son usados para prevenir destrucciones accidentales de los datos contenidos en un medio de almacenamiento.
Estos son realizados por 1) hardware,
2) software, 2) software,
3) operadores o usuarios
que cargan y descargan datos sobre el medio de almacenamiento (CDs, diskettes, cartridges) usados por la base de datos, dumps de BD, archivos de transacción, archivos de trabajo, logs y logs (trails) de auditoría.
Controles de Manejo de Archivos
Item Función
Etiquetas internas
Especifican el nombre del archivo, tabla o BD.
Usadas por el programa para chequear que este ha accedido al archivo, tabla o BD correcta.
Generación de números
Varias versiones de un archivo, tabla o BD pueden existir, todos con el mismo número.
Se usa por los programas que acceden al archivo, tabla o BD para chequear el acceso a sus
respectivas versiones.
Fecha de Retención
Prevenir los contenidos de un archivo, tabla o BD a ser sobrescrito antes de una fecha especificada.
Controles de Manejo de Archivos
Item Función
Totales de Control
Un registro dentro de cada archivo, tabla, o BD puede contener totales de control que pueden ser
chequeados.
Estos registros son actualizados al final de cada Estos registros son actualizados al final de cada corrida, y se reportan los totales de control.
Controles de Manejo de Archivos
Otros controles de HW son usados para prevenir la pérdida accidental de información sobre medios de almacenamiento.
Anillos de protección de archivos son usados para proteger datos sobre cintas magnéticas. Para permitir la grabación en una cinta, se coloca un anillo plástico en el centro de la parte una cinta, se coloca un anillo plástico en el centro de la parte de atrás del carrete (tambor). Si el anillo es removido los datos no pueden ser escritos sobre la cinta.
Similarmente, los discos pueden ser protegidos activando un switch de sólo lectura sobre el disco rígido,
Los diskettes pueden ser protegidos deslizando una parte plástica para tapar un hueco del diskette.
Controles de Manejo de Archivos
Si múltiples archivos son almacenados sobre un disco o diskette, los archivos individuales también pueden ser
bloqueados seteando un flag para prevenir la eliminación de datos.
También pueden ser útiles las etiquetas externas. Asisten a usuarios y operadores en la carga del archivo correcto.
usuarios y operadores en la carga del archivo correcto.
Ventajas: las etiquetas pueden contener el nombre del archivo, su fecha de creación, y un código de descripción.
Desventajas: se puede modificar el medio de almacenamiento sin modificar la etiqueta. Pueden no ser actualizadas para
Controles a Logs de Auditoría
Los logs de auditoría en un SBD mantienen la cronología de eventos que ocurren en la definición de la BD o en la BD en sí misma.
Se graba un conjunto de todos los eventos que ocurren sobre la BD como creaciones, modificaciones, eliminaciones y
recuperaciones. recuperaciones.
Logs Contables de Auditoría
Para mantener los logs contables de auditoría en un sistema de aplicación, el SBD debe realizar tres funciones:
Primero: se debe asociar una única estampilla de tiempo para cada transacción sobre la definición de la BD o la BD misma.
Estas estampillas de tiempo tienen dos propósitos: Estas estampillas de tiempo tienen dos propósitos:
1) confirmar que la última transacción ha alcanzado la definición de la BD o la BD misma;
2) identificar una posición única de tiempo para la
Logs Contables de Auditoría
Como resultado, los logs de auditoría deben permitir una de dos alternativas:
1) una operación de implosión
2) una operación de explosión
Implosión: cada transacción puede ser trazada desde su fuente al ítem de dato que afecta.
al ítem de dato que afecta.
El identificador de fuente de transacción establece su origen para ser trazada de forma no ambigua.
El identificador de destino designa el ítem de dato afectado.
La estampilla de tiempo confirma el efecto tomado sobre la definición de la BD o la BD misma.
Logs Contables de Auditoría
Como resultado, los logs de auditoría deben permitir una de dos alternativas:
1) una operación de implosión
2) una operación de explosión
Explosión: permitir la reconstrucción de la secuencia
cronológica de eventos que le han ocurrido a un ítem de dato de cronológica de eventos que le han ocurrido a un ítem de dato de la definición de la BD o de la BD misma.
La estampilla de tiempo puede ser clasificada dentro del
Logs Contables de Auditoría
Segundo: el SBD debe asociar una imagen anterior y otra posterior del ítem de dato.
Se hace una entrada para la transacción en el log de auditoría junto con estas imágenes – en el caso de una modificación. Para altas, bajas, y consultas se puede setear un flag para Para altas, bajas, y consultas se puede setear un flag para indicar que ambas imágenes coinciden.
Esto tiene dos propósitos:
1) facilitar las consultas sobre logs de auditoría: los efectos de la transacción serán determinados inmediatamente
consultando el log
2) proveer redundancia: una eliminación fraudulenta de una entrada del log de auditoría o una alteración de una
Logs Contables de Auditoría
Tercero: el SBD debe proveer facilidades para definir, crear, modificar, eliminar, y recuperar datos desde los logs de
auditoría, ya que estos requieren un almacenamiento permanente o semipermanente.
Usualmente los logs de auditoría no deberían ser modificados ya que reflejan la verdad de lo sucedido.
que reflejan la verdad de lo sucedido.
Sin embargo, esto puede suceder porque:
1) el sistema de aplicación que actualiza la BD procesa datos erróneamente
Logs Contables de Auditoría
Algunos problemas surgen al manejar logs de auditoría.
Consideremos las implicaciones que tienen en el log de auditoría los siguientes tipos de cambios:
1) se define un nuevo ítem de dato 2) se elimina un ítem de dato
2) se elimina un ítem de dato
3) se modifica el nombre de un ítem de dato
4) se modifica la escala de medición de un ítem de dato - de kilogramos a toneladas
5) se modifica el dominio de un dato - de numérico a alfanumérico
Logs Contables de Auditoría
De esta manera, pueden surgir problemas cuando los usuarios quieren recuperar datos desde logs de auditoría, que
pertenecen a un período de tiempo en el cual ocurrió algún cambio que afectó los logs de auditoría.
El sistema debería detectar la situación y proveer el conjunto completo de transacciones, aún aquellas afectadas.
completo de transacciones, aún aquellas afectadas.
Alternativamente, debería alertar al usuario del cambio e invalidar la consulta.
Una importante decisión a tomar es el período por el cual debieran mantenerse los logs de auditoría.
Logs de Auditoría de Operaciones
Los logs de auditoría de operaciones mantienen la cronología de los eventos que consumen recursos que afectan la definición de la BD o la BD.
Los administradores de base de datos deben tomar dos decisiones:
decisiones:
1) en función de los tiempos o la cantidad de recursos requeridos para aplicar transacciones puede surgir la necesidad de reorganizar la BD.
2) en función de los datos de consumo de recursos, puede surgir que sea necesario reestructurar o reescribir el proceso que aplica las transacciones a la BD.
Controles de Existencia
Una porción o toda la BD podría ser perdida (destruida o corrompida) debido a 5 tipos de fallas:
1) Error del programa de aplicación: un programa puede actualizar incorrectamente la BD debido a un bug.
Usualmente ocurren sólo daños localizados, ya que el programa actualiza un pequeño subconjunto de datos. programa actualiza un pequeño subconjunto de datos.
2) Un error del software del sistema: el sistema operativo, DBMS, monitor de telecomunicaciones, o programa de utilidad, podría contener un bug. El bug podría llevar a actualizaciones erróneas de la BD, corrupción de datos, o crash del sistema. Dependiendo de la naturaleza del bug,
Controles de Existencia
3) Fallas de hardware: a pesar de la alta confiabilidad, algún componente de hardware puede fallar. La falla podría ser menor y como resultado sólo ocurren daños localizados . Sin embargo la falla podría ser seria, y producir daños permanentes en la BD - un crash de disco.
4) Error procedural: un operador o usuario podría cometer un error que dañe la BD. - un operador podría realizar una operación incorrecta en la recuperación de un crash de sistema, o un usuario ingresa mal los parámetros para un proceso de actualización.
El tipo de daño (local o global) dependerá de la naturaleza del error.
Controles de Existencia
5) Fallas ambientales: terremotos, incendios, sabotaje, pueden ocurrir, y en general sus consecuencias son graves. En estos casos son esenciales los backups de archivos guardados fuera del sitio.
Los controles de existencia del SBD deben recuperar la BD ante Los controles de existencia del SBD deben recuperar la BD ante un evento de pérdida.
Involucran estrategias de back-up y estrategias de recuperación.
Todas las estrategias de back-up involucran mantener una copia de la versión anterior de la BD y un log de transacciones o
Controles de Existencia
Las estrategias de recuperación toman dos formas:
1) En caso de pérdida de la BD se debería recuperar el estado actual. Esto incluye una operación de rollforward
usando una versión anterior de la BD y un log de las transacciones aplicadas desde la fecha de la versión de la BD recuperada.
la BD recuperada.
2) Se podría necesitar recuperar un estado anterior de la BD, ya que el estado actual es inválido. Esto involucra una operación de rollback para deshacer las
transacciones que dañaron la BD. Se utiliza el log de las modificaciones.
Controles de Existencia
El auditor debe analizar:
1) que una BD destruida o dañada pueda ser reconstruida de manera auténtica, completa, exacta y en tiempo
2) que la privacidad de los datos es mantenida durante las 2) que la privacidad de los datos es mantenida durante las
Back-up: Estrategia Abuelo-Padre- Hijo
Involucra mantener las 2 versiones previas del archivo maestro y los últimos dos logs de transacciones que los actualizaron.
Si la versión actual del archivo maestro (hijo) se pierde, puede ser recuperada a partir del archivo maestro padre procesando nuevamente el archivo de transacciones
Si la versión del archivo maestro padre se pierde durante la recuperación, esta también puede ser recuperada usando la
versión abuelo del archivo maestro y la versión previa del archivo de transacción.
Es una de las primeras estrategias y los backups se realizaban en cintas magnéticas.
Transac-ciones
Maestro
(input)
Back-up: Estrategia Abuelo-Padre- Hijo
Maestro
(output)
Reporte
De Actualiza
Programa de
Actualización
Ventajas:
1) Simplicidad
Desventajas:
1) No es adecuado cuando hay procesos concurrentes que actualizan la BD.
Back-up: Estrategia Abuelo-Padre- Hijo
actualizan la BD.
2) La recuperación es lenta cuando el daño a la BD es parcial, ya que en este caso se debe recuperar la totalidad de la BD.
3) El archivo hijo no está disponible hasta que se finalice totalmente la recuperación.
Estrategia: Espejado y Grabación Dual
Involucra mantener dos copias completamente separadas de la BD y actualizar ambas simúltaneamente.
Se tienen en diferentes ubicaciones físicas. De esta manera,
sirve como protección para fallas del entorno. Si estuvieran en el mismo lugar, sólo protege de un falla de discos.
Si hubiera problemas de procesador, se debe usar un segundo procesador.
Cuando ocurre una falla, la BD y el procesador secundario se convierten en primarios.
Se utilizan dos estrategias de recuperación:
1) se debe tomar una copia intacta de la BD, en un
momento que sea conveniente. Se deben bloquear los accesos mientras se realiza la copia
2) se debe mantener un log de las transacciones que han sido procesadas desde que se copia la BD - deben
Estrategia: Espejado y Grabación Dual
sido procesadas desde que se copia la BD - deben procesarse estas transacciones luego de restaurar la copia de la BD.
Esta estrategia es usada si:
1) es importante una recuperación rápida de la BD dañada, 2) existen tiempos no picos en los cuales se puede copiar
Procesador
Procesador
Primario
BD
Primaria
Remoto
Estrategia: Espejado y Grabación Dual
Procesador
Frontend
Procesador
Secundario
BD
Secundaria
Ventaja:
1) permite que la BD esté disponible continuamente
Desventajas:
1) es costoso mantener los recursos duplicados – costo en hardware.
Estrategia: Espejado y Grabación Dual
en hardware.
2) no protege ante fallas procedurales, fallas del sistema o errores de programas de aplicación
3) estos errores corrompen tanto la BD primaria como la secundaria
4) de este modo, un segundo back-up y estrategia de recuperación deben ser usados para recuperar la BD luego de que sucedan estos tipos de errores.
Dumping
Involucra copiar todo o una porción de la BD a algún medio de back-up (Ej: cartridge).
La recuperación involucra recuperar el dump (la copia) de
backup en el medio de almacenamiento primario y reprocesar las transacciones a partir del dump tomado.
Los usuarios podrían ser responsables de reprocesar las
transacciones que han ocurrido a partir del tiempo del último dump.
Alternativamente, un log de transacciones puede ser mantenido entre dumps.
Dumping – Dumping Físico
El dumping físico involucra leer y copiar la base de datos en el orden serial de los registros físicos sobre el medio de
almacenamiento, por ejemplo track por track.
En algunos casos, límites físicos definen el espacio ocupado por un archivo, ejemplo, sólo un archivo puede ser asignado a un particular disco; y así, el dumping puede ser selectivo.
un particular disco; y así, el dumping puede ser selectivo.
En otros casos, el archivo está disperso a través de múltiples locaciones físicas y entrelazado con otros archivos, por lo cual dumping selectivo del archivo puede ser dificultoso o casi
Dumping – Dumping Lógico
El dumping lógico involucra leer y copiar la BD en el orden serial de los registros lógicos en un archivo.
La facilidad de backup simplemente graba un archivo a un medio de almacenamiento
Cuando un archivo es dañado y debe ser recuperado, el espacio almacenado ocupado por el archivo dañado es liberado. Luego se copia el dump en el almacenamiento primario.
El dumping lógico se vuelve complejo cuando los datos son
compartidos, y los registro en un archivo son también miembros de otros archivos.
Dumping
En una primera visión, el dumping físico puede hacerse más rápido.
El dumping lógico puede hacerse selectivo, y se podría hacer sólo de aquellos archivos que se han modificado luego del último dump.
En base a esto, el dumping físico puede consumir más recursos que el dumping lógico.
El dumping físico facilita la recuperación global de la BD, cuando esta es dañada globalmente, por fallas ambientales o fallas de dispositivos.
Logging
El logging involucra:
1) registrar una transacción que cambia la BD, o
2) registrar una imagen del registro cambiado en la BD por la acción de actualización.
Luego, el log puede ser usado para recuperar la BD hasta el Luego, el log puede ser usado para recuperar la BD hasta el punto de falla.
Logging
La estrategia alternativa, que requiere que los usuarios
reprocesen transacciones para recuperar la BD al punto de falla, podría no ser viable por varias razones:
1) el tiempo de inactividad requerido para que los usuarios reprocesen todas las transacciones
reprocesen todas las transacciones
2) recuperar la BD podría requerir que las transacciones sean reprocesadas en un orden especificado
3) si los usuarios no registran las transacciones en una secuencia de tiempo, o existen múltiples fuentes de entrada, podría ser imposible recuperar la secuencia correcta para reprocesar las transacciones.
Logging
Hay tres estrategias de logging:
1) logging de transacciones de entrada
2) logging de imágenes anteriores del registro cambiado 3) logging de imágenes anteriores del registro cambiado.
Logging de Transacciones de Entrada
Involucra reprocesar las transacciones de actualización desde el tiempo del último dump hasta el tiempo en que la BD se dañó.
Para realizar la recuperación, se debe almacenar junto con la transacción información tal como: el tiempo y fecha de
procesamiento, el archivo actualizado, el programa que realiza la actualización.
la actualización.
Un problema con esta estrategia es determinar como las
transacciones de entrada deberían ser reprocesadas durante la recuperación.
Logging de Transacciones de Entrada
Dos enfoques:
1) tener un programa de actualización de recuperación especial que lee el log y actualiza la BD en la misma forma en que los programas de aplicación realizaron sus actualizaciones.
No debería considerar muchos contenidos lógicos incluidos en los programas de la aplicación, por ej, generación de
reportes, funciones de manejo de interfaces, etc. reportes, funciones de manejo de interfaces, etc.
2) tener un programa general que lee el log y para cada
transacción llama al programa de aplicación que actualizó la BD con esa transacción. Se debe guardar la identificación del programa que trató cada transacción. Estos programas
Logging de Transacciones de Entrada
En algunos casos, la recuperación puede realizarse más rápidamente clasificando las transacciones.
Por ejemplo, todas las transacciones para un registro particular pueden ser clasificadas juntas, sus efectos sumados, y se
procesa una única actualización frente a la BD.
En algunos casos, esto no puede aplicarse ya que es importante una secuencia de tiempo particular para la integridad de la BD.
Logging de Imágenes Anteriores
Esta estrategia es diseñada para facilitar rollback de la BD. Cada vez que un registro es actualizado, se graba en el log su imagen anterior a la actualización.
Si una transacción falla antes de hacer el commit, todas los cambios en la BD se deben deshacer.
Se debe hacer roll back al último punto de commit. Se lee el log de atrás hacia delante, y se usan las imágenes anteriores de los registros para reemplazarlos en la BD.
Similarmente, si un programa erróneo actualiza la BD, se puede hacer roll back hasta el punto donde el programa
Logging de Imágenes Posteriores
Esta estrategia es diseñada para facilitar rollforward de la BD.
Después que un registro ha sido actualizado por una transacción, su imagen es copiada en el log.
Por ejemplo, si un disco falla, la recuperación se hace a través de un rollforward usando el último dump de la BD y el log que de un rollforward usando el último dump de la BD y el log que guarda la imagen posterior del registro.
El log se lee hacia adelante, y la última imagen posterior leída del log, constituye la última versión del registro en la BD antes de la falla.
El overhead asociado con estas dos estrategias es alto, pues la adición o eliminación de un registro sobre la BD puede implicar
Dumping Residual
La motivación principal es solucionar el overhead por un dump completo de la BD.
Un log de la BD solamente es insuficiente, ya que se correría el riesgo de tener que recorrer todo el log desde la creación de la BD.
Debido a esto surge la idea de hacer dumps de la BD. Los dumps son costosos porque:
1) pueden demorar mucho tiempo
Dumping Residual
El dumping residual involucra hacer un log de aquellos registros que no han sido modificados desde el último dump residual.
Se usa en conjunto con estrategias de logging de imágenes anteriores e imágenes posteriores
A los registros del dump residual se les coloca un flag para indicar que las imágenes anterior y posterior son idénticas.
Se utilizan las imágenes posteriores de los logs de transacciones para reconstruir aquellos datos que han cambiado, y el dump residual para recuperar los datos que no se han modificado.
Dumping Residual
Ventajas sobre el dump tradicional:
1) no se excluyen durante el dumping residual posibles procesos de actualización concurrente de la BD. Para grandes BD, esta estrategia de backup puede ser la
única posible. Para BDs con mucho tiempo de dump, el dumping residual sólo sirve como estrategia de back-up. 2) se hacen menos duplicaciones ya que un registro se
2) se hacen menos duplicaciones ya que un registro se copia sólo una vez, a menos que haya sido modificado varias veces
3) ofrece mayor flexibilidad, para nivelar la sobrecarga del sistema, ya que puede ser ejecutado como una
Archivos Diferenciales y Shadow Paging
Un archivo diferencial es un archivo en cual se guardan los cambios hechos sobre la BD.
La BD permanece intacta.
Los registros actualizados se escriben sobre archivos diferenciales.
Ante el acceso a un registro, este se deberá localizar en la BD y en el archivo diferencial.
Cuando el tamaño del archivo diferencial crece demasiado, se
produce overhead para mantenerlo y accederlo. Cuando se vuelve excesivo, los cambios deberían ser aplicados a la BD.
Archivos Diferenciales
Ventajas:
1) reduce los costos de dump sobre la BD, sólo el archivo diferencial requerirá dumps
2) facilita el dumping incremental, si las adiciones al archivo diferencial son ubicadas en direcciones
secuenciales del dispositivo secundario, sólo se necesita secuenciales del dispositivo secundario, sólo se necesita hacer dump de esta parte
3) permite dumping en tiempo real y reorganización con actualizaciones concurrentes. Hacer un diferencial de un archivo diferencial
Shadow Paging
Una variación a la estrategia de archivo diferencial es la
estrategia de shadow paging, que divide a la BD en páginas.
Una tabla de páginas con punteros a las páginas de la BD es creada, y si no es grande es mantenida en memoria principal. Existe una tabla a la sombra almacenada en disco.
Cuando el sistema procesa una transacción, primero copia el contenido de la página actual a la tabla de página en disco
(shadow page table). Si la transacción actualiza la BD, la nueva página se copia a una nueva área de disco.
Shadow Paging
Ventaja: la simplicidad, pues se facilita el rollback ante una falla.
Desventaja: no es una estrategia de back-up completa, necesita complementarse con dumps y registros de imágenes posteriores.
