hur man kontrollerar att databasen är konsekvent efter ofullständig återställning

Du kan återställa en databas från säkerhetskopian och använda massor av arkiv för att göra den konsekvent. Nu vill du se till att öppna återställningsloggar fungerar bra.
Så här kontrollerar du att databasen är konsekvent efter ofullständig återställning

Nedanstående uttalande satte datumformatet till utökat format eftersom vi skulle kräva detta många gånger i vår analys

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

Kock 1:

Syfte:Verifiera att datafilerna återställs till den avsedda tidpunkten (PIT) och att de är konsekventa (FUZZY=NO)
Fråga aktuell status och PIT (P-oint I-n T-tid fram till vilken datafilerna har varit återställd) av datafiler genom att läsa datafilhuvuden direkt från de fysiska datafilerna:

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

Verifiera att checkpoint_time / checkpoint_change# är i linje med din avsedda TILL TID/SCN. Om inte, återställ databasen ytterligare om du har fler arkiverade loggar tillgängliga.
Om FUZZY=JA för vissa datafiler betyder det att mer återställning krävs. Om inga fler arkiverade loggar är tillgängliga, identifiera sådana datafiler och avgöra om vi kan ta dem offline eftersom vi kommer att förlora data i dessa datafiler. Om datafilerna tillhör SYSTEM- eller UNDO-tabellutrymmet kan/FÅR vi inte föra sådan datafil offline utan ordentlig analys. Kontakta Oracle Support för ytterligare åtgärder.

SQL> välj fil#, substr(namn, 1, 50), substr(tabellutrymmesnamn, 1, 15), undo_opt_current_change# från v$datafile_header där fuzzy='YES';

Ibland, om tabellutrymmets namn inte indikerar att det är UNDO tabellutrymme, om vi ser ett värde som inte är noll i kolumnen UNDO_OPT_CURRENT_CHANGE#, indikerar det att datafilen innehåller ångra segment.

För att få en datafil offline:

SQL> ändra databasdatafil offline;

Kontroll 1 kan anses godkänd när:
+ Verifierat att alla datafiler har återställts till den avsedda tidpunkten.
+ Fuzzy=NO för SYSTEM, UNDO och alla avsedda datafiler. För datafiler med Fuzzy=YES, antingen återställ dem ytterligare eller ta dem OFFLINE om inga ytterligare arkiverade loggar är tillgängliga.

Kock 2:

Mål:Verifiera att filerna med status=RECOVER inte är OFFLINE oavsiktligt

SQL> välj status, aktiverad, count(*) från v$datafile-grupp efter status, aktiverad;STATUS  ENABLED      COUNT(*)------- ---------- --- -------SYSTEM  INAKTIVERAD            1ONLINE  LÄS SKRIV          1114RECOVER DISABLED            2

Om filerna är i RECOVER-status, kontrollera om de är OFFLINE :

SQL> välj fil#, substr(namn, 1, 50), status, fel, återställ från v$datafile_header;

Om du vill att data för dessa filer ska vara tillgängliga, lägg dem sedan ONLINE :

SQL> ändra databasdatafil ONLINE;

Om en fil förblir offline vid tidpunkten för OPEN RESETLOGS, kan datafilen inte återföras online igen i samma OPENED databas.
Kock 2 kan anses godkänd när:
a) Alla avsedda datafiler är inte OFFLINE

Kock 3:

Mål:Ytterligare fuzzy check (Absolute fuzzy check)

Ibland är det möjligt att se Fuzzy=NO och samma checkpoint_change# för alla avsedda datafiler; fortfarande kan vissa av datafilerna vara otydliga och OPEN RESETLOGS kommer att returnera fel, t.ex.

SQL> välj 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 FEL REC POINT _CHANGE REC CHECKPOINT _CHANGE (*)--- ------- --------------- --- ------------------ - ------------------- ----------NO ONLINE 5375858580 31-OKT-2011 23:10:14 7SQL> ÄNDRA DATALOGG BAS ÖPPEN; -01194:fil 14 behöver mer återställning för att vara konsekvent. före>

SQL> välj hxfil fil#, substr(hxfnm, 1, 50) namn, fhscn checkpoint_change#, fhafs Absolute_Fuzzy_SCN, max(fhafs) över () Min_PIT_SCN från x$kcvfh där fhafs!=0;

Obs! Kolumnen Min_PIT_SCN kommer att returnera samma värde även för flera rader eftersom vi har tillämpat ANALYTISKA "MAX() OVER ()"-funktionen på den.

Ovanstående fråga indikerar att återställningen måste utföras minst TILL SCN 5311524 för att göra datafiler konsekventa och redo att ÖPPAS. Eftersom checkpoint_change# är mindre än Min_PIT_SCN kommer datafilerna att begära mer återställning.

Kontroll 3 kan anses godkänd när,
a) Inga rader valda från ovanstående fråga (dvs. Min_PIT_SCN är 0 (Noll) för alla datafiler)
b) Min_PIT_SCN returneras mindre än Checkpoint_Change#

Kontroll 4:Arkivloggar krävs

Fråga kontrollfilen för att hitta den senaste arkivloggen som krävs för återställning. Låt säga att säkerhetskopieringen slutfördes den 31-AUG-2011 23:20:14:

SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> VÄLJ THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME FRÅN V$ARCHIVED_LOG
WHERE '31 -AUG-11 23:20:14' MELLAN FIRST_TIME OCH NEXT_TIME;

Om ovanstående fråga inte returnerar några rader kan det vara så att informationen har åldrats ur kontrollfilen – kör följande fråga mot v$log_history.

SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> välj a.THREAD#, a.SEQUENCE#, a.FIRST_TIME
från V$ LOG_HISTORY a
där FIRST_TIME =
( VÄLJ MAX(b.FIRST_TIME)
FRÅN V$LOG_HISTORY b
WHERE b.FIRST_TIME 
Sekvensnummeret som returneras av ovanstående fråga är loggsekvensen som var aktuell vid den tidpunkt då säkerhetskopieringen avslutades - låt säga 530 tråd 1.

För minimal återställningsanvändning:(Sekvensnummer som returneras +1 )

RMAN> KÖR
{
STÄLL IN TILL SEKVENS 531 TRÄD 1;
ÅTERSTÄLL DATABAS;
}

Om detta är en RAC-implementering använd denna SQL istället för att fråga kontrollfilen:

SQL> VÄLJ THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FRÅN V$ARCHIVED_LOG WHERE '31-AUG-11 23:20:14' MELLAN FIRST_TIME AND NEXT_TIME;

För minsta möjliga återställning använd loggsekvensen och tråden som har det lägsta NEXT_CHANGE# som returneras av ovanstående fråga.

Kontroll 4 kan anses vara godkänd när:

Alla arkivloggar från tidpunkten för säkerhetskopieringen till slutet av säkerhetskopieringen är tillgängliga för användning under återställning

Kontrollera 5 (efter lyckad OPEN RESETLOGS) :

Övervaka alert.log för tiden för OPEN RESETLOGS-aktiviteter. Du kan se några meddelanden som nedan under ordbokskontroll:

Skapar OFFLINE-filen 'MISSING00004' i kontrollfilen

om du hittar filen, försök att byta namn på dem. Om inte, kan vi offline datafilen eller släppa tillhörande tabellutrymme:

SQL> välj fil#, status, aktiverad, substr(namn, 1, 50) från v$datafil där namn som '%MISSING%';FILE#    STATUS  ENABLED    SUBSTR(NAME,1,50)---- ---- ------- ---------- ------------------------------------ ---------------------       4 OFFLINE INAKTIVERAD   //MISSING000       7 OFFLINE INAKTIVERAD   //MISSING000SQL> ändra databasdatafil 4 online;ändra databasdatafil 4 online*FEL på rad 1:ORA-01157:kan inte identifiera/låsa datafil 4 - se DBWR-spårningsfilORA-01111:namn på datafil 4 är okänt - byt namn till rätt filORA-01110:datafil 4:'//dbs/MISSING00004'SQL> ändra databasens namn på filen 'MISSING00004' till '//users01.dbf';Databasen ändrad.SQL> ändra databasens namn på filen 'MISSING00007' till '//users02.dbf';Databas ändrad.SQL> välj tabellutrymmesnamn, status från dba_tabellutrymmen där tabellutrymmesnamn in (välj tabellutrymmesnamn från dba_data_filer där fil_id i (4, 7));TABELLSPACE_NAME                 STATUS------------------ ---------- -- ----------ANVÄNDARE                          OFFLINESQL> ÄNDRA ANVÄNDARE I BORDSPLATS ONLINE;Tablespace har ändrats.

Hoppas detta hjälper till att kontrollera att databasen är konsekvent efter ofullständig återställning. Lämna gärna feedbacken

Läser också
hur man hittar sekvensnummer för arkivlogg i oracle
RMAN backup-kommandon
RMAN list backup-kommandon
Hur man återställer databasen med RMAN