hvordan man kontrollerer, at databasen er konsistent efter ufuldstændig gendannelse

Du kan gendanne en database fra sikkerhedskopien og anvende masser af arkiv for at gøre den konsistent. Nu vil du gerne sikre dig, at åbne nulstillingslogfiler fungerer fint.
Sådan kontrollerer du, at databasen er konsistent efter ufuldstændig gendannelse

Nedenstående erklæring satte datoformatet til udvidet form, da vi ville kræve dette mange gange i vores analyse

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

Tjek 1:

Formål:Bekræft, at datafilerne er gendannet til det tilsigtede tidspunkt (PIT), og at de er konsistente (FUZZY=NO)
Forespørg på den aktuelle status og PIT (P-oint I-n T-tid, indtil datafilerne har været gendannet) af datafiler ved at læse datafilheadere direkte fra de fysiske datafiler:

SQL> vælg fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) fra v$datafile_header-gruppen efter fuzzy, status, error, recover, checkpoint_change#, checkpoint_time;

Bekræft, at checkpoint_time / checkpoint_change# er i overensstemmelse med din tilsigtede INDTIL TID/SCN. Hvis ikke, gendan databasen yderligere, hvis du har flere arkiverede logfiler til rådighed.
Hvis FUZZY=JA for nogle datafiler, betyder det, at der kræves mere gendannelse. Hvis der ikke er flere arkiverede logfiler tilgængelige, skal du identificere sådanne datafiler og afgøre, om vi kan tage dem offline, fordi vi mister dataene i disse datafiler. Hvis datafilerne tilhører SYSTEM eller UNDO tablespace, kan/MÅ vi ikke bringe en sådan datafil offline uden ordentlig analyse. Kontakt venligst Oracle Support for yderligere handlinger.

SQL> vælg file#, substr(name, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# fra v$datafile_header hvor fuzzy='YES';

Nogle gange, hvis tablespace-navnet ikke angiver, at det er FORTRYD tablespace, hvis vi ser en værdi, der ikke er nul i kolonne UNDO_OPT_CURRENT_CHANGE#, indikerer det, at datafilen indeholder fortryd-segmenter.

Sådan bringes en datafil offline:

SQL> ændre databasedatafil offline;

Kontrol 1 kan betragtes som bestået, når:
+ Verificeret, at alle datafiler er blevet gendannet til det tilsigtede tidspunkt.
+ Fuzzy=NEJ for SYSTEM, FORTRYD og alle tilsigtede datafiler. For datafiler med Fuzzy=YES skal du enten gendanne dem yderligere eller bringe dem OFFLINE, hvis ingen yderligere arkiverede logfiler er tilgængelige.

Tjek 2:

Formål:Bekræft, at filerne med status=RECOVER ikke er OFFLINE utilsigtet

SQL> vælg status, aktiveret, tæl(*) fra v$datafilgruppe efter status, aktiveret;STATUS  AKTIVERET      ANTAL(*)------- ---------- --- -------SYSTEM  DEAKTIVERET            1ONLINE  LÆS SKRIV          1114RECOVER DEAKTIVERET            2

Hvis filerne er i RECOVER-status, skal du kontrollere, om de er OFFLINE :

SQL> vælg fil#, substr(navn, 1, 50), status, fejl, gendan fra v$datafile_header;

Hvis du ønsker, at dataene for disse filer skal være tilgængelige, så bring dem ONLINE :

SQL> ændre databasedatafil ONLINE;

Hvis en fil forbliver offline på tidspunktet for OPEN RESETLOGS, kan datafilen muligvis ikke bringes online igen i den samme OPENED database.
Kontrol 2 kan anses for bestået, når:
a) Alle de tilsigtede datafiler er ikke OFFLINE

Tjek 3:

Formål:Yderligere Fuzzy check (Absolute Fuzzy check)

Nogle gange er det muligt at se Fuzzy=NO og samme checkpoint_change# for alle de tilsigtede datafiler; stadig nogle af datafilerne kan være uklare, og OPEN RESETLOGS vil returnere fejl, f.eks.

SQL> vælg fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) fra v$datafile_header-gruppen efter fuzzy, status, error, recover, checkpoint_change#, checkpoint_time;FUZ STATUS ERROR REC POINT _CHANGE (*)--- ------- --------------- --- ------------------ - ------------------- ----------NEJ ONLINE 5375858580 31-OCT-2011 23:10:14 7SQL> ELLER ÆNDRE DATALOG BASE OPEN; -01194:fil 14 har brug for mere gendannelse for at være konsistentORA-01110:datafil 3:'/u01/app/oracle/oradata/TEST/undotbs02.dbf'Derfor bør vi udføre yderligere fuzzy check kendt som Absolute Fuzzy Check:

SQL> vælg hxfil fil#, substr(hxfnm, 1, 50) navn, fhscn checkpoint_change#, fhafs Absolute_Fuzzy_SCN, max(fhafs) over () Min_PIT_SCN fra x$kcvfh hvor fhafs!=0;

Bemærk:Kolonne Min_PIT_SCN returnerer samme værdi selv for flere rækker, da vi har anvendt ANALYTISK "MAX() OVER ()"-funktion på den.

Ovenstående forespørgsel angiver, at gendannelsen skal udføres mindst INDTIL SCN 5311524 for at gøre datafiler konsistente og klar til at ÅBNE. Da checkpoint_change# er mindre end Min_PIT_SCN, vil datafilerne bede om mere gendannelse.

Kontrol 3 kan betragtes som bestået, når,
a) Ingen rækker valgt fra ovenstående forespørgsel (dvs. Min_PIT_SCN er 0 (nul) for alle datafilerne)
b) Min_PIT_SCN returneres mindre end Checkpoint_Change#

Tjek 4:Arkivlogfiler påkrævet

Forespørg kontrolfilen for at finde den seneste arkivlog, der kræves før gendannelse. Lad os sige, at sikkerhedskopieringen blev fuldført den 31-AUG-2011 23:20:14:

SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> VÆLG THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME FRA V$ARCHIVED_LOG
HVOR '31 -AUG-11 23:20:14' MELLEM FIRST_TIME OG NEXT_TIME;

Hvis ovenstående forespørgsel ikke returnerer nogen rækker, kan det være, at informationen er ældet ud af kontrolfilen – kør følgende forespørgsel mod v$log_history.

SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> vælg a.THREAD#, a.SEQUENCE#, a.FIRST_TIME
fra V$ LOG_HISTORY a
hvor FIRST_TIME =
( SELECT MAX(b.FIRST_TIME)
FRA V$LOG_HISTORY b
HVOR b.FIRST_TIME 
Sekvensnummeret, der returneres af ovenstående forespørgsel, er den aktuelle logsekvens på det tidspunkt, da sikkerhedskopieringen sluttede - lad os sige 530 tråd 1.

For minimum gendannelsesbrug:(Sekvens# som returneret +1 )

RMAN> KØR
{
INDSTIL SEKVENS 531 TRÅD 1;
GENDANN DATABASE;
}

Hvis dette er en RAC-implementering, skal du bruge denne SQL i stedet for at forespørge kontrolfilen:

SQL> VÆLG THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FRA V$ARCHIVED_LOG WHERE '31-AUG-11 23:20:14' MELLEM FIRST_TIME AND NEXT_TIME;

For minimal gendannelse skal du bruge logsekvensen og tråden, der har det laveste NEXT_CHANGE# returneret af ovenstående forespørgsel.

Kontrol 4 kan betragtes som bestået, når:

Alle arkivlogs fra tidspunktet for sikkerhedskopieringen til slutningen af sikkerhedskopien er tilgængelige til brug under gendannelse

Afkrydsningsfelt 5 (efter vellykket OPEN RESETLOGS):

Overvåg alert.log for tidspunktet for OPEN RESETLOGS aktiviteter. Du kan muligvis se nogle meddelelser som nedenfor under ordbogskontrol:

Oprettelse af OFFLINE-fil 'MISSING00004' i kontrolfilen

hvis du finder filen, så prøv at omdøbe dem. Hvis ikke, kan vi offline datafilen eller droppe tilhørende tablespace:

SQL> vælg filnummer, status, aktiveret, substr(navn, 1, 50) fra v$datafil, hvor navn som '%MISSING%';FILE#    STATUS  AKTIVERET    SUBSTR(NAME,1,50)---- ---- ------- ---------- ------------------------------------ ---------------------       4 OFFLINE DEAKTIVERET   //MISSING000       7 OFFLINE DEAKTIVERET   //MISSING000SQL> ændre databasedatafil 4 online;ændre databasedatafil 4 online*FEJL på linje 1:ORA-01157:kan ikke identificere/låse datafil 4 - se DBWR-sporingsfilORA-01111:navn på datafil 4 er ukendt - omdøb til korrekt filORA-01110:datafil 4:'//dbs/MISSING00004'SQL> ændre database omdøb fil 'MISSING00004' til '//users01.dbf';Database altered.SQL> ændre database omdøb filen 'MISSING00007' til '//users02.dbf';Database ændret.SQL> vælg tablespace_name, status fra dba_tablespaces hvor tablespace_name in (vælg tablespace_name fra dba_data_files hvor fil_id i (4, 7));TABLESPACE_NAME                 STATUS------------------ ---------- -- ---------BRUGERE                          OFFLINESQL> ÆNDRE TABELPLADSBRUGERE ONLINE;Tablespace ændret.

Håber dette hjælper med at kontrollere, at databasen er konsistent efter ufuldstændig gendannelse. Giv venligst feedback

Læser også
hvordan man finder arkivlogsekvensnummer i oracle
RMAN backup-kommandoer
RMAN-liste backup-kommandoer
Sådan gendannes databasen ved hjælp af RMAN