Identificar agentes fundamentales

Para la recuperación es necesario los online redo log files y al archived log files.

TIPOS DE CHECKPOINT:

• Checkpoint incremental: La posición del checkpoint es avanzada automáticamente por el DBWn. Este proceso es conocido como checkpoint incremental.

• Checkpoint lleno: Ocurre cuando todos los buffers sucios son escritos al disco. En una ejecución normal puede haber cientos de miles de buffers sucios y solo debería ocurrir cuando se produce un shutdown ordenado, o por que lo haga el DBA.

• Checkpoint parcial: Un checkpoint parcial es necesario y ocurre automáticamente cuando se realiza ciertas operaciones.

Dependiendo de la operación el checkpoint parcial afectará a diferentes buffers, las operaciones son:

• Pasar un tablespace a offline: Afecta a todos los bloques que son parte del tablespace.

• Pasar un fichero de datos a offline: Afecta a todos los bloques que son parte del fichero de datos.

• Eliminar un segmento: Afecta a todos los bloques que son parte del segmento.

• Truncar una tabla: Afecta a todos los bloques que son parte de la tabla.

• Poner un tablespace en modo backup:Afecta a todos los bloques que son parte del tablespace.

Un checkpoint lleno ocurren por un cierre ordenado o a petición. Un checkpoint parcial es automático por necesidad. ONLINE REDO LOG FILES: Una base de datos requiere al menos dos grupos de online redo log file, se pueden crear más pero 2 es el mínimo. Cada grupo tiene uno o varios miembros, que son los archivos fisicos, un grupo puede tener solo un miembro pero por seguridad se debería tener dos miembros por cada grupo.

El único modo de proteger contra la perdida de datos cuando se pierden todos los miembros del grupo online redo log, es configurar un ambiente Data Guard. Si los miembros del Online Redo Log no están disponibles, no se podrá hacer el roll forward en caso de fallo de instancia y no se podrá abrir la base de datos.

Los online redo log pueden configurarse mientras la base de datos está abierta. Para configurar el fichero de control la base de datos tiene que estar en estado no montada (nomount) o apagada.

Si un miembro de un grupo del redo log file es dañado, la base de datos permanecerá abierta mientras haya algún otro miembro válido.

Si cualquier copia del fichero de control es dañada, la base de datos se estrellará inmediatamente. Mientras haya al menos dos grupos y un miembro en cada grupo, los grupos del online redo log como los miembros de cada grupo pueden ser añadidos, borrados o movidos.

Si la base de datos se crea con el DBCA se creara 3 grupos con un miembro en cada grupo:

• Para ver los grupos del online redo log file se utiliza la vista V$LOG.

• Para ver los miembros de cada grupo se utiliza la vista V$LOG, y para saber dónde están físicamente se usa la vista V$LOGFILE.

Para que cambien el switch del log se utiliza:

• ALTER SYSTEM SWITCH LOGFILE

Esta sentencia hace que la secuencia se incremente y se utilice el siguiente grupo. El grupo anterior pasa a estado active y el grupo que se está utilizando pasa a estado current. Los estados de los grupos online log file son:

• Inactive: No se está utilizando.

• Active: El grupo se puede utilizar por si sucede un fallo de instancia.( pasara a Inactivo si se produce un Checkpoint)

• Current: Es el grupo que se está utilizando, para realizar el redo.

El número de miembros por grupo está indicado en el fichero CreateDB.sql, están las directivas:

• MAXLOGFILES: Limita el número de grupos que la base de datos puede tener.

• MAXLOGMEMBERS: Limita el número de miembros máximo de cada grupo.

Para añadir un miembro a un grupo se utiliza:

• ALTER DATABASE ADD LOGFILEMEMBER ‘rutaREDO01A.LOG[ TO GROUP 1

MODO ARCHIVELOG Y PROCESO DE ARCHIVO: Oracle garantiza que la base de datos nunca sea corrompida, por el uso de los online redo log files para reparar cualquier corrupción que haya sido causada por el fallo de la instancia. Es automática e inevitable, pero para garantizar que no se pierda ningún dato después del fallo de la instancia, será necesario tener registrado todos los cambios aplicados a la base de datos desde la última copia de seguridad, esto no está por defecto.

Cuando la base de datos esta en modo archivelog, los ficheros online redo log file, no podrán ser borrados hasta que hayan sido escritos en el histórico, de este modo tendremos una historia completa de todos los cambios producidos en la base datos, y si un archivo es dañado, podrán recuperarse todos los datos.

Una vez que tenemos la base datos configurada en modo archivelog, comenzará un nuevo proceso background automáticamente, el ARCn. Oracle por defecto comenzará cuatro de estos procesos, pero puede haber hasta un máximo de treinta.

El modo archivelog copia los Online Redo Log Files en el histórico después de cada log switch, generando una cadena continua de registros de actividades que pueden ser usados para hacer copias de seguridad.

El nombre y la posición de estos archivos son controlados por parámetros de inicialización, los archive log files pueden ser multiplexadas, pero al final estos han de ser emigrados a un almacenamiento online, como una cinta.

La instancia de Oracle es quien crea los archive logs con el proceso ARCn, pero la migración d