sql >> Database >  >> RDS >> Oracle

hoe te controleren of de database consistent is na onvolledig herstel

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


  1. Hoe kan ik een primaire sleutelbeperking wijzigen met behulp van de SQL-syntaxis?

  2. Kan niet inloggen op database als SYS met Oracle SQL Developer

  3. Een inleiding tot datamining

  4. Afdrukken naar scherm in .sql-bestand postgres