Als ich kürzlich an einer Standby-Datenbank arbeitete, ging ich zu DG Broker, um den Status zu überprüfen, und erhielt Folgendes:
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 … mein Standby wendet Redo nicht an. Als ich versuchte, die verwaltete Wiederherstellung zu starten, erhielt ich Folgendes im Standby-Alarmprotokoll:
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)
Der ORA-38868 sagt mir also, dass ich eine schlechte Verzeichnisstruktur habe. Mein erster Gedanke war, dass dies mit der Arbeit zusammenhängt, über die ich gestern gebloggt habe. Aber diese Arbeit war auf der primären Seite. Ich habe mir das Standby-Alarmprotokoll angesehen und das erste Auftreten dieses Fehlers vor etwa 2,5 Monaten festgestellt. Wenn dies ein Produktionssystem wäre, könnte ich große Probleme haben, dieses Problem für diesen Zeitraum unbemerkt zu lassen. Aber ich habe Maßnahmen ergriffen, um mich zu warnen, wenn mein Produktions-Standby für einen inakzeptablen Zeitraum hinter dem primären zurückbleibt. Dies ist nur ein Testsystem, das ich wegblasen und bei Bedarf von vorne anfangen kann. Aber was für ein Spaß wäre das? Mal sehen, ob wir das Problem beheben können.
Meine erste Station war Metalink. Aber ich habe null Treffer für den Fehler ORA-38868 erhalten. Bei einer Websuche erhielt ich einen relevanten Treffer, der eine Lösung zum einfachen Neustart der Instanz und zum erneuten Starten von Redo Apply bot. Ich war skeptisch, versuchte es aber mit der einfachen Lösung. Es sollte nicht überraschen, dass ein einfacher Neustart der Instanz das Problem nicht behoben hat. Der Fehler sagt mir, dass meine Steuerdatei beschädigt ist. Durch einen Neustart der Instanz wird die Beschädigung der Steuerdatei nicht behoben. Da Metalink und das Internet keinen Nutzen haben, denke ich, dass es an mir liegt, das Problem zu beheben. Wenn alles andere fehlschlägt, lösche ich einfach den Standby-Modus und erstelle ihn neu.
Meine anfängliche Lösung besteht darin, zur Primärdatei zurückzukehren und eine Standby-Steuerdatei zu erstellen. Starten Sie dann den Standby mit der Standby-Steuerdatei. Ich bin zuversichtlich, dass eine neue Steuerdatei von der Primärdatei das Problem lösen wird. Allerdings muss ich 2,5 Monate Redo beantragen, die ich nicht mehr zur Verfügung habe.
Ich habe versucht, die Verwendung von RMAN zu untersuchen, um ein Standby über ein inkrementelles Backup fortzusetzen. Aber das scheint in meiner Prioritätenliste der Dinge, die zu tun sind, weit unten zu stehen. Ich habe ein bevorstehendes Projekt, bei dem ich wissen muss, wie das geht, und dieses Projekt ist jetzt weniger als einen Monat entfernt. Dies scheint also ein perfekter Zeitpunkt zu sein, um diese Technik für mein bevorstehendes Projekt zu üben und mein aktuelles Problem zu beheben. Die Schritte dazu finden Sie in:
Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups
Die Schritte in diesem Dokument haben nicht nur meine Standby-Datei aktualisiert, sondern auch die Steuerdateien neu erstellt, wodurch mein Problem behoben wurde.
