2. 2
Instituto Profesional DuocUC
Escuela de Ingeniería
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. 3
Instituto Profesional DuocUC
Escuela de Ingeniería
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
OPEN
STARTUP
Abriendo una Base de Datos
Mientras 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én
conocido como iniciada (STARTED)), la instancia debe leer información del
archivo de parámetros. No hay comprobación de los archivos de bases de datos
en 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 instancia
retornará 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. Cualquier
notificación de miembros inválidos sera notificado en el archivo de alertas de
la base de datos.
4. 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 siempre
que estos datafile sean los de los tablespaces SYSTEM o. Si algún archivo
está 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 encontrar
todos los archivos es necesaria una recuperación, el administrador puede
chequear la vista v$recover_file para obtener información completa de los
archivos que necesitan atención:
SQL> startup
ORACLE instance started.
Total System Global Area 171966464 bytes
Fixed Size 775608 bytes
Variable Size 145762888 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: '/oracle/oradata/orcl/users01.dbf'
SQL> SELECT name, error
2 FROM v$datafile
3 JOIN v$recover_file
4 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án
sincronizados 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 recovery
ORA-01110: data file 4: '/oracle/oradata/orcl/users01.dbf'
Nuevamente, v$recover_file entrega un completo informe de los archivos que
requieren atención. Los archivos que están presentes pero requieren
recuperarse son listados, pero no entregan un mensaje de error.
5. 5
Instituto Profesional DuocUC
Escuela de Ingeniería
Cambiando el Estado de la Instancia
Use Database Control para alterar el estado de la instancia:
Cambiando el Estado de la Instancia
Cuando se inicia la instancia, el modo por defecto de partida es OPEN. Usted puede
seleccionar 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 opciones
avanzadas de Startup permite seleccionar otros modos diferentes de OPEN para iniciar
la instancia y alterar el estado de una instancia que ya ha sido iniciada. También es
posible utilizar comandos SQL para el mismo propósito:
SQL> STARTUP NOMOUNT
ORACLE instance started.
Total System Global Area 188743680 bytes
Fixed Size 778036 bytes
Variable Size 162537676 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
SQL> ALTER DATABASE MOUNT
Database altered.
SQL> ALTER DATABASE OPEN
6. 6
Instituto Profesional DuocUC
Escuela de Ingeniería
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 grupo
disponible, la instancia puede ser abierta.
Manteniendo una base de datos Abrierta
Despué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 es
posible continuar operando. La recuperación de cualquiera de esos tipos de falla de medios debe
ser hecha con la base de datos abajo, por lo tanto, el administrador debe ejecutar necesariamente
un 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. 7
Instituto Profesional DuocUC
Escuela de Ingeniería
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 Control
Recuperar un archivo de control perdido o dañado, implica las siguientes tareas:
1. Si la instancia aun no ha fallado, bájela usando SHUTDOWN ABORT
2. 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 problemas
del 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 archivo
de parámetros- Recuerde que Oracle sugiere tener al menos 2 archivos de control
en uns instancia.
3. Subir la instancia.
8. 8
Instituto Profesional DuocUC
Escuela de Ingeniería
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 uno
de los restantes del mismo grupo.
Pérdida de un Archivo de Redo
La 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 siguiente
comando 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 siguiente
comando SQL:
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP #;
9. 9
Instituto Profesional DuocUC
Escuela de Ingeniería
Si la base de datos esta en modo NOARCHIVELOG y
algún datafile se pierde o daña:
Pérdida de un DataFile en modo
NOARCHIVELOG
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ón
desde el último backup.
User User UserUser User
Pérdida de un datafile en modo NOARCHIVELOG
La 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 posible
hasta el último backup disponible de la base de datos y los usuarios deberán
reingresar todos los cambios ejecutados desde dicho respaldo y la fecha de la falla
producida.
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. 10
Instituto Profesional DuocUC
Escuela de Ingeniería
Pérdida de un Datafile No Critico en modo
ARCHIVELOG
Si se pierde un datafile o esta corrupto y el archivo
no pertenece al tablespace SYSTEM o UNDO, entonces
despues de restaurar recupere el archivo de datafile
dañado.
Usuarios
Pérdida de un datafile No Critico en Modo ARCHIVELOG
Cuando una base de datos esta en modo ARCHIVELOG, la pérdida de algún datafile
que 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 usuarios
sigan 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. 11
Instituto Profesional DuocUC
Escuela de Ingeniería
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 ARCHIVELOG
Los datafiles pertenecientes a los tablespace SYSTEM o UNDO, son considerados
críticos para el correcto funcionamiento del sistema. La pérdida de alguno de estos
archivos 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.
