Da jeg for nylig arbejdede på en standby-database, gik jeg til DG Broker for at tjekke status og modtog dette:
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 … min standby anvender ikke Redo. Da jeg forsøgte at starte administreret gendannelse, fik jeg følgende i standby-advarselsloggen:
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)
Så ORA-38868 fortæller mig, at jeg har en dårlig mappestruktur. Min første tanke var, at dette var relateret til det arbejde, jeg bloggede om i går. Men det arbejde var på den primære side. Jeg kiggede tilbage på standby-advarselsloggen og fandt den første forekomst af denne fejl for omkring 2,5 måneder siden. Hvis dette var et produktionssystem, kunne jeg have store problemer med at lade dette problem gå ubemærket hen i den periode. Men jeg har truffet foranstaltninger til at advare mig, hvis min produktionsstandby halter bagefter primært i en uacceptabel periode. Dette er blot et testsystem, som jeg kan blæse væk og starte fra bunden, hvis jeg har brug for det. Men hvad sjovt ville det være? Lad os se, om vi kan løse problemet.
Mit første stop var Metalink. Men jeg fik nul hits for ORA-38868-fejlen. Da jeg lavede en websøgning, fik jeg et relevant hit, som tilbød en løsning med blot at genstarte forekomsten og genstarte Anvend om igen. Jeg var skeptisk, men forsøgte den nemme løsning. Det burde ikke være nogen overraskelse, at en simpel genstart af instansen ikke løste problemet. Fejlen fortæller mig, at min kontrolfil har korruption i sig. Genstart af forekomsten vil ikke løse kontrolfilkorruption. Da Metalink og internettet ikke nytter noget, gætter jeg på, at det er op til mig at rette dette. Hvis alt andet fejler, vil jeg simpelthen droppe standbyen og genskabe den.
Min første løsning er at gå tilbage til den primære og oprette en standby-kontrolfil. Start derefter standbyen med standby-kontrolfilen. Jeg har tillid til, at en ny kontrolfil fra den primære vil løse problemet. Jeg er dog nødt til at anvende 2,5 måneders genoptagelse, som jeg ikke længere har til rådighed.
Jeg har forsøgt at undersøge brugen af RMAN til at rulle frem en standby via en inkrementel backup. Men dette ser ud til at falde lavt på min prioriterede liste over ting, jeg skal gøre. Jeg har et kommende projekt, hvor jeg skal vide, hvordan man gør dette, og det projekt er nu mindre end en måned væk. Så det virker som et perfekt tidspunkt til at øve denne teknik til mit kommende projekt og til at løse mit nuværende problem. Trinene til at gøre dette er i:
Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups
Trinnene i dette dokument rullede ikke kun min standby frem, men genskabte også kontrolfilerne og løste dermed mit problem.