sql >> Databáze >  >> RDS >> Oracle

ORA-38868

Když jsem nedávno pracoval na záložní databázi, šel jsem do DG Broker zkontrolovat stav a obdržel jsem toto:

DGMGRL> show configuration
 
Configuration - resp_ress_config
 
Protection Mode: MaxPerformance
Databases:
resp - Primary database
ress - Physical standby database
Error: ORA-16766: Redo Apply is stopped

Hmm...můj pohotovostní režim se neaplikuje znovu. Když jsem se pokusil spustit spravovanou obnovu, v pohotovostním protokolu výstrah se zobrazilo následující:

Tue Dec 31 09:52:10 2013
Managed Standby Recovery starting Real Time Apply
Tue Dec 31 09:52:10 2013
MRP0: Background Media Recovery terminated with error 38868
Errors in file /u01/app/oracle/diag/rdbms/ress/ress2/trace/ress2_pr00_13905.trc:
ORA-38868: warning: the control file may have incorrect data file structure
Managed Standby Recovery not using Real Time Apply
Slave exiting with ORA-38868 exception
Errors in file /u01/app/oracle/diag/rdbms/ress/ress2/trace/ress2_pr00_13905.trc:
ORA-38868: warning: the control file may have incorrect data file structure
Recovery Slave PR00 previously exited with exception 38868
MRP0: Background Media Recovery process shutdown (ress2)

Takže ORA-38868 mi říká, že mám špatnou strukturu adresářů. Moje první myšlenka byla, že to souvisí s prací, o které jsem včera blogoval. Ale ta práce byla na primární straně. Podíval jsem se zpět do protokolu pohotovostních výstrah a našel jsem první výskyt této chyby asi před 2,5 měsíci. Pokud by se jednalo o produkční systém, mohl bych mít velký problém nechat tento problém po tu dobu bez povšimnutí. Mám ale zavedená opatření, která mě upozorní, pokud se má produkční pohotovost zaostává za primárním po nepřijatelnou dobu. Toto je pouze testovací systém, který mohu odpálit a začít od nuly, pokud budu potřebovat. Ale jaká by to byla zábava? Uvidíme, zda se nám podaří problém vyřešit.

Moje první zastávka byl Metalink. Ale pro chybu ORA-38868 jsem nedostal nulu. Při vyhledávání na webu jsem dostal jeden relevantní zásah, který nabízel řešení jednoduše restartovat instanci a znovu spustit aplikaci redo. Byl jsem skeptický, ale pokusil jsem se o jednoduchou opravu. Nemělo by být překvapením, že jednoduchý restart instance problém nevyřešil. Chyba mi říká, že můj kontrolní soubor má poškození. Restartování instance neopraví poškození řídicího souboru. Protože Metalink a internet jsou k ničemu, myslím, že je na mně, abych to napravil. Pokud vše ostatní selže, jednoduše ukončím pohotovostní režim a znovu jej vytvořím.

Moje počáteční řešení je vrátit se k primárnímu a vytvořit záložní kontrolní soubor. Poté spusťte pohotovostní režim pomocí ovládacího souboru pohotovostního režimu. Věřím, že nový kontrolní soubor z primárního problém vyřeší. Potřebuji však použít 2,5 měsíce opakování, z nichž již nemám k dispozici.

Snažil jsem se prozkoumat použití RMAN k přechodu do pohotovostního režimu prostřednictvím přírůstkové zálohy. Ale zdá se, že to je v mém seznamu priorit, co je třeba udělat, nízko. Mám nadcházející projekt, kde budu potřebovat vědět, jak to udělat, a tento projekt je nyní za méně než jeden měsíc. Zdá se tedy, že je to ideální čas na procvičení této techniky pro můj nadcházející projekt a na vyřešení mého aktuálního problému. Kroky k tomu jsou v:

Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups

Kroky v tomto dokumentu nejen posunuly můj pohotovostní režim vpřed, ale také znovu vytvořily kontrolní soubory, čímž byl můj problém vyřešen.


  1. 2 způsoby, jak vytvořit tabulku na propojeném serveru pomocí T-SQL

  2. Jak získat další/předchozí záznam v MySQL?

  3. Jak zabezpečit servery MySQL/MariaDB

  4. Jak najít řetězec v řetězci na serveru SQL