U kunt een database herstellen vanaf de back-up en veel archieven toepassen om deze consistent te maken. Nu wilt u er zeker van zijn dat de geopende reset-logboeken goed werken.
Hier leest u hoe u kunt controleren of de database consistent is na onvolledig herstel
De onderstaande verklaring stelt de datumnotatie in op een uitgebreide vorm, omdat we dit vaak nodig zouden hebben in onze analyse
SQL> alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS' ;
Controle 1:
Doelstelling:Controleer of de databestanden zijn hersteld naar het beoogde tijdstip (PIT) en dat ze consistent zijn (FUZZY=NO)
Vraag de huidige status en PIT op (P-oint I-n T-time waartoe de databestanden zijn hersteld) van gegevensbestanden door de kopteksten van de gegevensbestanden rechtstreeks uit de fysieke gegevensbestanden te lezen:
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 ;
- Controleer of de checkpoint_time / checkpoint_change# in lijn is met uw beoogde TOT TIJD/SCN. Als dat niet het geval is, herstelt u de database verder als u meer gearchiveerde logbestanden beschikbaar heeft.
- Als FUZZY=YES voor sommige gegevensbestanden, betekent dit dat er meer herstel nodig is. Als er geen gearchiveerde logs meer beschikbaar zijn, identificeer dan dergelijke databestanden en bepaal of we ze offline kunnen halen omdat we de gegevens in die databestanden kwijtraken. Als de databestanden tot de SYSTEM of UNDO tablespace behoren, kunnen we / MOETEN we zo'n databestand niet offline halen zonder goede analyse. Raadpleeg Oracle Support voor verdere acties.
SQL> select file#, substr(name, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# from v$datafile_header where fuzzy='YES' ;
Soms, als de naam van de tabelruimte niet aangeeft dat het een UNDO-tabelruimte is en we zien een waarde die niet nul is in de kolom UNDO_OPT_CURRENT_CHANGE#, geeft dit aan dat het gegevensbestand ongedaanmakingssegmenten bevat.
Om een databestand offline te halen:
SQL> alter database datafile offline ;
Controle 1 kan als geslaagd worden beschouwd wanneer:
+ Geverifieerd dat alle databestanden zijn hersteld tot het beoogde tijdstip.
+ Fuzzy=NO voor SYSTEM, UNDO en alle beoogde databestanden. Voor databestanden met Fuzzy=YES, herstel ze verder of breng ze OFFLINE als er geen gearchiveerde logs meer beschikbaar zijn.
Controle 2:
Doelstelling:Controleer of de bestanden met status=RECOVER niet per ongeluk OFFLINE zijn
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
Als de bestanden de RECOVER-status hebben, controleer dan of ze OFFLINE zijn:
SQL> select file#, substr(name, 1, 50), status, error, recover from v$datafile_header ;
Als u wilt dat de gegevens voor deze bestanden toegankelijk zijn, breng ze dan ONLINE:
SQL> alter database datafile ONLINE ;
Als een bestand offline blijft op het moment van OPEN RESETLOGS, mag het databestand niet opnieuw online worden gebracht in dezelfde OPENED database.
Controle 2 kan als Geslaagd worden beschouwd wanneer:
a) Alle beoogde databestanden zijn niet OFFLINE
Controle 3:
Doelstelling:Extra Fuzzy-controle (Absolute Fuzzy-controle)
Af en toe is het mogelijk om Fuzzy=NO en hetzelfde checkpoint_change# te zien voor alle beoogde databestanden; toch kunnen sommige gegevensbestanden vaag zijn en OPEN RESETLOGS zal een fout retourneren, bijvoorbeeld
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 ;
Opmerking:Kolom Min_PIT_SCN retourneert dezelfde waarde, zelfs voor meerdere rijen, aangezien we de functie ANALYTICAL "MAX() OVER ()" erop hebben toegepast.
Bovenstaande zoekopdracht geeft aan dat het herstel minimaal TOT SCN 5311524 moet worden uitgevoerd om de gegevensbestanden consistent te maken en klaar om te OPENEN. Aangezien de checkpoint_change# kleiner is dan Min_PIT_SCN, zullen de databestanden om meer herstel vragen.
Controle 3 kan als geslaagd worden beschouwd wanneer,
a) Geen rijen geselecteerd uit bovenstaande zoekopdracht (d.w.z. Min_PIT_SCN is 0 (nul) voor alle gegevensbestanden)
b) Min_PIT_SCN minder wordt geretourneerd dan Checkpoint_Change#
Controle 4:Archieflogboeken vereist
Doorzoek het controlfile om het laatste archieflogboek te vinden dat nodig is voor herstel. Laten we zeggen dat de back-up voltooid is op 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;
Als de bovenstaande query geen rijen retourneert, kan het zijn dat de informatie uit het controlebestand is verouderd - voer de volgende query uit op 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.
Voor minimaal herstelgebruik:(Sequence# as return +1 )
RMAN> RUN
{
SET UNTIL SEQUENCE 531 THREAD 1;
RECOVER DATABASE;
}
Als dit een RAC-implementatie is, gebruik dan deze SQL om het controlebestand op te vragen:
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;
Gebruik voor minimaal herstel de logreeks en thread met de laagste NEXT_CHANGE# die is geretourneerd door de bovenstaande query.
Controle 4 kan als GESLAAGD worden beschouwd wanneer:
Alle archieflogboeken vanaf het moment van de back-up tot het einde van de back-up zijn beschikbaar voor gebruik tijdens herstel
Controleer 5 (na succesvolle OPEN RESETLOGS):
Houd alert.log in de gaten voor de tijd van OPEN RESETLOGS-activiteiten. Mogelijk ziet u enkele berichten zoals hieronder tijdens de woordenboekcontrole:
OFFLINE-bestand 'MISSING00004' maken in het controlebestand
als je het bestand vindt, probeer het dan te hernoemen. Zo niet, dan kunnen we het gegevensbestand offline zetten of de bijbehorende tabelruimte laten vallen:
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.
Ik hoop dat dit helpt om te controleren of de database consistent is na onvolledig herstel. Geef alsjeblieft de feedback
Leest ook
hoe het volgnummer van het archieflogboek in oracle te vinden
RMAN-back-upopdrachten
RMAN-lijst-back-upopdrachten
De database herstellen met RMAN