Toen ik onlangs aan een standby-database werkte, ging ik naar DG Broker om de status te controleren en ontving dit:
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...mijn stand-by past opnieuw niet toe. Toen ik probeerde om beheerd herstel te starten, kreeg ik het volgende in het standby-waarschuwingslogboek:
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)
Dus de ORA-38868 vertelt me dat ik een slechte directorystructuur heb. Mijn eerste gedachte was dat dit te maken had met het werk waar ik gisteren over blogde. Maar dat werk was aan de primaire kant. Ik keek terug naar het standby-waarschuwingslogboek en vond het eerste optreden van deze fout ongeveer 2,5 maanden geleden. Als dit een productiesysteem was, zou ik grote problemen kunnen hebben om dit probleem voor die tijd onopgemerkt te laten. Maar ik heb maatregelen getroffen om me te waarschuwen als mijn productie-standby voor een onaanvaardbare periode achterblijft bij de primaire. Dit is slechts een testsysteem dat ik kan wegblazen en opnieuw kan beginnen als dat nodig is. Maar wat zou dat leuk zijn? Laten we kijken of we het probleem kunnen oplossen.
Mijn eerste stop was Metalink. Maar ik kreeg nul hits voor de ORA-38868-fout. Toen ik op internet zocht, kreeg ik een relevante hit die een oplossing bood om de instantie eenvoudig opnieuw te starten en opnieuw te starten. Ik was sceptisch, maar probeerde de gemakkelijke oplossing. Het zou geen verrassing moeten zijn dat een eenvoudige herstart van de instantie het probleem niet oploste. De fout vertelt me dat mijn controlebestand corruptie bevat. Het herstarten van de instantie zal de corruptie van het controlebestand niet oplossen. Aangezien Metalink en internet nutteloos zijn, denk ik dat het aan mij is om dit op te lossen. Als al het andere faalt, laat ik de stand-by gewoon vallen en maak ik hem opnieuw.
Mijn eerste oplossing is om terug te gaan naar de primaire en een reservebesturingsbestand te maken. Start vervolgens de standby op met het standby-besturingsbestand. Ik heb er vertrouwen in dat een nieuw controlebestand van de primaire het probleem zal oplossen. Ik moet echter 2,5 maanden opnieuw uitvoeren, waarvan ik niet langer beschikbaar heb.
Ik heb geprobeerd te onderzoeken met behulp van RMAN om een stand-by door te sturen via een incrementele back-up. Maar dit lijkt laag op mijn prioriteitenlijstje van dingen om te doen. Ik heb een aankomend project waarbij ik moet weten hoe ik dit moet doen en dat project is nu minder dan een maand verwijderd. Dus dit lijkt een perfect moment om deze techniek te oefenen voor mijn aanstaande project en om mijn huidige probleem op te lossen. De stappen om dit te doen staan in:
Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups
De stappen in dit document brachten niet alleen mijn stand-by voort, maar creëerden ook de controlebestanden opnieuw, waardoor mijn probleem werd opgelost.