Nach einem kürzlichen Stromausfall an unserem DR-Standort stellte ich fest, dass ein Standby dort keine Protokolle mehr anwendete. Anscheinend befand sich in den archivierten Redo-Protokollen eine Transaktion, die eine Datendatei vergrößerte, aber die Festplatte am Standby-Standort hatte nicht genügend Speicherplatz, um diese Transaktion abzuschließen. Der Standby-Modus beendete also die verwaltete Wiederherstellung, wie es sollte.
Wir bewahren die archivierten Redo-Logs normalerweise 7 Tage lang auf. Als ich diese Situation entdeckte, waren leider 15 Tage vergangen und die archivierten Redo-Protokolle „fehlten“. Da keine archivierten Redo-Protokolle angewendet werden mussten, bestand die einzige Lösung darin, die Datenbank von Grund auf neu zu erstellen. Diese Datenbank ist ungefähr 7 TB groß, daher ist der Wiederaufbau von Grund auf keine triviale Angelegenheit.
Die primäre ist eine RAC 11.2.0.2-Datenbank mit 3 Knoten, die unter Linux ausgeführt wird. Die Standby-Datenbank ist eine RAC-Datenbank mit zwei Knoten, offensichtlich dieselben Oracle- und Betriebssystemversionen.
So haben wir die Wiederherstellung des Standby-Modus erreicht:
- Wir haben die Primärdatenbank in den Hot-Backup-Modus versetzt und einen festplattenbasierten Snapshot der Datenbank erstellt.
- Der Schnappschuss wurde auf ein externes Medium kopiert. Hinweis:Der Versand über das WAN war zu zeitaufwändig.
- Die externen Medien wurden von Hand zum DR-Standort getragen.
- Der LOG_ARCHIVE_DEST_STATE_n für den Standby wurde auf DEFER gesetzt.
- Die Standby-Datenbank wurde aus der DG Broker-Konfiguration gelöscht: REMOVE DATABASE standby PRESERVE DESTINATIONS;
- Die Einhängepunkte der Standby-Datenbank wurden gelöscht. Schließlich war die Datenbank zu diesem Zeitpunkt im Wesentlichen nutzlos.
- Neue Bereitstellungspunkte wurden erstellt und der Snapshot wurde auf die Festplatte am DR-Standort geschrieben.
- Nachdem die Dateiübertragungen abgeschlossen waren (ca. 5 Tage), haben wir unseren Speicher angewiesen, den Snapshot am DR-Standort mit einem aktuelleren Snapshot zu aktualisieren. Dies wurde über das WAN durchgeführt, da nur die Änderungen gesendet wurden, die viel, viel kleiner als die Datenbank waren.
- Eine Standby-Steuerdatei wurde erstellt: ALTER DATABASE CREATE STANDBY CONTROLFILE AS „/dir/path“;
- Um die Dinge einfach zu halten, wollten wir eine Einzelinstanz-Standby verwenden, bis wir sie zum Laufen gebracht haben. Also haben wir eine PFILE aus der RAC SPFILE des Standby erstellt und dann einen Texteditor verwendet, um die Parameterdatei zu ändern, um alle RAC-fähigen Parameter zu entfernen. Wir haben CLUSTER_DATABASE entfernt, einen instanzspezifischen UNDO_TABLESPACE-Parameter gesetzt, der für alle Instanzen „*.“ verwendet werden soll, THREAD-Parameter entfernt usw. Unsere normale Standby-Datenbank hat zwei Instanzen, STANDBY1 und STANDBY2. In Knoten 1 haben wir die pfile in $ORACLE_HOME/dbs/initstandby.ora statt in initstandby1.ora abgelegt, damit die Single-Instance-Datenbank ihre Parameterdatei finden kann. Wir haben etwas Ähnliches für die Passwortdatei gemacht.
- Wir haben die Standby-Steuerdatei aus Schritt 9 über die Steuerdateien im Datenbank-Snapshot kopiert.
- Mit der pfile- und pswd-Datei für eine Einzelinstanzdatenbank haben wir STARTUP MOUNT durchgeführt.
- Wir haben alle erforderlichen Standby-Redo-Protokolle erstellt. In unserem Fall verfügt die Primärdatenbank auch über Standby-Redo-Protokolle, um Umschaltvorgänge zu erleichtern, und die Standby-Redo-Protokolle der Primärdatenbank waren nicht Teil des Snapshots. Also mussten wir die SRLs entfernen, die die Reise nicht gemacht haben.
- Setzen Sie im primären LOG_ARCHIVE_DEST_STATE_n auf ENABLE.
- In den primären Instanzen wurde ALTER SYSTEM SWITCH LOGFILE ausgeführt;
- In den Warnungsprotokollen des primären und des Standby-Servers überprüft, dass der Standby-Server Protokolle empfängt, d. h. bestätigt, dass der Protokolltransport funktioniert hat.
- Managed Standby aktiviert:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT OF SESSION;
- Im Warnungsprotokoll des Standby wurde überprüft, dass die Protokolle angewendet wurden, d. h. die bestätigte Anwendung funktionierte jetzt.
Zu diesem Zeitpunkt hatten wir eine Standby-Datenbank gesichert und ausgeführt. Wir haben eine einfache Tabelle in der Primärtabelle erstellt und eine Datenzeile darin eingefügt, die Protokollwechsel erneut durchgeführt und dann die Standby-Tabelle im schreibgeschützten Modus geöffnet, um zu überprüfen, ob die Transaktion in der Standby-Tabelle ordnungsgemäß wiedergegeben wurde. Sobald wir uns davon überzeugt haben, dass die Standby-Datenbank funktioniert, müssen wir sie zu einer RAC-Datenbank machen. Nun, alles ist bereits vorhanden, damit dies eine RAC-Datenbank ist, weil sie es einmal war. Um den Job abzuschließen, haben wir einfach die Einzelinstanz-Standby-Datenbank (SHUTDOWN ABORT) in SQL*Plus heruntergefahren und dann srvctl verwendet, um die Standby-Datenbank als RAC-Datenbank zu starten:
srvctl start database -d standby -o mount
Das einzige, was an dieser Stelle übrig blieb, war, den Standby wieder zur DG Broker-Konfiguration (in DGMGRL) hinzuzufügen: ADD DATABASE standby
Als dies zum ersten Mal passierte, war ich nervös, wie es mit einer so großen Datenbank laufen würde. Keine der oben genannten Operationen ist größenabhängig, mit Ausnahme des Kopierens der Dateien auf und von Medien. Aber es ging alles gut.
Um sicherzustellen, dass wir in Zukunft nicht in diese Situation geraten, haben wir unserem Oracle Enterprise Manager Grid Control Warnfunktionen hinzugefügt. Ich erhalte jetzt eine WARNUNG-Warnung, wenn der Log-Versand oder die Log-Beantragung 12 Stunden im Rückstand sind, und eine CRITICAL-Warnung, wenn 24 Stunden im Rückstand sind. Das sollte uns genügend Zeit geben, um Probleme zu beheben, bevor die archivierten Redo-Protokolle nach 7 Tagen automatisch entfernt werden, oder zumindest den Prozess so ändern, dass mehr Tage an archivierten Redo-Protokollen gespeichert werden, bis wir die Situation behoben haben.
