Quando ho lavorato su un database in standby di recente, sono andato da DG Broker per controllare lo stato e ho ricevuto questo:
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 ... il mio standby non sta applicando il ripristino. Quando ho tentato di avviare il ripristino gestito, ho visualizzato quanto segue nel registro degli avvisi di standby:
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)
Quindi ORA-38868 mi dice che ho una struttura di directory errata. Il mio primo pensiero è stato che questo fosse legato al lavoro di cui ho scritto ieri sul blog. Ma quel lavoro era sul lato primario. Ho esaminato il registro degli avvisi di standby e ho trovato la prima occorrenza di questo errore circa 2,5 mesi fa. Se questo fosse un sistema di produzione, potrei avere grossi problemi a lasciare che questo problema passi inosservato per quel periodo di tempo. Ma ho delle misure in atto per avvisarmi se il mio standby di produzione è in ritardo rispetto al primario per un periodo di tempo inaccettabile. Questo è solo un sistema di test che posso spazzare via e ricominciare da zero se necessario. Ma che divertimento sarebbe? Vediamo se riusciamo a risolvere il problema.
La mia prima tappa è stata Metalink. Ma ho avuto zero riscontri per l'errore ORA-38868. Durante una ricerca sul Web, ho ricevuto un risultato pertinente che offriva una soluzione per riavviare semplicemente l'istanza e riavviare l'applicazione di ripetizione. Ero scettico, ma ho tentato la soluzione facile. Non dovrebbe sorprendere che un semplice riavvio dell'istanza non abbia risolto il problema. L'errore mi dice che il mio file di controllo è danneggiato. Il riavvio dell'istanza non risolverà il danneggiamento del file di controllo. Dal momento che Metalink e Internet non sono di alcuna utilità, immagino che stia a me risolvere questo problema. Se tutto il resto fallisce, abbandonerò semplicemente lo standby e lo ricreerò.
La mia soluzione iniziale è tornare al primario e creare un file di controllo in standby. Quindi avviare lo standby con il file di controllo dello standby. Ho fiducia che un nuovo file di controllo dal primario risolverà il problema. Tuttavia, devo applicare 2,5 mesi di ripristino di cui non ho più a disposizione.
Ho cercato di indagare sull'utilizzo di RMAN per portare avanti uno standby tramite un backup incrementale. Ma questo sembra non rientrare nella mia lista di priorità delle cose da fare. Ho un progetto imminente in cui avrò bisogno di sapere come farlo e quel progetto è ora tra meno di un mese. Quindi questo sembra il momento perfetto per praticare questa tecnica per il mio prossimo progetto e per risolvere il mio problema attuale. I passaggi per farlo sono in:
Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups
I passaggi in questo documento non solo hanno portato avanti il mio standby, ma hanno anche ricreato i file di controllo, risolvendo così il mio problema.
