UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE CIENCIAS ECONOMICAS

CARRERA DE FINANZAS

TÉCNICAS DE RECUPERACIÓNDE BASES DE DATOS

Luis Pillajo

Aula 39

Técnicas de recuperaciónde bases de datos

Conceptos de recuperación

Luis Pillajo

Capítulo 19

Descripción de la recuperación y clasificación de los algoritmos de

recuperación

Luis Pillajo

Técnicas de recuperación de bases de datos

1. El método de recuperación restaura una copia de seguridad antigua de la base de datos que normalmente se archiva en cinta a partir de la copia de seguridad del registro.

2. También puede ser necesario rehacer algunas operaciones durante la recuperación se consultan las entradas guardadas en el registro del sistema online.

Almacenamiento en caché (búfer) de los bloques de disco

Normalmente, una o más de las páginas de disco que incluyen los elementos de datos que se van a actualizar se almacenan en caché en los búferes de la memoria principal, y después se actualizan en memoria antes de escribirse de nuevo en el disco.

Se utiliza un directorio para la caché a fin de rastrear los elementos de la base de datos que se encuentran en los búferes.!

Puede ser necesario limpiar algunos de los búferes de la caché para conseguir espacio para el elemento nuevo. Para seleccionar los búferes que se van a limpiar se puede utilizar alguna estrategia de sustitución de página propia de los sistemas operativos.

Cuando el contenido del búfer es reemplazado (limpiado) de la caché. También necesitamosotro bit, denominado bit pin-unpin

Luis Pillajo

Almacenamiento en caché (búfer) de los bloques de disco

• La primera, conocida como actualización en el lugar (in-place),

escribe el búfer en la misma ubicación de disco original, por lo que sobrescribe el valor antiguo de cualquier elemento de datos modificado en disco.

• Conocida como shadowing (en la sombra), escribe un búfer

actualizado en una ubicación diferente del disco, por lo que pueden conservarse varias versiones de los elementos de datos.

Luis Pillajo

El almacenamiento en caché es tradicionalmente una función del sistema operativo, pero debido a su importancia en la eficacia de los procedimientos de recuperación, el DBMS se encarga de hacerlo llamando a rutinas de bajo nivel de los sistemas operativos.Al volcar a disco un búfer modificado podemos utilizar dos estrategias:

Registro antes de la escritura, robar/no-robar y forzar/no-forzar

Una entrada de registro del tipo REHACER incluye el valor nuevo (AFIM) del elemento escrito por la operación, ya que lo necesitamos para rehacer el efecto de la operación a partir del registro del sistema (estableciendo el valor del elemento en la base de datos a su AFIM).

Las entradas de registro del tipo DESHACER incluyen el valor antiguo (BFIM) del elemento, ya que lo necesitamos para deshacer el efecto de la operación a partir del registro del sistema

Luis Pillajo

El mecanismo de recuperación debe garantizar la grabación de la BFIM del elemento de datos en la entrada apropiada del registro del sistema y que esa entrada se vuelque en disco antes de que la BFIM sea sobrescrita con la AFIM en la base de datos en disco. Este proceso se suele denominar registro antes de la escritura.

Luis Pillajo

Robar/no-robar Y

Forzar/no-forzar

Si una página en caché actualizada por una transacción no puede escribirse en disco antes de que la transacción se confirme, se denomina método no-robar. Si el protocolo permite escribir un búfer actualizado antes de que la transacción se confirme, se denomina robar.

Si todas las páginas actualizadas por una transacción se escriben inmediatamente en disco cuando la transacción se confirma, se denomina método forzar. En caso contrario, se conoce como no-forzar.

Puntos de control en el registro del sistema y puntos de control difusos

Luis Pillajo

Si una transacción falla por cualquier razón después de actualizar la base de datos, es posible tener que anular la transacción.

Luis Pillajo

Luis Pillajo

Técnicas de recuperación basadas en la actualización

diferida

Una transacción no puede modificar la base de datos en disco hasta haber alcanzado su punto de confirmación.

Una transacción no alcanza su punto de confirmación hasta que todas sus operaciones de actualización se han grabado en el registro del sistema y este último se ha escrito en el disco.

Acciones de transacción que no afectan a la base de datos

Luis Pillajo

En general, una transacción tendrá acciones que no afectan a la base de datos, como la generación e impresión de mensajes o informes a partir de la información recuperada de la base de datos.

Técnicas de recuperación basadas en la actualización

inmediata

1. Utiliza dos listas de transacciones que el sistema se encarga de mantener: las transacciones confirmadas desde el último punto de

control y las transacciones activas (como máximo, sólo una transacción entrará en

esta categoría porque el sistema es monousuario).

2. Deshace todas las operaciones escribir elemento

de la transacción activa a partir del registro del sistema,

utilizando el procedimiento DESHACER descrito a

continuación.

3. Rehace las operaciones escribir elemento de las

transacciones confirmadas a partir del registro del sistema, en el mismo orden en que se escribieron en dicho registro, utilizando el procedimiento

REHACER descrito anteriormente.

Luis Pillajo

Recuperación DESHACER/REHACER basada en la actualización inmediata en un entorno monousuario

Procedimiento RIU_S.

Utiliza dos listas de transacciones que el sistema se encarga de mantener: las transacciones confirmadas desde el último punto de control y las transacciones activas.

Deshace todas las operaciones escribir_elemento de las transacciones activas (no confirmadas), utilizando el procedimiento DESHACER. Las operaciones deben deshacerse en el orden inverso al orden en que se escribieron en el registro del sistema.

Rehace todas las operaciones escribir_elemento de las transacciones confirmadas a partir del registro del sistema, en el orden en que se escribieron en dicho registro.

Luis Pillajo

Procedimiento RIU_M.

Paginación en la sombra (shadowing)

Luis Pillajo

Algoritmo de recuperación ARIES

Luis Pillajo

El procedimiento de recuperación ARIES consta de tres pasos principales:

1. El análisis identifica las páginas sucias (actualizadas) en el búfer62. La fase REHACER realmente vuelve a aplicar a la base de datos las actualizaciones3. La fase DESHACER se explora el registro del sistema hacia atrás y se deshacen en orden

inverso las operaciones de las transacciones que estaban.

Recuperación en sistemas multibase de datos

Para mantener la atomicidad de una

transacción multibase de datos, es necesario tener un mecanismo de

recuperación de dos niveles. Necesitamos un

gestor de recuperación global, o

coordinador, para conservar la información

necesaria para la recuperación, además

de los gestores de recuperación locales y la

información que mantienen (registro del

sistema, tablas).

El efecto neto del protocolo de

confirmación en dos fases es que o todas las

bases de datos participantes confirman

el efecto de la transacción, o ninguna

de ellas lo hace.

En caso de que cualquiera de los

participantes(o el coordinador) falle,

siempre es posible volver a un estado en el

que la transacción se confirma o se anula.

Un fallo durante o antes de la fase 1

normalmente requiere que la transacción se

anule, mientras que un fallo

durante la fase 2 significa que una

transacción satisfactoria puede recuperarse y

confirmarse

Luis Pillajo

Copia de seguridad de la base de datos yrecuperación ante fallos catastróficos

Para evitar la pérdida de todos los efectos de las transacciones que se han ejecutado desde la última copia de seguridad, es costumbre hacer una copia de seguridad del registro del sistema a intervalos más frecuentes que la copia de seguridad de la base de datos completa, copiándolo periódicamente en la cinta magnética.Para recuperarse ante un fallo del disco, primero se vuelve a crear la base de datos en el disco a partir de su última copia de seguridad en cinta. A continuación, se reconstruyen los efectos de todas las transacciones confirmadas cuyas operaciones se han grabado en las copias de seguridad del registro del sistema.

Luis Pillajo

Conceptos de las bases dedatos de objetos

Las bases de datos son componentes fundamentales de muchos sistemas de software, y las bases de datos tradicionales son difíciles de utilizar con las aplicaciones orientadas a objetos que están desarrolladas con un lenguaje de programación orientado a objetos, como C++, Smalltalk o Java. Las bases de datos orientadas a objetos están diseñadas para que se integren directamente y sin problemas con las aplicaciones que están desarrolladas en dichos lenguajes.

Luis Pillajo

Capítulo 20

Panorámica de los conceptosde orientación a objetos

Luis Pillajo

Identidad del objeto

• Un sistema de bases de datos 00

proporciona una identidad única a cada objeto independiente almacenado en la base de datos. Esta identidad única suele implementarse mediante un identificador de objeto único, generado por el sistema, u orD.

• La principal propiedad que debe tener

un orD es la de ser inmutable, es decir, el valor de éste para un objeto particular no cambia. Esto preserva la identidad del objeto del mundo real que se está representando

Luis Pillajo

Estructura del objeto

Luis Pillajo

Los tres constructores más básicos son atom, tuple y set. Otros constructores que también se utilizan mucho son list, bag array. El constructor atom se utiliza para representar todos los valores atómicos básicos, como enteros, números reales, cadenas de caracteres, booleanos y cualquier tipo de datos básico que el sistema soporte directamente.

Constructores de tipos

Luis Pillajo

Encapsulamiento de operaciones,métodos y persistencia

El concepto de encapsulamiento es una de las principales características de los lenguajes y sistemas OO. También está relacionado con los conceptos de tipos de datos abstractos y ocultación de información en los lenguajes de programación. En los modelos y sistemas de bases de datos tradicionales, este concepto no se aplicaba porque lo habitual era que la estructura de los objetos de la base de datos fuera visible para los usuarios y programas externos.

Luis Pillajo

Especificación del comportamiento de los objetos a través de operaciones de clase

Los conceptos de ocultación de información y encapsulamiento pueden aplicarse a los objetos de bases de datos. La idea principal es definir el comportamiento de un tipo de objeto basándose en las operaciones que pueden aplicarse externamente a los objetos de ese tipo. Nuevo, y la operación destructor, que se utiliza para destruir un objeto.

También podemos declarar varias operaciones modificador de objeto para modificar los estados (valores) de varios atributos de un objeto. Operaciones adicionales pueden recuperar información sobre el objeto. Una operación se aplica normalmente a un objeto utilizando la notación de punto.

Luis Pillajo

Cómo especificar la persistencia de objeto a través de la denominación y la noción de alcance

Luis Pillajo

Jerarquías de tipos y herencia

EMPLEADO: Nombre, Direcc, FechaNac, Edad, Dni, Sueldo, FechaContrato, TiempoEnLaEmpresa

ESTUDIANTE: Nombre, Direcc, FechaNac, Edad, Dni, Especialidad, NotaMedia

Luis Pillajo

El nombre de una función lo podemos utilizar para referimos al valor de un atributo o al valor resultante de una operación (método). En esta sección utilizamos el término función para referimos indistintamente a los atributos y las operaciones de un tipo objeto, ya que se tratan de una forma parecida en una introducción básica a la herencia.Un tipo en su forma más simple puede definirse asignándole un nombre de tipo y, después, enumerando los nombres de sus funciones visibles (públicas).El concepto de subtipo resulta de utilidad cuando el diseñador o el usuario debe crear un tipo nuevo parecido pero no idéntico a un tipo definido ya existente. El subtipo hereda entonces todas las funciones del tipo predefinido, al que denominaremos supertipo. Por ejemplo, supongamos que queremos definir dos tipos nuevos, EMPLEADO Y ESTUDIANTE, de este modo:

Restricciones en las extensiones correspondientes a una jerarquía de tipos

Es común en las aplicaciones de bases de datos que cada tipo o subtipo tenga una extensión asociada, que alberga la colección de todos los objetos persistentes de ese tipo o subtipo. En este caso, la restricción es que cada objeto de una extensión que corresponde a un subtipo también debe ser miembro de la extensión que corresponde a su subtipo.

Algunos sistemas de bases de datos 00 tienen un tipo de sistema predefinido (denominado clase ROOT [raíz] o clase OBJECT [objeto]) cuya extensión contiene todos los objetos del sistema.

•

La clasificación procede entonces asignando objetos en los subtipos adicionales que son significativos para la aplicación, creando una jerarquía de tipos o de clases para el sistema.

Luis Pillajo

Objetos complejos

Luis Pillajo

Objetos complejos no estructurados y extensibilidad de tipos

Objetos complejos estructurados

Luis Pillajo

Otros conceptos de orientación a objetos

El polimorfismo de operaciones, que también se conoce como sobrecarga del operador. Este concepto permite que se vincule el mismo nombre de operador o símbolo a dos o más implementaciones diferentes del operador, dependiendo del tipo de objetos a los que se aplique ese operador. OBJETO_GEOMÉTRICO: Forma, Área, PuntoReferencia RECTÁNGULO subtipo-de OBJETO_GEOMÉTRICO (Forma='rectángulo'):

Anchura, Altura TRIÁNGULO subtipo-de OBJETO_GEOMÉTRICO (Forma='triángulo'):

lado1, lado2, Ángulo CíRCULO subtipo-de OBJETO_GEOMÉTRICO (Forma='círculo'): Radio

Luis Pillajo

Polimorfismo (sobrecarga del operador)

Herencia múltiple y herencia selectiva

Luis Pillajo

Versiones

Si el sistema ya está operativo, y si es preciso cambiar uno o más de sus módulos, el diseñador debe crear una versión nueva de cada uno de esos módulos para implementar los cambios.

Observe que puede haber más de dos versiones de un objeto

Es lo que se denomina con frecuencia ingeniería concurrente.

Luis Pillajo

CONFIGURACIONES

Una configuración del objeto complejo es una colección consistente en una versión de cada módulo planificada de tal forma que las versiones del módulo de la configuración son compatibles y, juntas, forman una versión válida del objeto complejo.

Una nueva versión o configuración del objeto complejo no tiene que incluir las versiones nuevas de cada módulo.

Por tanto, determinadas versiones de módulos que no han cambiado pueden pertenecer a más de una configuración del objeto complejo.

Luis Pillajo