So überprüfen Sie, ob die Datenbank nach einer unvollständigen Wiederherstellung konsistent ist

Sie können eine Datenbank aus der Sicherung wiederherstellen und viele Archive anwenden, um sie konsistent zu machen. Jetzt möchten Sie sicherstellen, dass die Protokolle zum Öffnen von Zurücksetzungen einwandfrei funktionieren.
So prüfen Sie, ob die Datenbank nach einer unvollständigen Wiederherstellung konsistent ist

Die folgende Anweisung setzt das Datumsformat auf erweiterte Form, da wir dies oft in unserer Analyse benötigen würden

SQL> alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS';

Überprüfen Sie 1:

Ziel:Verifizieren, dass die Datendateien zum beabsichtigten Zeitpunkt (PIT) wiederhergestellt wurden und konsistent sind (FUZZY=NO) wiederhergestellt) von Datendateien, indem Datendatei-Header direkt aus den physischen Datendateien gelesen werden:

SQL> select fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time, count(*) from v$datafile_header group by fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time;

Vergewissern Sie sich, dass checkpoint_time / checkpoint_change# mit Ihrer beabsichtigten UNTIL TIME/SCN übereinstimmt. Wenn nicht, stellen Sie die Datenbank weiter wieder her, wenn Sie mehr archivierte Protokolle zur Verfügung haben.
Wenn für einige Datendateien FUZZY=YES ist, bedeutet dies, dass mehr Wiederherstellung erforderlich ist. Wenn keine archivierten Protokolle mehr verfügbar sind, identifizieren Sie solche Datendateien und entscheiden Sie, ob wir sie offline nehmen können, da wir die Daten in diesen Datendateien verlieren würden. Wenn die Datendateien zum SYSTEM- oder UNDO-Tablespace gehören, können / MÜSSEN wir solche Datendateien nicht ohne ordnungsgemäße Analyse offline schalten. Bitte wenden Sie sich für weitere Maßnahmen an den Oracle-Support.

SQL> select file#, substr(name, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# from v$datafile_header where fuzzy='YES';

Gelegentlich, wenn der Tablespace-Name nicht darauf hinweist, dass es sich um einen UNDO-Tablespace handelt, wenn in der Spalte UNDO_OPT_CURRENT_CHANGE# ein Wert ungleich Null angezeigt wird, weist dies darauf hin, dass die Datendatei Undo-Segmente enthält.

Um eine Datendatei offline zu schalten:

SQL> Datenbankdatendatei offline ändern;

Prüfung 1 kann als bestanden angesehen werden, wenn:
+ bestätigt wurde, dass alle Datendateien bis zum beabsichtigten Zeitpunkt wiederhergestellt wurden.
+ Fuzzy=NEIN für SYSTEM, UNDO und alle beabsichtigten Datendateien. Stellen Sie Datendateien mit Fuzzy=YES entweder weiter wieder her oder bringen Sie sie OFFLINE, wenn keine weiteren archivierten Protokolle verfügbar sind.

Prüfung 2:

Ziel:Sicherstellen, dass die Dateien mit status=RECOVER nicht versehentlich OFFLINE sind

SQL> select status, enabled, count(*) from v$datafile group by status, enabled;STATUS  ENABLED      COUNT(*)------- ---------- --- -------SYSTEM  DEAKTIVIERT            1ONLINE  LESEN SCHREIBEN          1114WIEDERHERSTELLUNG DEAKTIVIERT            2

Wenn sich die Dateien im WIEDERHERSTELLEN-Status befinden, überprüfen Sie, ob sie OFFLINE sind:

SQL> select file#, substr(name, 1, 50), status, error, recovery from v$datafile_header;

Wenn Sie möchten, dass die Daten für diese Dateien zugänglich sind, dann bringen Sie sie ONLINE :

SQL> Datenbankdatei ONLINE ändern;

Wenn eine Datei zum Zeitpunkt von OPEN RESETLOGS offline bleibt, darf die Datendatei nicht wieder in derselben OPENED-Datenbank wieder online gebracht werden.
Prüfung 2 kann als bestanden betrachtet werden, wenn:
a) Alle beabsichtigten Datendateien sind nicht OFFLINE

Überprüfen Sie 3:

Ziel:Zusätzliche Fuzzy-Prüfung (Absolute Fuzzy-Prüfung)

Gelegentlich ist es möglich, Fuzzy=NO und gleiche checkpoint_change# für alle beabsichtigten Datendateien zu sehen; Dennoch könnten einige der Datendateien unscharf sein und OPEN RESETLOGS wird einen Fehler zurückgeben, z. B.

SQL> select fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time, count(*) from v$datafile_header group by fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time;FUZ STATUS ERROR REC CHECKPOINT_CHANGE# CHECKPOINT_TIME COUNT (*)--- ------- --------------- --- ------------------ - ------------------- ----------NO ONLINE 5375858580 31-OCT-2011 23:10:14 7SQL> ALTER DATABASE OPEN RESETLOGS;ORA -01194:Datei 14 benötigt mehr Wiederherstellung, um konsistent zu seinORA-01110:Datendatei 3:'/u01/app/oracle/oradata/TEST/undotbs02.dbf'Daher sollten wir eine zusätzliche Fuzzy-Prüfung durchführen, die als absolute Fuzzy-Prüfung bekannt ist:

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;

Hinweis:Die Spalte Min_PIT_SCN gibt den gleichen Wert zurück, auch für mehrere Zeilen, da wir die Funktion ANALYTICAL „MAX() OVER ()“ darauf angewendet haben.

Die obige Abfrage zeigt an, dass die Wiederherstellung mindestens BIS SCN 5311524 durchgeführt werden muss, damit die Datendateien konsistent und zum ÖFFNEN bereit sind. Da checkpoint_change# kleiner als Min_PIT_SCN ist, werden die Datendateien nach mehr Wiederherstellung fragen.

Prüfung 3 kann als bestanden angesehen werden, wenn
a) keine Zeilen aus der obigen Abfrage ausgewählt wurden (d. h. Min_PIT_SCN ist 0 (Null) für alle Datendateien)
b) Min_PIT_SCN kleiner als Checkpoint_Change#

zurückgegeben wird

Prüfung 4:Protokolle archivieren erforderlich

Fragen Sie die Steuerdatei ab, um das neueste für die Wiederherstellung erforderliche Archivprotokoll zu finden. Nehmen wir an, die Sicherung wurde am 31. August 2011 um 23:20:14 Uhr abgeschlossen:

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' ZWISCHEN FIRST_TIME UND NEXT_TIME;

Wenn die obige Abfrage keine Zeilen zurückgibt, kann es sein, dass die Informationen aus der Steuerdatei veraltet sind – führen Sie die folgende Abfrage gegen v$log_history.

aus

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 
Die von der obigen Abfrage zurückgegebene Sequenznummer ist die Protokollsequenz, die zum Zeitpunkt des Endes der Sicherung aktuell war – sagen wir 530 Thread 1.

Verwenden Sie für eine minimale Wiederherstellung:(Sequence# wie zurückgegeben +1 )

RMAN> RUN
{
SET BIS SEQUENCE 531 THREAD 1;
DATENBANK WIEDERHERSTELLEN;
}

Wenn dies eine RAC-Implementierung ist, verwenden Sie stattdessen diese SQL, um die Steuerdatei abzufragen:

SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG WHERE '31-AUG-11 23:20:14' ZWISCHEN FIRST_TIME UND NEXT_TIME;

Verwenden Sie für eine minimale Wiederherstellung die Protokollsequenz und den Thread mit der niedrigsten NEXT_CHANGE#, die von der obigen Abfrage zurückgegeben wird.

Prüfung 4 kann als BESTANDEN angesehen werden, wenn:

Alle Archivprotokolle vom Zeitpunkt der Sicherung bis zum Ende der Sicherung stehen zur Verwendung während der Wiederherstellung zur Verfügung

Check 5 (Nach erfolgreichem OPEN RESETLOGS) :

Überwachen Sie das alert.log für die Zeit der OPEN RESETLOGS-Aktivitäten. Während der Wörterbuchprüfung werden möglicherweise Nachrichten wie die folgenden angezeigt:

Erstellen der OFFLINE-Datei „MISSING00004“ in der Steuerdatei

Wenn Sie die Datei finden, versuchen Sie, sie umzubenennen. Wenn nicht, können wir die Datendatei offline schalten oder den zugehörigen Tablespace löschen:

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 DEAKTIVIERT   //MISSING000       7 OFFLINE DEAKTIVIERT   //MISSING000SQL> Datenbankdatendatei 4 online ändern; Datenbankdatendatei 4 ändern online*FEHLER in Zeile 1:ORA-01157:Datendatei 4 kann nicht identifiziert/gesperrt werden - siehe DBWR-Trace-DateiORA-01111:Name für Datendatei 4 ist unbekannt - in korrekte Datei umbenennenORA-01110:Datendatei 4:'//dbs/MISSING00004'SQL> ändern Sie die Datenbankumbenennungsdatei 'MISSING00004' in '//users01.dbf';Datenbank geändert.SQL> ändern Sie die Datenbankumbenennungsdatei 'MISSING00007' in '//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                          OFFLINESQL> ALTER TABLESPACE USERS ONLINE;Tablespace geändert.

Ich hoffe, dies hilft bei der Überprüfung, ob die Datenbank nach einer unvollständigen Wiederherstellung konsistent ist. Bitte geben Sie Feedback

Liest auch
So finden Sie die Sequenznummer des Archivprotokolls in Oracle
RMAN-Sicherungsbefehle
RMAN-Listensicherungsbefehle
So stellen Sie die Datenbank mit RMAN wieder her