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.