Gestión Avanzada de Copias de Seguridad y Sistemas Distribuidos en Oracle

UT08: Recuperación de Datos en Oracle

1) Posibilidades de Copias de Seguridad en Oracle

Oracle ofrece diversas herramientas para la gestión de copias de seguridad:

Herramienta RMAN (Recovery Manager): Es la opción preferente debido a su potencia y amplias posibilidades. Permite utilizar comandos específicos del sistema para la gestión de copias.
Enterprise Manager: Proporciona la capacidad de realizar copias de seguridad a nivel de tablas, esquemas, *tablespaces* individuales o la base de datos completa.
Recuperaciones de tipo Flashback: Consiste en devolver toda la base de datos, o una parte de ella, a un punto anterior en el tiempo donde los datos eran consistentes.

2) Tipos de Copias de Seguridad

Las copias de seguridad se clasifican según el estado de la base de datos y el nivel de abstracción:

En Frío: La base de datos debe estar apagada.
En Caliente: La base de datos permanece encendida y operativa.
Lógicas: Se realizan en caliente y permiten exportar o importar datos concretos de la Base de Datos mediante utilidades específicas.
Físicas: Pueden ser en frío o en caliente, y realizan una copia exacta de los archivos de la base de datos.

3) Copias Físicas en Frío

Se realizan con la base de datos apagada y sin permitir acceso a los usuarios. Aunque permiten una copia exacta, no son prácticas en grandes sistemas de producción que requieren disponibilidad permanente.

Estas copias consisten en duplicar los archivos fundamentales de la base de datos:

Archivos de control.
Archivos de datos.
Archivos *Redo Log*.

Opcionalmente, se pueden copiar los archivos de parámetros de inicialización: init.ora y spfile.ora. Copiar estos archivos asegura una imagen exacta de la base de datos.

Para restaurar la base de datos, se copian los archivos de seguridad a sus directorios correspondientes y se inicia la base de datos con el comando STARTUP.

4) Copias de Seguridad Lógicas

Las copias lógicas leen los datos de la base de datos y los extraen generando un archivo de exportación, el cual puede ser recuperado con la orden IMPORT de Oracle. Se pueden importar usuarios, tablas, *tablespaces* y bases de datos completas.

Las utilidades IMPORT y EXPORT permiten:

Archivar datos históricos (copias de esquemas tras cambios).
Guardar definiciones de tablas (con o sin datos) como protección ante fallos de usuarios.
Transportar *tablespaces* de una base de datos a otra.

Utilidad EXPORT

Se ejecuta desde el intérprete de comandos del Sistema Operativo. Los parámetros más comunes son:

USERID: Nombre de usuario/contraseña para la exportación (opcional).
FILE: Nombre del archivo de salida (por defecto: expdat.dmp).
GRANTS: Especifica si se exportan las concesiones sobre los objetos (Y/N). Por defecto: Y.
ROWS: Especifica si se exportan las filas de las tablas. Por defecto: Y.
OWNER: Indica una lista de cuentas a exportar.
CONSTRAINTS: Especifica si se exportan las restricciones (Por defecto: Y).
TRIGGERS: Especifica si se exportan los *triggers* (Por defecto: Y).
TABLES: Especifica la lista de tablas a exportar.
QUERY: Especifica la cláusula WHERE a aplicar a cada tabla durante la exportación.
TABLESPACES: Especifica los *tablespaces* a transportar.

Modos de exportación:

Modo tabla:: Exporta definiciones de tablas, datos o filas seleccionadas, concesiones e índices del propietario, y restricciones.
Modo usuario:: Exporta todos los objetos del esquema del usuario.
Modo tablespace:: Mueve los *tablespaces* de una base de datos a otra.
Modo de base de datos completa:: Exporta todos los objetos de la base de datos, excepto los esquemas SYS.

Utilidad IMPORT

Se utiliza para la recuperación de archivos de exportación. Los parámetros más comunes son:

USERID: Nombre de usuario/contraseña para la importación (opcional). Se requieren privilegios DBA o IMP_FULL_DATABASE.
FILE: Nombre del archivo de exportación a importar.
SHOW: Especifica si el contenido del archivo debe mostrarse (S/N) en lugar de ejecutarse. Por defecto: N.
FROMUSER: Lista de cuentas cuyos objetos deben leerse desde el archivo de exportación.

5) Recuperaciones de tipo Flashback

Esta tecnología permite corregir errores de usuario sin recurrir a copias de seguridad completas, devolviendo la base de datos (o una tabla) a un punto anterior en el tiempo.

Área de Rápida Recuperación (FRA)

Es esencial para el funcionamiento de las recuperaciones *flashback*. Es un espacio en disco dedicado a almacenar los archivos necesarios para retroceder a un punto seguro.

Se deben calibrar los siguientes parámetros:

DB_RECOVERY_FILE_DEST_SIZE: Tamaño asignado al FRA. Ejemplo: ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=5G;
DB_RECOVERY_FILE_DEST: Ruta donde se guardan los archivos *flashback*. Se recomienda que esté en una unidad de disco distinta a la de la base de datos.
DB_FLASHBACK_RETENTION_TARGET: Número máximo de minutos que se podrá retroceder la operación *flashback* desde el momento actual.

Para activar el uso de *flashback* a nivel de base de datos:

ALTER DATABASE FLASHBACK ON;

El parámetro UNDO_RETENTION permite especificar el tiempo máximo que se admitirá para deshacer los cambios definitivos.

Recuperaciones de Tablas mediante Flashback

Prerrequisitos:

Tener el privilegio FLASHBACK ANY TABLE o el permiso FLASHBACK sobre la tabla.
Privilegios SELECT, INSERT, UPDATE y ALTER sobre la tabla.
Para usar un punto de restauración, se debe tener asignado el rol SELECT_CATALOG_ROLE o el permiso SELECT ANY DICTIONARY.
Las tablas a recuperar deben tener activado el ROW MOVEMENT: ALTER TABLE tabla ENABLE ROW MOVEMENT;
Debe estar activada la posibilidad de *flashback* sobre la base de datos: ALTER DATABASE FLASHBACK ON;
Debe estar activado en el *tablespace* al que pertenece la tabla: ALTER TABLESPACE nombre FLASHBACK ON;

Para recuperar la tabla borrada se utiliza:

FLASHBACK TABLE tabla TO BEFORE DROP;

Tras la recuperación, es posible que los índices hayan cambiado de nombre y deban ser renombrados para su control.

UT09: Bases de Datos Distribuidas y Replicadas

1. Bases de Datos Distribuidas

Una base de datos distribuida es una colección de datos que lógicamente pertenecen a un único sistema, pero están físicamente dispersos en varios sitios de la red. El objetivo es que el usuario acceda a los datos remotamente como si estuvieran almacenados localmente. El **SGBDD** (Sistema Gestor de Bases de Datos Distribuidas) maneja esta dispersión haciéndola transparente al usuario.

Ventajas de las BDD

Mayor rapidez en el acceso a los datos y capacidad de almacenamiento.
Acceso más flexible.
Escalabilidad.
Fiabilidad y cierta capacidad de tolerancia a fallos.

Inconvenientes de las BDD

Costosos de implementar debido a la duplicidad de recursos (red y servidores).
Dificultad en la administración de datos ubicados en distintas localizaciones.
Dependencia de las redes de comunicaciones para el correcto intercambio de datos.
Complejidad en el procesamiento de consultas y propagación de actualizaciones.
Administración del catálogo distribuido.

Tipos de BDD

Dependiendo de los componentes elegidos:

Homogéneas: El SGBD utilizado es el mismo en todas las bases de datos locales.
Heterogéneas: Las bases de datos están distribuidas independientemente del SGBD local. Pueden requerir aplicaciones mediadoras para la cooperación de transacciones.

Sistemas Centralizados vs. Distribuidos

Sistemas Centralizados: Un solo DBA. Se busca la independencia de datos (transparente para el programador) y la reducción de redundancia.
Sistemas Distribuidos: Control jerárquico (DBA global y local). Ofrecen transparencia en la distribución, replicación de datos (aumentando disponibilidad) y problemas de seguridad intrínsecos.

2. Componentes SGBDD

Para crear una base de datos distribuida se requieren:

Un SGBD.
Un conjunto de bases de datos locales en cada servidor.
Una red de comunicaciones.
Un diccionario de datos global que mapee la ubicación de cada dato.

Funcionalidades de un SGBDD

Acceder a sitios remotos y transmitir consultas/datos a través de la red.
Almacenar el esquema de distribución y replicación en el catálogo del sistema.
Establecer estrategias de ejecución para consultas y transacciones que acceden a múltiples sitios.
Decidir sobre qué copia de los datos replicados acceder.
Mantener la consistencia de las copias de datos replicados.
Realizar la recuperación ante fallos.

3. Almacenamiento de Datos

Se refiere al posicionamiento de los datos y el esquema bajo el cual se organizan. Los tipos principales son la réplica y la fragmentación.

Replicación de Datos

El sistema conserva varias copias o réplicas idénticas de una tabla, almacenadas en nodos diferentes.

Ventajas:

Disponibilidad: El sistema sigue operativo si un nodo cae.
Aumento del paralelismo: Múltiples nodos pueden consultar la misma tabla simultáneamente, minimizando el tráfico entre nodos si el dato está localmente disponible.

Inconveniente:

Aumento de la sobrecarga en las actualizaciones: El sistema debe asegurar la consistencia propagando los cambios a todas las réplicas.

Fragmentación de Datos

Consiste en dividir la información de la BD en partes más pequeñas que se reparten entre los nodos. Cada fragmento contiene información suficiente para reconstruir la tabla original, y no hay duplicación de registros, lo que reduce el coste de almacenamiento a costa de la disponibilidad si un nodo falla.

La fragmentación puede ser horizontal o vertical, y aplicarse de forma sucesiva o alternativa.

Fragmentación Horizontal

Los fragmentos son subconjuntos de una tabla definidos mediante una operación de selección. La tabla original se reconstruye mediante una operación de unión de los fragmentos.

Fragmentación Vertical

Los fragmentos son subconjuntos de los atributos con sus valores. Para recomponer la tabla original, cada fragmento debe incluir la clave primaria de la tabla.

Fragmentación Mixta

Es una combinación de las técnicas horizontal y vertical.

Para que una fragmentación sea correcta, debe cumplir:

Ser completa: Cada elemento de la tabla debe estar en algún fragmento.
Ser reconstruible.
Los fragmentos deben ser disjuntos.

4. Consultas Distribuidas

Oracle basa su concepto de BDD en el objeto DATABASE LINK. Un DATABASE LINK es una conexión unidireccional entre una base de datos cliente y otra servidora, creada desde la base de datos que desea referenciar a la otra.

Privilegios necesarios para crear DB Links:

CREATE DATABASE LINK (privado, local).
CREATE PUBLIC DATABASE LINK (público).
CREATE SESSION (en el sitio remoto).

Para crear un DB Link es imprescindible que exista la conexión entre las bases de datos a través de **Oracle Net Services**, lo que implica configurar una entrada en el fichero tnsnames.ora de la base de datos referenciada.

5. Transacciones Distribuidas

Aquella transacción que involucra sentencias ejecutadas en dos o más nodos dentro de un entorno distribuido. Los elementos intervinientes son:

BD Cliente: Nodo que origina la referencia a la transacción distribuida y posee los DB Links.
BD Servidor: Bases de datos que contienen la información a modificar.
Coordinador Local: Nodo que referencia datos en otros nodos para completar su parte de la transacción.
Coordinador Global: Nodo donde se origina la transacción distribuida.
Commit Point Site: Nodo que inicia las operaciones de COMMIT o ROLLBACK, generalmente el que tiene el valor mayor en un parámetro específico.

El SGBDD garantiza la atomicidad mediante un mecanismo de tres pasos:

Fase de Preparación

El coordinador global notifica a todos los nodos la inminente operación de COMMIT o ROLLBACK. Cada nodo se prepara realizando dos tareas:

Almacenar la información en los *Redologs*.
Generar un bloqueo distribuido sobre la tabla para prevenir lecturas.

Fase de Commit

Una vez que todos los nodos confirman su preparación:

El coordinador global avisa al Commit Point Site para que realice el COMMIT.
El Commit Point Site ejecuta el COMMIT y notifica al coordinador global.
Los coordinadores (global y locales) envían mensajes a todos los nodos para ejecutar el COMMIT local.
Cada nodo realiza su parte local del COMMIT y elimina el bloqueo distribuido.
Todos los nodos notifican al coordinador global que completaron el COMMIT.

Fase de Olvido

Cuando el Commit Point Site recibe la confirmación de todos:

El Commit Point Site borra la información sobre el estado de la transacción distribuida e informa al coordinador global.
El coordinador global borra la información restante de la transacción distribuida.

6. Replicación de Bases de Datos

Es una técnica para incrementar el rendimiento de accesos y consultas mediante la introducción de redundancia. Se necesita un nodo maestro (canalizador de modificaciones) y nodos esclavos (que reciben las actualizaciones). Los cambios se almacenan en ficheros de *logs* para ser aplicados por los esclavos.

En bases de datos replicadas, todas las actualizaciones deben realizarse en el nodo maestro, dejando los nodos esclavos solo para consultas.

Se distinguen dos tipos de replicación:

Síncrona: Los cambios se propagan inmediatamente tras cada operación, manteniendo una conexión abierta constante.
Asíncrona: La más común. Los cambios se propagan en intervalos de tiempo definidos.

7. Las 12 Reglas de un Sistema Distribuido (Según el Modelo)

Autonomía local.
No dependencia de un sitio central.
Operación continua.
Independencia de ubicación.
Independencia de fragmentación.
Independencia de replicación.
Procesamiento de consultas distribuidas.
Administración de transacciones distribuidas.
Independencia de *hardware*.
Independencia de sistema operativo.
Independencia de red.
Independencia de DBMS.