Ich bin dabei, Hardware für einen vorhandenen RAC-Cluster mit 3 Knoten zu ersetzen. Dieses System ist auch primär für eine 2-Knoten-RAC-Standby-Datenbank. Um die Hardware zu ersetzen, plane ich, den Cluster vorübergehend auf eine 6-Knoten-Konfiguration, 3 alte Server und 3 neue Server zu erweitern. Sobald ich die Instanzen auf der neuen Hardware ausgeführt und meine Anwendungen eine Verbindung zu den neuen Instanzen hergestellt habe, werde ich die alten Instanzen herunterfahren und die alten Server stilllegen, um zu einer 3-Knoten-Konfiguration zurückzukehren.
Nachdem ich den Cluster auf alle sechs Knoten erweitert hatte, habe ich am vergangenen Wochenende die neuen Instanzen auf den neuen Knoten gestartet. Um mir das Leben zu erleichtern, habe ich für diese Arbeit einfach die DBCA genutzt. Nachdem ich DBCA hochgefahren hatte, entschied ich mich, an einer RAC-Datenbank zu arbeiten, und wählte dann Instanzverwaltung und dann Neue Instanz hinzufügen. Beim Durchlaufen des Assistenten lasse ich die DBCA alle Details für mich erledigen. Klingt einfach.
Heute Morgen habe ich meinen üblichen Archivverzögerungsbericht erhalten. Es sieht etwa so aus:
INSTANCE_NAME APPLY_LAG CURR_TIME
orcs1 +01 21:40:47 2012-12-03 08:00:01
Ich schicke dies zweimal täglich an meinen Posteingang. Ein kurzer Blick hilft mir festzustellen, ob mein Standby Transaktionen von der primären empfängt und anwendet. Ich habe alle meine Standby-Datenbanken auf eine Anwendungsverzögerung von vier Stunden eingestellt. Und meine primäre hat ARCHIVE_LAG_TARGET auf eine Stunde eingestellt. Dies bedeutet, dass die Anwendungsverzögerung mindestens 4 Stunden beträgt, jedoch nicht mehr als 5 Stunden betragen sollte. Wie wir oben sehen können, haben wir zwei Standby-Datenbanken, die die maximale Anwendungsverzögerung von 5 Stunden deutlich überschritten haben. Oben habe ich den Standby mit einer Verzögerung von 1 Tag 21 Stunden angewendet! Da wusste ich sofort, dass etwas nicht stimmt. Und man musste kein Raketenwissenschaftler sein, um zu wissen, dass das Hinzufügen der neuen Instanz zur primären wahrscheinlich zu dem Problem beigetragen hat.
Wie ich am Anfang dieses Beitrags sagte, habe ich ein 2-Knoten-RAC-Standby-System. Eine Instanz ist die „Anwendungsinstanz“ und die andere Instanz sitzt dort relativ untätig. In meinem Warnungsprotokoll für die Anwendungsinstanz habe ich die folgenden Fehlermeldungen gesehen:
Sa. Dez. 01 14:25:40 2012
Erstellte Wiederherstellungsdatei /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
Datendatei 342 erfolgreich zur Medienwiederherstellung hinzugefügt
Datendatei #342:'/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
Kein OMF-Ziel angegeben, Protokolle können nicht erstellt werden
Fehler mit Protokoll /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0:Medienwiederherstellung im Hintergrund mit Fehler 1264 beendet
Fehler in Datei /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264:Protokolldatei-Dateiname kann nicht erstellt werden
Wiederherstellung unterbrochen!
Sa. Dez. 01 14:25:51 2012
Wiederhergestellte Datendateien in einen konsistenten Zustand bei Änderung 192271576009
Sa. Dez. 01 14:25:51 2012
MRP0:Herunterfahren des Medienwiederherstellungsprozesses im Hintergrund (orcs2)
Da ich meine Standby-Datenbank auf STANDBY_FILE_MANAGEMENT=AUTO eingestellt habe, ist der erste Teil der Meldungen sinnvoll. Wenn Sie einer RAC-Datenbank eine neue Instanz hinzufügen, müssen Sie nur für diese Instanz einen Undo-Tablespace bereitstellen, und Sie müssen auch Online-Redo-Log-Gruppen bereitstellen, die dem Thread dieser Instanz gewidmet sind. Die DBCA hat mir speziell Fragen zu den Undo- und Redo-Dateistrukturen gestellt. Im Inhalt des Alarmprotokolls oben können wir sehen, dass die Standby-Datei erfolgreich die Datendatei 342 hinzugefügt hat, die mein Undo-Tablespace ist. Aber der Standby konnte die Online-Redo-Logs nicht hinzufügen. Wenn Sie möchten, dass der Standby die Online-Redo-Protokolle automatisch hinzufügen kann, müssen Sie OMF-Parameter angeben, was ich nur ungern mache. Da das Hinzufügen der Online-Redo-Log-Datei zu einem Fehler führte, stoppte der Standby-Modus die Medienwiederherstellung. Der Standby-Server empfängt weiterhin Protokolle.
Ich habe auf Metalink oder bei der Google-Suche nicht viel gefunden, um dieses Problem zu lösen, aber hier sind die Schritte, die ich unternommen habe, um die Medienwiederherstellung wieder zum Laufen zu bringen. Auf der Standby-Datenbank (ich habe dies auf der Anwendungsinstanz getan, aber es sollte auf jeder Instanz in der RAC-Standby-Datenbank möglich sein):
1. Datenbank ändern verwaltete Standby-Datenbank wiederherstellen abbrechen;
Datenbank ändern verwaltete Standby-Datenbank wiederherstellen abbrechen
*
FEHLER in Zeile 1:
ORA-16136:Managed Standby Recovery nicht aktiv
Dies sollte kein Schock sein, da wir wissen, dass Managed Recovery abgebrochen wurde. Aber der Vollständigkeit halber habe ich diesen Schritt eingefügt. Wenn Sie Redo-Protokolle zu einem Standby hinzufügen müssen, das gerade Transaktionen anwendet, dann benötigen Sie diesen Schritt.
2. alter system set standby_file_management='MANUAL' scope=memory;
System geändert.
3. Datenbank ändern Protokolldatei hinzufügen Thread 4 Gruppe 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' Größe 536871424;
Datenbank geändert.
Das obige ist genau das, was auf der Primärseite ausgeführt wurde. Sie müssen das Redo-Protokoll auf dem Standby genauso hinzufügen wie auf dem primären. Wiederholen Sie dies für jede Redo-Log-Gruppe, die auf der primären hinzugefügt wird. Da ich meiner primären RAC-Datenbank drei Instanzen hinzugefügt habe, muss ich hier drei Threads hinzufügen.
4. alter system set standby_file_management='AUTO' scope=memory;
System geändert.
5. Datenbank ändern verwaltete Standby-Datenbank wiederherstellen Sitzung trennen;
Datenbank geändert.
Starten Sie die verwaltete Wiederherstellung. Jetzt sollte alles in Ordnung sein und wir können dies im Warnprotokoll der Anwendungsinstanz überprüfen:
Datenbank ändern verwaltete Standby-Datenbank wiederherstellen Sitzung trennen
Versuchen Sie, den Managed Standby Recovery-Prozess im Hintergrund zu starten (orcs2)
Montag 03. Dez. 13:32:38 2012
MRP0 startete mit pid=47, OS id=13232
MRP0:Im Hintergrund verwalteter Standby-Wiederherstellungsprozess gestartet (orcs2)
Logmerger-Prozess gestartet
Mon. Dez. 03 13:32:44 2012
Managed Standby Recovery verwendet Real Time Apply nicht
Montag 03. Dez. 13:32:49 2012
Parallel Media Recovery mit 4 Slaves gestartet
Warten auf Archivierung aller nicht aktuellen ORLs...
Alle nicht aktuellen ORLs wurden archiviert.
Montag 03. Dez. 13:32:49 2012
Abgeschlossen:Datenbank ändern verwaltete Standby-Datenbank wiederherstellen Sitzung trennen
Mon. Dez. 03 13:32:50 2012
Medienwiederherstellungsprotokoll /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Medienwiederherstellungsprotokoll /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Medienwiederherstellungsprotokoll /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Medienwiederherstellungsprotokoll /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
Wir können auch überprüfen, ob die Anwendungsverzögerung kürzer wird. Geben Sie im Standby-Modus Folgendes aus:
wählen Sie i.instance_name,d.value als apply_lag,
to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') als curr_time
von v$instance i,v$dataguard_stats d
wobei d.name='Lag anwenden';
Hintergrundinformationen zur Verwaltung von Online-Redo-Logs für Ihre physische Standby-Datenbank finden Sie im Metalink-Hinweis 740675.1 Online-Redo-Logs in einem Standby.
