È possibile ripristinare un database dal backup e applicare molti archivi per renderlo coerente. Ora vorresti assicurarti che i log di ripristino aperti vadano bene.
Ecco come verificare che il database sia coerente dopo un ripristino incompleto
La seguente dichiarazione imposta il formato della data in formato esteso poiché lo avremmo richiesto molte volte nella nostra analisi
SQL> alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS' ;
Verifica 1:
Obiettivo:verificare che i file di dati siano stati ripristinati al punto temporale previsto (PIT) e che siano coerenti (FUZZY=NO)
Richiedere lo stato corrente e il PIT (P-oint I-n T-ime fino a cui i file di dati sono stati recuperato) dei file di dati leggendo le intestazioni dei file di dati direttamente dai file di dati fisici:
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 ;
- Verifica che il checkpoint_time / checkpoint_change# sia in linea con il tuo previsto UNTIL TIME/SCN. In caso contrario, ripristinare ulteriormente il database se sono disponibili più registri archiviati.
- Se FUZZY=YES per alcuni file di dati, significa che è necessario un ulteriore recupero. Se non sono disponibili altri registri archiviati, identificare tali file di dati e determinare se possiamo portarli offline perché perderemo i dati in quei file di dati. Se i file di dati appartengono al tablespace SYSTEM o UNDO, non possiamo/Dobbiamo portare tale file di dati offline senza un'analisi adeguata. Consulta il supporto Oracle per ulteriori azioni.
SQL> select file#, substr(name, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# from v$datafile_header where fuzzy='YES' ;
Occasionalmente, se il nome del tablespace non indica che è un tablespace UNDO, se vediamo un valore diverso da zero nella colonna UNDO_OPT_CURRENT_CHANGE#, indica che il file di dati contiene segmenti di annullamento.
Per portare offline un file di dati:
SQL> alter database datafile offline ;
Il controllo 1 può essere considerato superato quando:
+ Verificato che tutti i file di dati sono stati recuperati fino al momento previsto.
+ Fuzzy=NO per SYSTEM, UNDO e tutti i file di dati previsti. Per i file di dati con Fuzzy=YES, recuperali ulteriormente o portali OFFLINE se non sono disponibili altri registri archiviati.
Verifica 2:
Obiettivo:verificare che i file con status=RECOVER non siano OFFLINE involontariamente
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
Se i file sono nello stato RECOVER, verifica se sono OFFLINE :
SQL> select file#, substr(name, 1, 50), status, error, recover from v$datafile_header ;
Se vuoi che i dati di questi file siano accessibili, portali ONLINE :
SQL> alter database datafile ONLINE ;
Se un file rimane offline al momento di OPEN RESETLOGS, il file di dati potrebbe non essere riportato di nuovo online nello stesso database APERTO.
Il controllo 2 può essere considerato superato quando:
a) Tutti i file di dati previsti sono non OFFLINE
Verifica 3:
Obiettivo:controllo Fuzzy aggiuntivo (controllo Fuzzy assoluto)
Occasionalmente, è possibile vedere Fuzzy=NO e lo stesso checkpoint_change# per tutti i file di dati previsti; tuttavia alcuni dei file di dati potrebbero essere sfocati e OPEN RESETLOGS restituirà un errore, ad es.
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 colonna Min_PIT_SCN restituirà lo stesso valore anche per più righe poiché abbiamo applicato la funzione ANALYTICAL "MAX() OVER ()".
La query sopra indica che il ripristino deve essere eseguito almeno FINO A SCN 5311524 per rendere i file di dati coerenti e pronti per l'APERTURA. Poiché il checkpoint_change# è più piccolo di Min_PIT_SCN, i file di dati richiederanno un ulteriore recupero.
Il controllo 3 può essere considerato superato quando,
a) Nessuna riga selezionata dalla query precedente (ovvero Min_PIT_SCN è 0 (Zero) per tutti i file di dati)
b) Min_PIT_SCN viene restituito inferiore a Checkpoint_Change#
Controllo 4:Archivia i registri obbligatori
Interrogare il file di controllo per trovare l'ultimo log di archivio richiesto per il ripristino. Diciamo che il backup è stato completato il 31-AUG-2011 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;
Se la query precedente non restituisce alcuna riga, è possibile che le informazioni siano invecchiate fuori dal file di controllo:esegui la query seguente su 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.
Per un utilizzo minimo di recupero:(Sequence# come restituito +1 )
RMAN> RUN
{
SET UNTIL SEQUENCE 531 THREAD 1;
RECOVER DATABASE;
}
Se si tratta di un'implementazione RAC, utilizzare questo SQL invece per interrogare il file di controllo:
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;
Per il ripristino minimo, utilizza la sequenza di log e il thread con il NEXT_CHANGE# più basso restituito dalla query precedente.
Il controllo 4 può essere considerato PASSATO quando:
Tutti i log di archivio dal momento del backup alla fine del backup sono disponibili per l'uso durante il ripristino
Seleziona 5 (dopo APRIRE RESETLOGS) :
Monitorare alert.log per il tempo delle attività OPEN RESETLOGS. Potresti visualizzare alcuni messaggi come quelli di seguito durante il controllo del dizionario:
Creazione del file OFFLINE 'MISSING00004' nel file di controllo
se trovi il file, prova a rinominarlo. In caso contrario, possiamo offline il file di dati o eliminare il tablespace associato:
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.
Spero che questo aiuti su come verificare che il database sia coerente dopo un ripristino incompleto. Si prega di fornire il feedback
Legge anche
come trovare il numero di sequenza del registro di archivio in Oracle
Comandi di backup RMAN
Comandi di backup dell'elenco RMAN
Come ripristinare il database utilizzando RMAN
