Abf leccion 19

Jaime Amigo P. © 2006, Santiago - Chile

Instituto Profesional DuocUCEscuela de Ingeniería

Recuperación de Base de Datos

2


Objetivos

Después de completar esta lección usted aprenderá a recuperar la pérdida de:• Archivo de Control• Archivo de Redo log• Datafile

3


Abriendo una Base de Datos

Al abrir una base de datos:• Todos los archivos de control deben estar

presentes y sincronizados• Todos los archivos de datafile deben estar

presentes y sincronizados• Al menos un miembro de cada grupo de redo log

debe estar presente

SHUTDOWN

NOMOUNT

MOUNT

OPENSTARTUP

Abriendo una Base de DatosMientras una base de datos pasa de un estado shutdown a abierta ejecuta una seria de consistencias internas en dichas etapas.

• NOMOUNT: Para que una instancia pase al estado de NOMOUNT (tambiénconocido como iniciada (STARTED)), la instancia debe leer información del archivo de parámetros. No hay comprobación de los archivos de bases de datosen el estado NOMOUNT.

• MOUNT: Cuando una instancia pasa al estado MOUNT, chequea que todos los archivos de control indicados en el archivo de parámetros esten presentes y sincronizados. Si un archivo de control está erróneo o corrupto, la instanciaretornará un error al administrador notificando que existe un archivo de control dañado y regresara la instancia al estado NOMOUNT.

• OPEN: Cuando una instancia pasa de un estado MOUNT a OPEN indica que:- Chequea que todos los grupos de archivos de redo log conocidos en el

archivo de control tengan al menos 1 miembro presente. Cualquiernotificación de miembros inválidos sera notificado en el archivo de alertas de la base de datos.

4

Abriendo una Base de Datos (continuación)- Verifica que todos los datafiles conocido en el archivo de control estan

presentes a menos que estos hayan sido puestos offline. Los archivos offline no son chequeados hasta que el administrador intenta ponerlos online. El administrador puede colocar los datafiles offline y abrir la instancia siempreque estos datafile sean los de los tablespaces SYSTEM o. Si algún archivoestá dañado, un error es retornado al usuario mientras la instancia esta en estado MOUNT. Cuando la instancia encuentra archivos dañados, solo el primer archivo encontrado dañado es notificado como error. Para encontrartodos los archivos es necesaria una recuperación, el administrador puedechequear la vista v$recover_file para obtener información completa de los archivos que necesitan atención:

SQL> startupORACLE instance started.Total System Global Area 171966464 bytesFixed Size 775608 bytesVariable Size 145762888 bytesDatabase Buffers 25165824 bytesRedo Buffers 262144 bytesDatabase mounted.ORA-01157: cannot identify/lock data file 4 - see DBWR trace fileORA-01110: data file 4: '/oracle/oradata/orcl/users01.dbf'SQL> SELECT name, error2 FROM v$datafile3 JOIN v$recover_file4 USING (file#);

NAME ERROR----------------------------------- ------------------/oracle/oradata/orcl/users01.dbf FILE NOT FOUND/oracle/oradata/orcl/example01.dbf FILE NOT FOUND

- Verifique que todos los datafile que no están offline o solo de lectura, estánsincronizados con el archivo de control. Si es necesario, la recuperación de la instancia es automáticamente ejecutada. Sin embargo, si el archivo no esta sincronizado, solo puede ser recuperado usando los grupos de redo log online, entonces el administrador debe ejecutar un recovery de los medios de respaldos.

ORA-01113: file 4 needs media recoveryORA-01110: data file 4: '/oracle/oradata/orcl/users01.dbf'

Nuevamente, v$recover_file entrega un completo informe de los archivos querequieren atención. Los archivos que están presentes pero requierenrecuperarse son listados, pero no entregan un mensaje de error.

5


Cambiando el Estado de la Instancia

Use Database Control para alterar el estado de la instancia:

Cambiando el Estado de la InstanciaCuando se inicia la instancia, el modo por defecto de partida es OPEN. Usted puedeseleccionar comenzar la instancia en otro modo o bien por problemas con la base de datos, sea preciso iniciar la base de datos en otro modo. La página de opcionesavanzadas de Startup permite seleccionar otros modos diferentes de OPEN para iniciarla instancia y alterar el estado de una instancia que ya ha sido iniciada. También esposible utilizar comandos SQL para el mismo propósito:

SQL> STARTUP NOMOUNTORACLE instance started.Total System Global Area 188743680 bytesFixed Size 778036 bytesVariable Size 162537676 bytesDatabase Buffers 25165824 bytesRedo Buffers 262144 bytesSQL> ALTER DATABASE MOUNTDatabase altered.SQL> ALTER DATABASE OPEN

6


Manteniendo una Base de Datos Abierta

Una vez abierta, una base de datos falla por:• Pérdida de algun archivo de control• Pérdida de un datafile que pertenece al

tablespace system o undo• Pérdida de una entrada de un grupo de redo log.

Si al menos hay un miembro de cada grupodisponible, la instancia puede ser abierta.

Manteniendo una base de datos AbriertaDespués de abrir una instancia, algún problema en los medios podría producir la pérdida de archivo de control, miembro de un grupo de redolog o pérdida de un datafile perteneciente al tablespace SYSTEM o UNDO, esto podría causar una falla en la instancia.En muchos caso la falla de una instancia no permite realizar un shutdown normal, y no esposible continuar operando. La recuperación de cualquiera de esos tipos de falla de medios debeser hecha con la base de datos abajo, por lo tanto, el administrador debe ejecutar necesariamenteun comando SHUTDOWN ABORT antes de comenzar la recuperación.La pérdida de datafiles pertenecientes a otros tablespaces no causan una falla en la instancia y la base de datos puede ser recuperada mientras continua trabajando con los otros tablespaces.

7


Pérdida de un Archivo de Control

Si se pierde o corrompe un archivo de control:1. La instancia normalmente es abortada. Si esta

abierta, debe bajarse.2. Recuperar el archivo de control dañado

copiandolo de una copia válida existente.3. Levante la instancia.

Archivos de Control

Pérdida de una Archivo de ControlRecuperar un archivo de control perdido o dañado, implica las siguientes tareas:

1. Si la instancia aun no ha fallado, bájela usando SHUTDOWN ABORT2. Saue una copia del archivo de control y dejale en la localización donde se

encontraba el archivo perdido o dañado. Si la falla se ha producido por problemasdel controlador o disco físico, copie el archivo de control a otra localización y modifique el archivo de parámetros apuntando a la nueva localización. Alternativamente, se puede borrar el archivo de control dañado desde el archivode parámetros- Recuerde que Oracle sugiere tener al menos 2 archivos de control en uns instancia.

3. Subir la instancia.

8


Pérdida de un Archivo de Redo Log

Si un miembro de un grupo de redo log se pierde, mientras exista al menos 1 miembro en el grupo:

1. La operación normal de la instancia no se veráafectada.

2. Se recibira un mensaje de alerta en el archivo de alert log notificando al administrador que un miembro no puede ser encontrado.

3. Recuperar el archivo dañado copiandolo de unode los restantes del mismo grupo.

Pérdida de un Archivo de RedoLa recuperación de la pérdida de un solo miembro de un grupo de redo log no debe

afectar la operatividad de una instancia. 1. Determine cual es el archivo dañado examinando el archivo de alertas de Oracle.2. Recupere el archivo desde una copia de los restantes archivos pertenecientes al

mismo grupo.3. Si la falla fue producida por el controlado o disco físico, renombre el archivo

dañado.4. Si el grupo ya ha sido archivado o si la instancia esta en modo noarchivelog,

usted puede resolver el problema limpiando el grupo de log y recreando el o los archivos dañados. Seleccione el grupo apropiado y seleccione la acción Clear Logfile. Usted puede manualmente limpiar el grupo afectado con el siguientecomando SQL:

SQL> ALTER DATABASE CLEAR LOGFILE GROUP #;Nota: Database Control no permite limpiar grupos que no han sido archivados. Si usted

desea hacer una limpiada de un grupo no archivado, primeramente se requiere un respaldo full de la base de datos. De otro modo, esto puede generar una pérdida de datos si ocurre otra falla. Para limpiar un grupo de log no archivado use el siguientecomando SQL:

SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP #;

9


Si la base de datos esta en modo NOARCHIVELOG y algún datafile se pierde o daña:

Pérdida de un DataFile en modoNOARCHIVELOG

1. Bajar la instancia si aún no se ha hecho.2. Recupere las entradas de base de datos,

incluyendo todos los datos y archivos de control desde un respaldo.

3. Haga que los usuarios reingresen la informacióndesde el último backup.

User User UserUser User

Pérdida de un datafile en modo NOARCHIVELOGLa pérdida de cualquier datafile en una base de datos en modo NOARCHIVELOG requiere recuperar la base de datos completamente, incluyendo archivos de control y todos los archivos de datos.Con una base de datos en modo NOARCHIVELOG, la recuperación solo es posiblehasta el último backup disponible de la base de datos y los usuarios deberánreingresar todos los cambios ejecutados desde dicho respaldo y la fecha de la fallaproducida.

1. Bajat la instancia si no se ha hecho.2. Haga Click en Perform Recovery desde la página Maintenance del Enterprise

Manager. 3. Seleccione “Whole Database” como tipo de recuperación.

10


Pérdida de un Datafile No Critico en modoARCHIVELOG

Si se pierde un datafile o esta corrupto y el archivono pertenece al tablespace SYSTEM o UNDO, entoncesdespues de restaurar recupere el archivo de datafiledañado.

Usuarios

Pérdida de un datafile No Critico en Modo ARCHIVELOGCuando una base de datos esta en modo ARCHIVELOG, la pérdida de algún datafileque no pertenezca al tablespace SYSTEM o UNDO solo afecta a los objetos del archivo dañado. El resto de la base de datos esta disponible para que los usuariossigan trabajando. Para el archivo dañado que falta:

1. Haga Click en Perform Recovery de la página Maintenance.2. Seleccione “Datafiles” como tipo de recuperación y seleccione “Restore to current

time”.3. Agrege todos los datafiles necesarios a recuperar.4. Indique si desea recuperar los archivos en la ubicación por defecto o bien

determine la nueva localización.5. Suse RMAN para recuperar los archivos perdidos.

Cuando una base de datos esta en modo ARCHIVELOG, la recuperación será hasta el último commit ejecutado y los usuarios no necesitaran retipear o reingresar la información como en el caso anterior.

11


Pérdida de Datafile Criticos para el Sistema en modo ARCHIVELOG

Usuarios

Si se pierde o corrompe un datafile y pertenece a los tablespace SYSTEM o UNDO:1. La instancia puede o no bajarse automáticamente.

Sino lo hace, realice un SHUTDOWN ABORT.2. Monte la base de datos (subir en modo MOUNT).3. Restaurar y recuperar el o los archivos dañados.4. Abrir la base de datos (dejar en modo OPEN).

Pérdida de Datafile crítico para el Sistema en modo ARCHIVELOGLos datafiles pertenecientes a los tablespace SYSTEM o UNDO, son consideradoscríticos para el correcto funcionamiento del sistema. La pérdida de alguno de estosarchivos requieren que la base de datos sea colocada en modo MOUNT para la recuperación (a diferencia de otros archivos que pueden ser recuperados con la base de datos abierta (OPEN)).

1. Si la instancia aun no esta abajo, bajela.2. Montar la base de datos (subirla en estado MOUNT).3. Haga Click en Perform Recovery desde la página Maintenance.4. Seleccione “Datafiles” como tipo de recuperación y seleccione “Restore to current

time.”5. Agregar todos los datafiles necesarios a recuperarse.6. Determine si serán recuperados en la localización por defecto o en una nueva

ubicación.7. Suse RMAN para recuperar los archivos dañados. 8. Abrir la base de datos (dejar en modo OPEN). Los usuarios no necesitan

reingresar datos porque la recuperación se realiza hasta el último commit.

Abf leccion 19

Documents

Transcript of Abf leccion 19