jak zkontrolovat, zda je databáze konzistentní po nedokončené obnově

Můžete obnovit databázi ze zálohy a použít velké množství archivu, aby byla konzistentní. Nyní byste se chtěli ujistit, že otevřené protokoly resetování proběhnou v pořádku.
Zde je návod, jak zkontrolovat, zda je databáze po neúplném obnovení konzistentní

Níže uvedené prohlášení nastavilo formát data na rozšířenou formu, jak bychom to v naší analýze vyžadovali mnohokrát

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

Kontrola 1:

Cíl:Ověřte, že datové soubory jsou obnoveny do zamýšleného časového bodu (PIT) a jsou konzistentní (FUZZY=NE)
Zeptejte se na aktuální stav a PIT (P-oint I-n T-ime, do kterého byly datové soubory uloženy obnoveno) datových souborů čtením záhlaví datových souborů přímo z fyzických datových souborů:

SQL> vyberte fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time, count(*) ze skupiny v$datafile_header podle fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time;

• Ověřte, že checkpoint_time / checkpoint_change# je v souladu s vaším zamýšleným DOKUMENTEM/SCN. Pokud ne, obnovte databázi dále, pokud máte k dispozici více archivovaných protokolů.
• Pokud u některých datových souborů FUZZY=ANO, znamená to, že je vyžadována další obnova. Pokud nejsou k dispozici žádné další archivované protokoly, identifikujte takové datové soubory a určete, zda je můžeme převést do režimu offline, protože o data v těchto datových souborech přijdeme. Pokud datové soubory patří do tabulkového prostoru SYSTEM nebo UNDO, nemůžeme / NESMÍME takový datový soubor převést do režimu offline bez řádné analýzy. Další akce vám poskytne podpora Oracle.

SQL> vyberte soubor#, substr(název, 1, 50), substr(název_tabulkového_prostoru, 1, 15), undo_opt_current_change# z v$datafile_header kde fuzzy='YES';

Občas, pokud název tabulkového prostoru neuvádí, že se jedná o tabulkový prostor UNDO, pokud ve sloupci UNDO_OPT_CURRENT_CHANGE# vidíme nenulovou hodnotu, znamená to, že datový soubor obsahuje segmenty zpět.

Převedení datového souboru do režimu offline:

SQL> změnit databázový soubor offline;

Kontrola 1 může být považována za splněnou, když:
+ Ověřeno, že všechny datové soubory byly obnoveny až do zamýšleného bodu v čase.
+ Fuzzy=NE pro SYSTEM, UNDO a všechny zamýšlené datové soubory. U datových souborů s Fuzzy=YES je buď dále obnovte, nebo je převeďte OFFLINE, pokud nejsou k dispozici žádné další archivované protokoly.

Kontrola 2:

Cíl:Ověřte, že soubory se status=RECOVER nejsou neúmyslně OFFLINE

SQL> select status, enabled, count(*) from v$datafile group by status, enabled;STATUS  ENABLED      COUNT(*)------- ---------- --- -------SYSTÉM  VYPNUTO            1ONLINE  ​​ČTĚTE ZÁPIS          1114OBNOVENÍ ZAKÁZÁNO            2

Pokud jsou soubory ve stavu RECOVER, ověřte, zda jsou OFFLINE :

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

Pokud chcete, aby data pro tyto soubory byla přístupná, přeneste je ONLINE :

SQL> změnit datový soubor databáze ONLINE;

Pokud soubor zůstane offline v době OPEN RESETLOGS, datový soubor nemusí být znovu uveden do stavu online ve stejné OPENED databázi.
Kontrolu 2 lze považovat za prošlou, když:
a) Všechny zamýšlené datové soubory jsou ne OFFLINE

Kontrola 3:

Cíl:Dodatečná kontrola fuzzy (Absolute fuzzy kontrola)

Občas je možné vidět Fuzzy=NO a stejný checkpoint_change# pro všechny zamýšlené datové soubory; stále mohou být některé datové soubory nejasné a OPEN RESETLOGS vrátí chybu, např.

SQL> select fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time, count(*) ze skupiny v$datafile_header podle fuzzy, status, error, recovery, checkpoint_change#, checkpoint_time;FUZ STATUS  ERROR           REC REC CHECKPOINT_CHANGE TIME  COUNT CHANGE # (*)--- ------- --------------- --- ------------------- ------------------- ----------NE ONLINE                                   5375858580 31. ŘÍJNA 2011 23:10 DATA SET ZNOVU DATA  ZNOVU  ZNOVU  ZÁB. -01194:soubor 14 potřebuje více obnovy, aby byl konzistentníORA-01110:datový soubor 3:'/u01/app/oracle/oradata/TEST/undotbs02.dbf'Proto bychom měli provést další fuzzy kontrolu známou jako Absolute Fuzzy Check: 
SQL> vyberte hxfil file#, substr(hxfnm, 1, 50) name, fhscn checkpoint_change#, fhafs Absolute_Fuzzy_SCN, max(fhafs) over () Min_PIT_SCN z x$kcvfh kde fhafs!=0;
 

 Poznámka:Sloupec Min_PIT_SCN vrátí stejnou hodnotu i pro více řádků, protože jsme na něj použili funkci ANALYTICAL „MAX() OVER ()“.
 

 Výše uvedený dotaz znamená, že obnova musí být provedena alespoň DO SCN 5311524, aby byly datové soubory konzistentní a připravené k OTEVŘENÍ. Vzhledem k tomu, že checkpoint_change# je menší než Min_PIT_SCN, budou datové soubory vyžadovat další obnovení.
 

 Kontrolu 3 lze považovat za splněnou, když
a) Z výše uvedeného dotazu nejsou vybrány žádné řádky (tj. Min_PIT_SCN je 0 (nula) pro všechny datové soubory)
b) Min_PIT_SCN je vráceno méně než Checkpoint_Change#
 

 Kontrola 4:Je vyžadována archivace protokolů 
 

 Dotazem na kontrolní soubor najděte nejnovější archivní protokol požadovaný pro obnovení. Řekněme, že záloha byla dokončena 31. srpna 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' MEZI FIRST_TIME A NEXT_TIME;
 

 Pokud výše uvedený dotaz nevrací žádné řádky, je možné, že informace z kontrolního souboru zastaraly – spusťte následující dotaz proti v$log_history.
 
SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> vyberte a.THREAD#, a.SEQUENCE#, a.FIRST_TIME
z V$ LOG_HISTORY a
kde FIRST_TIME =
( SELECT MAX(b.FIRST_TIME)
FROM V$LOG_HISTORY b
WHERE b.FIRST_TIME 
Sekvence# vrácená výše uvedeným dotazem je sekvence protokolu aktuální v době ukončení zálohování – řekněme 530 vlákno 1.
 

 Pro minimální použití obnovy:(Sequence# jako vrácené +1)
 
RMAN> SPUSTIT
{
NASTAVIT DO SEKVENCE 531 VLÁKNO 1;
OBNOVIT DATABÁZI;
}
 

 Pokud se jedná o implementaci RAC, použijte místo toho tento SQL k dotazu na kontrolní soubor:
 
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# Z V$ARCHIVED_LOG WHERE '31-AUG-11 23:20:14' BETWEEN FIRST_TIME AND NEXT_TIME;
 

 Pro minimální obnovu použijte sekvenci protokolu a vlákno, které má nejnižší NEXT_CHANGE# vrácené výše uvedeným dotazem.
 

 Kontrola 4 může být považována za VYHOVĚNO, když:
 

 Všechny archivní protokoly od okamžiku zálohování do konce zálohy jsou k dispozici pro použití během obnovy
 

 Kontrola 5 (po úspěšném OPEN RESETLOGS) : 
 

 Sledujte záznam alert.log po dobu aktivit OPEN RESETLOGS. Během kontroly slovníku se mohou zobrazit některé zprávy jako níže:
 

 Vytváření OFFLINE souboru „MISSING00004“ v kontrolním souboru
 

 pokud soubor najdete, zkuste je přejmenovat. Pokud ne, můžeme datový soubor offline nebo zrušit související tabulkový prostor:
 
SQL> vyberte soubor#, stav, povoleno, substr(název, 1, 50) z v$datafile, kde název jako '%MISSING%';FILE#    STAV  POVOLENO    SUBSTR(NAME,1,50)---- ---- ------- ---------- ----------------------------- ---------------------       4 OFFLINE ZAKÁZÁNO   //CHYBÍ000       7 OFFLINE ZAKÁZÁNO   //MISSING000SQL> změnit databázový soubor 4 online;změnit datový soubor databáze 4 online*ERROR na řádku 1:ORA-01157:nelze identifikovat/zamknout datový soubor 4 – viz DBWR trasovací souborORA-01111:název datového souboru 4 je neznámý – přejmenujte na správný souborORA-01110:datový soubor 4:'//dbs/MISSING00004'SQL> změnit soubor přejmenování databáze 'MISSING00004' na '//users01.dbf';Database altered.SQL> změnit soubor přejmenování databáze 'MISSING00007' na '//users02.dbf';Database altered.SQL> vyberte název_tabulkového_prostoru, stav z dba_tabulkových_prostorů, kde je název_tabulkového_prostoru (vyberte název_tabulkového_prostoru z dba_data_files, kde id_souboru v (4, 7));NÁZEV_TABLE_SPACE                 STAV--------------- ---------- -- ---------USERS                           OFFLINESQL> ZMĚNIT UŽIVATELE TABLESPACE ONLINE;Tablespace změněn.
 

 Doufám, že to pomůže při kontrole, zda je databáze konzistentní po neúplném obnovení. Uveďte prosím zpětnou vazbu 
 

 Také čte 
Jak najít pořadové číslo archivního protokolu v oracle
Příkazy pro zálohování RMAN
Příkazy pro zálohování seznamu RMAN
Jak obnovit databázi pomocí RMAN