Puede restaurar una base de datos desde la copia de seguridad y aplicar muchos archivos para que sea consistente. Ahora, le gustaría asegurarse de que los registros de restablecimientos abiertos funcionen bien.
Aquí se explica cómo verificar que la base de datos sea consistente después de una recuperación incompleta
La declaración a continuación establece el formato de fecha en forma extendida, ya que lo requeriríamos muchas veces en nuestro análisis
SQL> alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS' ;
Marque 1:
Objetivo:Verificar que los archivos de datos se recuperen en el momento previsto (PIT) y que sean coherentes (FUZZY=NO)
Consultar el estado actual y el PIT (Punto en el tiempo hasta el cual se han recuperado los archivos de datos). recuperado) de archivos de datos leyendo los encabezados de los archivos de datos directamente desde los archivos de datos físicos:
SQL> select fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) from v$datafile_header group by fuzzy, status, error, recover, checkpoint_change#, checkpoint_time ;
- Verifique que checkpoint_time / checkpoint_change# coincida con su UNTIL TIME/SCN previsto. De lo contrario, recupere más la base de datos si tiene más registros archivados disponibles.
- Si FUZZY=YES para algunos archivos de datos, significa que se requiere más recuperación. Si no hay más registros archivados disponibles, identifique dichos archivos de datos y determine si podemos desconectarlos porque perderemos los datos en esos archivos de datos. Si los archivos de datos pertenecen al espacio de tabla SYSTEM o UNDO, podemos/no DEBEMOS desconectar dicho archivo de datos sin un análisis adecuado. Consulte con el soporte de Oracle para conocer más acciones.
SQL> select file#, substr(name, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# from v$datafile_header where fuzzy='YES' ;
Ocasionalmente, si el nombre del espacio de tabla no indica que sea un espacio de tabla DESHACER, si vemos un valor distinto de cero en la columna UNDO_OPT_CURRENT_CHANGE#, indica que el archivo de datos contiene segmentos de deshacer.
Para poner un archivo de datos fuera de línea:
SQL> alter database datafile offline ;
La comprobación 1 se puede considerar superada cuando:
+ Se verificó que todos los archivos de datos se han recuperado hasta el momento previsto.
+ Fuzzy=NO para SISTEMA, DESHACER y todos los archivos de datos previstos. Para los archivos de datos con Fuzzy=YES, recupérelos más o póngalos OFFLINE si no hay más registros archivados disponibles.
Marque 2:
Objetivo:Verificar que los archivos con status=RECOVER no estén OFFLINE sin querer
SQL> select status, enabled, count(*) from v$datafile group by status, enabled ; STATUS ENABLED COUNT(*) ------- ---------- ---------- SYSTEM DISABLED 1 ONLINE READ WRITE 1114 RECOVER DISABLED 2
Si los archivos están en estado RECUPERAR, verifique si están SIN CONEXIÓN:
SQL> select file#, substr(name, 1, 50), status, error, recover from v$datafile_header ;
Si desea que los datos de estos archivos sean accesibles, tráigalos EN LÍNEA:
SQL> alter database datafile ONLINE ;
Si un archivo permanece fuera de línea en el momento de ABRIR REINICIAR REGISTROS, es posible que el archivo de datos no vuelva a estar en línea en la misma base de datos ABIERTA.
La verificación 2 se puede considerar superada cuando:
a) Todos los archivos de datos previstos no DESCONECTADO
Marque 3:
Objetivo:Comprobación difusa adicional (Comprobación difusa absoluta)
Ocasionalmente, es posible ver Fuzzy=NO y el mismo checkpoint_change# para todos los archivos de datos previstos; aún algunos de los archivos de datos pueden ser confusos y OPEN RESETLOGS devolverá un error, por ejemplo,
SQL> select fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) from v$datafile_header group by fuzzy, status, error, recover, checkpoint_change#, checkpoint_time ; FUZ STATUS ERROR REC CHECKPOINT_CHANGE# CHECKPOINT_TIME COUNT(*) --- ------- --------------- --- ------------------ -------------------- ---------- NO ONLINE 5375858580 31-OCT-2011 23:10:14 7 SQL> ALTER DATABASE OPEN RESETLOGS ; ORA-01194: file 14 needs more recovery to be consistent ORA-01110: data file 3: '/u01/app/oracle/oradata/TEST/undotbs02.dbf' Hence, we should perform additional fuzzy check known as Absolute Fuzzy Check:
SQL> select hxfil file#, substr(hxfnm, 1, 50) name, fhscn checkpoint_change#, fhafs Absolute_Fuzzy_SCN, max(fhafs) over () Min_PIT_SCN from x$kcvfh where fhafs!=0 ;
Nota:la columna Min_PIT_SCN devolverá el mismo valor incluso para varias filas, ya que le hemos aplicado la función ANALÍTICA "MAX() SOBRE ()".
La consulta anterior indica que la recuperación debe realizarse al menos HASTA SCN 5311524 para que los archivos de datos sean consistentes y estén listos para ABRIR. Dado que checkpoint_change# es más pequeño que Min_PIT_SCN, los archivos de datos solicitarán más recuperación.
La comprobación 3 se puede considerar superada cuando,
a) No se han seleccionado filas de la consulta anterior (es decir, Min_PIT_SCN es 0 (cero) para todos los archivos de datos)
b) Min_PIT_SCN se devuelve menos que Checkpoint_Change#
Comprobación 4:Archivar registros obligatorios
Consulte el archivo de control para encontrar el archivo de registro más reciente necesario para la recuperación. Digamos que la copia de seguridad se completó el 31 de agosto de 2011 a las 23:20:14:
SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> SELECT THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG
WHERE '31-AUG-11 23:20:14' BETWEEN FIRST_TIME AND NEXT_TIME;
Si la consulta anterior no devuelve ninguna fila, es posible que la información haya caducado del archivo de control. Ejecute la siguiente consulta en v$log_history.
SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> select a.THREAD#, a.SEQUENCE#, a.FIRST_TIME
from V$LOG_HISTORY a
where FIRST_TIME =
( SELECT MAX(b.FIRST_TIME)
FROM V$LOG_HISTORY b
WHERE b.FIRST_TIME < to_date('31-AUG-11 23:20:14', 'DD-MON-RR HH24:MI:SS') ) ; SQL>
The sequence# returned by the above query is the log sequence current at the time the backup ended - let say 530 thread 1.
Para el uso mínimo de recuperación:(Sequence# como se devolvió +1)
RMAN> RUN
{
SET UNTIL SEQUENCE 531 THREAD 1;
RECOVER DATABASE;
}
Si se trata de una implementación de RAC, use este SQL en su lugar para consultar el archivo de control:
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG WHERE '31-AUG-11 23:20:14' BETWEEN FIRST_TIME AND NEXT_TIME;
Para una recuperación mínima, use la secuencia de registro y el subproceso que tenga el NEXT_CHANGE# más bajo devuelto por la consulta anterior.
La casilla 4 se puede considerar APROBADA cuando:
Todos los registros de archivo desde el momento de la copia de seguridad hasta el final de la copia de seguridad están disponibles para su uso durante la recuperación
Marque 5 (después de OPEN RESETLOGS exitoso):
Supervise alert.log para conocer el tiempo de las actividades de OPEN RESETLOGS. Es posible que vea algunos mensajes como los siguientes durante la verificación del diccionario:
Creando el archivo SIN CONEXIÓN 'MISSING00004' en el archivo de control
si encuentra el archivo, intente cambiarles el nombre. De lo contrario, podemos desconectar el archivo de datos o eliminar el espacio de tabla asociado:
SQL> select file#, status, enabled, substr(name, 1, 50) from v$datafile where name like '%MISSING%' ; FILE# STATUS ENABLED SUBSTR(NAME,1,50) -------- ------- ---------- -------------------------------------------------- 4 OFFLINE DISABLED /<path>/MISSING000 7 OFFLINE DISABLED /<path>/MISSING000 SQL> alter database datafile 4 online ; alter database datafile 4 online * ERROR at line 1: ORA-01157: cannot identify/lock data file 4 - see DBWR trace file ORA-01111: name for data file 4 is unknown - rename to correct file ORA-01110: data file 4: '/<oracle_home path>/dbs/MISSING00004' SQL> alter database rename file 'MISSING00004' to '/<path>/users01.dbf' ; Database altered. SQL> alter database rename file 'MISSING00007' to '/<path>/users02.dbf' ; Database altered. SQL> select tablespace_name, status from dba_tablespaces where tablespace_name in (select tablespace_name from dba_data_files where file_id in (4, 7)) ; TABLESPACE_NAME STATUS ------------------------------ --------- USERS OFFLINE SQL> ALTER TABLESPACE USERS ONLINE ; Tablespace altered.
Espero que esto ayude a verificar que la base de datos sea consistente después de una recuperación incompleta. Proporcione sus comentarios
También lee
cómo encontrar el número de secuencia de registro de archivo en Oracle
comandos de copia de seguridad de RMAN
comandos de copia de seguridad de lista de RMAN
cómo recuperar la base de datos mediante RMAN
