Site-Failover und -Recovery

Ein Site-Failover ist erforderlich, wenn Ihre Infrastruktur ein ungeplantes Ereignis erlitten hat, das dazu führt, dass die primäre Site für einen Zeitraum nicht verfügbar und vollständig unzugänglich ist, der sich negativ auf das Unternehmen auswirkt. In diesem Szenario übernimmt die Standbydatenbank die Primärrolle.

Eine primäre Site kann aus verschiedenen Gründen nicht mehr verfügbar sein, einschließlich, aber nicht beschränkt auf:

Probleme, die dazu führen können, dass die Primärdatenbankinstanzen nicht gestartet werden, wie ausgefallene oder weitgehend beschädigte Medien oder ein fehlerhaftes BS- oder Firmwareupgrade
Infrastrukturausfall wie ein vollständiger Strom- oder Kühlsystemausfall innerhalb der OCI-Regionsinfrastruktur
Vollständige Netzwerkfehler
Naturkatastrophen wie Erdbeben, Brände und Überschwemmungen

Ungeplante Ereignisse sind zwar selten, können aber auch auftreten.

Site-Failover ausführen

Da ein echtes Failover störend ist und zu einem kleinen Datenverlust führen kann, testen Sie Ihr Site-Failover in einer TEST-Umgebung.

Im folgenden Beispiel werden Namen aus unserer Testumgebung für die Primärdatenbank in Ashburn (CDBHCM_iad1dx) und die Standbydatenbank in Phoenix (CDBHCM_phx5s) verwendet.

Erzwingen Sie das Stoppen aller Oracle Real Application Clusters-(Oracle RAC-)Datenbankinstanzen auf der Primärdatenbank.

Hinweis:
Führen Sie diesen Test nicht in einer Produktionsumgebung durch.
```
$ srvctl stop database -db CDBHCM_iad1dx -stopoption
        abort
```
Von diesem Punkt an wird angenommen, dass unser primäres (simuliertes) nicht mehr verfügbar ist. Wir werden unsere sekundäre Region zu unserem neuen primären Standort machen.
Die folgenden Schritte verwenden unsere Testimplementierung und alle Schritte werden am sekundären Standort (neue primäre) durchgeführt.

Melden Sie sich an der sekundären Site bei einem der Oracle Exadata Database Service on Dedicated Infrastructure domUs an, werden Sie BS-Benutzer oracle, und rufen Sie die Data Guard Broker-Befehlszeilenschnittstelle auf.

Knoten: Ein Oracle Exadata Database Service on Dedicated Infrastructure domU
Benutzer: oracle

$ dgmgrl sys/sys password
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx  - Primary database
    Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
  CDBHCM_phx5s - Physical standby database 
                    Transport Lag:      0 seconds (computed 18 seconds ago)
                    Apply Lag:          0 seconds (computed 18 seconds ago)

Fast-Start Failover:  Disabled

Configuration Status:
ERROR   (status updated 0 seconds ago)

Beachten Sie den Fehler.

Führen Sie ein Failover mit der Befehlszeilenschnittstelle von Oracle Data Guard Broker aus.
- Knoten: Ein Oracle Exadata Database Service on Dedicated Infrastructure domU auf der sekundären Site
- Benutzer: oracle
```
DGMGRL> failover to CDBHCM_phx5s
```
Wenn die primären Middle Tiers (einschließlich des gemeinsam verwendeten Dateisystems) noch intakt sind, führen Sie manuell eine "erzwungene" rsync vom nicht erfolgreichen primären Standort zum DR-Standort aus.

Die Anwendungs- und Web-Tiers sind möglicherweise noch funktionsfähig, aber die Prozesse für den Anwendungs- und Prozessplaner versuchen, keine Verbindung zur ausgefallenen Datenbank herzustellen. Dadurch wird die Ausführung von rsync durch das Skript rsync gestoppt.
- Knoten: Ein Middle Tier, nicht erfolgreicher primärer Standort
- Benutzer: psadm2
1. Führen Sie eine erzwungene rsync aus. Ein Beispielskript rsync_psft.sh ist im Skriptverzeichnis verfügbar.
  Wenn das Skript rsync deaktiviert ist, fordert der Parameter -f auf, mit einem erzwungenen rsync fortzufahren. Ein erzwungenes rsync konsultiert die Datenbank nicht, um die Rolle der Site zu bestimmen, und führt dann das angeforderte rsync aus.
  
  Hinweis:
  Dies sollte nur erfolgen, wenn während eines Site-Failovers eine letzte Aktualisierung erzwungen wird. Die Option FORCE wird protokolliert.
```
$ rsync_psft.sh path to file system/parameter file -f
```
  Beispiel:
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. Überwachen Sie das Prozesslog rsync, um zu prüfen, ob der Prozess erfolgreich abgeschlossen wurde.
Wenn der Sitefehler abgeschlossen ist und kein endgültiger rsync-Prozess ausgeführt werden kann, deaktivieren Sie rsync in der neuen Primärdatenbank, indem Sie das Skript disable_psft_rsync.sh ausführen.
- Knoten: Eine Middle Tier, neue primäre Site
- Benutzer: psadm2
```
disable_psft_rsync.sh
```
Wenn Sie die Active Data Guard-Unterstützung bei der Konfiguration der Primär- und Standbydatenbankserver konfiguriert haben, stellen Sie sicher, dass der Active Data Guard-Service für PeopleSoft (PSQUERY) in der neuen Primärdatenbank gestartet wurde.
- Knoten: Ein Oracle Exadata Database Service on Dedicated Infrastructure domU auf der sekundären Site
- Benutzer: oracle
```
$ srvctl status service -db CDBHCM_phx5s -s PSQUERY
Service PSQUERY is running on instance(s) CDBHCM1,CDBHCM2
```
Dieser Service muss auf allen Oracle Real Application Clusters-(Oracle RAC-)Instanzen ausgeführt werden.

Hinweis:
Dieser Service muss gestartet werden, bevor der Prozessplaner gestartet wird. Andernfalls verläuft der Prozessplaner beim Hochfahren nicht erfolgreich.
Prüfen Sie, ob die rollenbasierten Datenbankservices auf der neuen Primärdatenbank ausgeführt werden.
- Site: Site 2
- Knoten: Alle Oracle Exadata Database Service on Dedicated Infrastructure domUs
- Benutzer: oracle
Beispiel: Setzen Sie den folgenden Befehl für jede domU ab, die eine Oracle RAC-Datenbankinstanz PeopleSoft hostet:
```
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_BATCH
Service HR92U033_BATCH is running on instance(s) CDBHCM1,CDBHCM2
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_ONLINE
Service HR92U033_ONLINE is running on instance(s) CDBHCM1,CDBHCM2
```
Dieser Service muss auf allen Oracle RAC-Instanzen ausgeführt werden.

Starten Sie die Application Server- und Process Scheduler-Domains.

Site: Site 2
Knoten: Compute-Instanzen des Anwendungs- und Prozess-Scheduler-Servers
Benutzer: psadm2

Melden Sie sich bei den Compute-Instanzen an, die die PeopleSoft-Anwendungsserver und den Prozessplaner hosten, und werden Sie psadm2.
Verwenden Sie das Skript startPSFTAPP.sh aus dem Wrapper-Verzeichnis in GitHub.
```
$ startPSFTAPP.sh
```

Überwachen Sie den Start.

Sie können die Abfrage aus den Anwendungs- und Process Scheduler-Domains PeopleSoft verwenden.

col service_name format a20
select a.inst_id,a.instance_name,b.service_name, count(*)
from gv$instance a, gv$session b
where a.inst_id = b.inst_id
and service_name not like 'SYS%'
group by a.inst_id,a.instance_name,b.service_name
order by 1

SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                 2
SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                2
         1 CDBHCM1          HR92U033_BATCH               8
         1 CDBHCM1          HR92U033_ONLINE             52
         2 CDBHCM2          HR92U033_BATCH               7
         2 CDBHCM2          HR92U033_ONLINE             50

Wenn Sie keinen vollständigen Sitefehler wie in Schritt 5 beschrieben hatten, gehen Sie zum nächsten Schritt. Wenn ein vollständiger Sitefehler aufgetreten ist, müssen Sie das Skript disable_psft_rsync.sh erneut ausführen, da das Skript startPSTAPP.sh rsync aktiviert.
Hinweis:

Bei einem tatsächlichen Ausfallereignis, bei dem der primäre Standort verloren geht oder nicht mehr zugänglich ist, müssen Sie den Umfang und die Auswirkungen bewerten. Hier sind ein paar Dinge zu beachten:
- Möglicher Datenverlust der Datenbank
- Fehlende Dateisystemartefakte (Berichte, Logs, eingehende und ausgehende Dateien usw.)
Je nach Ausfall können Sie möglicherweise alle Transaktionen wiederherstellen, die an der ursprünglichen primären Transaktion festgeschrieben wurden. Wenn möglich, bitten Sie die Benutzer, die allerletzten Transaktionen zu überprüfen, an denen sie gearbeitet haben.

Es ist wahrscheinlich, dass Dateisystemartefakte fehlen, von der Ausgabe, die geschrieben oder übertragen wird, wenn der Zugriff auf die ursprüngliche Primärdatenbank beendet wird. Verwenden Sie das Berichtslogging in der Datenbank, um Dateisystemartefakte zu identifizieren, die nahe der Zeit des Ausfalls erstellt wurden, und bestimmen Sie dann, was für fehlende oder unvollständige Dateien von Fall zu Fall getan werden muss.
Starten Sie Web Services.
- Site: Site 2
- Knoten: Alle PeopleSoft Internet Architecture-(PIA-)Webserver-Compute-Instanzen
- Benutzer: psadm2
Wenn Coherence*Web konfiguriert ist, starten Sie zuerst das Cachecluster auf allen Compute-Instanzen, auf denen die PIA-Webserver gehostet werden, und starten dann die PIA-Webserver. In diesem Beispiel wird ein Skript verwendet, um beide in der richtigen Reihenfolge zu starten.
1. Melden Sie sich bei den PIA-Webservern an, und werden Sie psadm2.
2. Starten Sie mit dem Skript von startPSFTAPP.sh die Webserver.
```
$ startPSFTWEB.sh
```
Prüfen Sie den Load Balancer.
- Standort: Region Standort 2
- Knoten: OCI-Konsole
- Benutzer: Mandantenadministrator
1. Melden Sie sich bei der OCI-Konsole an, und ändern Sie die Region in Ihre neue primäre Region.
2. Wählen Sie im Hauptmenü Networking und dann Load Balancer aus.
3. Wählen Sie das entsprechende Compartment aus.
4. Klicken Sie auf Backend-Set und dann auf Backends.
  Jedes Backend muss OK enthalten. Es kann einige Minuten dauern, bis jeder PIA-Webserver gestartet wurde.

Nicht erfolgreiche Primärdatenbank als neue Standby-Datenbank neu instanziieren

Sie sollten Ihre neue Produktionsumgebung mit einer Standbydatenbank schützen. Idealerweise können Sie die ausgefallene Primärdatenbank als neue Standbydatenbank neu instanziieren, indem Sie sowohl die Datenbank als auch die Dateisysteme neu instanziieren.

Alte Primärdatenbank als Standby neu instanziieren

Oracle Data Guard verhindert, dass die alte Primärdatenbank geöffnet wird, wenn sie nach einem Ausfall der primären Site wieder verfügbar gemacht wird. Jeder Versuch, die Datenbank normal zu starten, schlägt fehl. Meldungen, die in das Alertlog geschrieben werden, weisen darauf hin, dass eine Wiederinbetriebnahme erforderlich ist. Wenn Flashback Database vor dem Fehler in dieser Datenbank aktiviert wurde, können Sie die alte Primärdatenbank als neue Standbydatenbank neu instanziieren.

Führen Sie die folgenden Schritte aus, um die alte Primärdatenbank als Standbydatenbank der aktuellen Produktion wiederherzustellen:

Melden Sie sich bei einer der domUs an, in denen die alte Primärdatenbank gehostet wird, und starten Sie die Datenbank:
```
$ srvctl start database -db CDBHCM_phx5s
```

Melden Sie sich bei der Data Guard Broker-Befehlszeilenschnittstelle in der neuen primären Region an, und zeigen Sie die Konfiguration an.

Beachten Sie den ORA-16661-Fehler in Fettdruck unten.

$ dgmgrl sys/sys password
DGMGRL> show configuration
configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 12 seconds ago)

Standby neu instanziieren
```
DGMGRL> REINSTATE DATABASE CDBHCM_phx5s;
```
Hinweis:
Der Prozess zum Wiederherstellen der ausgefallenen Datenbank und zum Starten einer gültigen Standby-Datenbank kann einige Zeit in Anspruch nehmen.
Prüfen Sie den Status Ihrer Umgebung mit der Data Guard Broker-Befehlszeilenschnittstelle.
Beispiel:
```
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database 
                    Transport Lag:      0 seconds (computed 1 second ago)
                    Apply Lag:          0 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 35 seconds ago)
```
Die neu instanziierte Datenbank dient jetzt als Standbydatenbank, schützt die Primärdatenbank und ist für Switchover und Failover verfügbar.

Wenn Sie die Active Data Guard-Unterstützung bei der Konfiguration der Primär- und Standbydatenbankserver konfiguriert haben, kann der Active Data Guard-Service für PeopleSoft (PSQUERY) von der Primärdatenbank zurück in die Standbydatenbank verschoben werden.

Alte primäre Middle Tiers als Standby wiederherstellen

Reaktivieren Sie die alten primären Middle Tiers basierend auf Ihrem Failover-Ereignis.

Wenn die alten primären Middle Tier-Server während des Datenbank-Failover-Ereignisses verfügbar blieben, hätten Sie zum Zeitpunkt des Fehlers eine endgültig erzwungene rsync von der ausgefallenen primären Site zur Standbydatenbank ausführen müssen und dann die Richtung der rsync-Prozesse auf die gleiche Weise wie bei einem Switchover umgekehrt.

Die Anwendungs- und Web-Tiers sind möglicherweise noch funktionsfähig, aber die Prozesse für den Anwendungs- und Prozessplaner versuchen, keine Verbindung zur ausgefallenen Datenbank herzustellen. Dadurch wird die Ausführung von rsync durch das Skript rsync gestoppt.
1. Wenn die primären Middle Tiers, einschließlich des gemeinsam genutzten Dateisystems, noch intakt sind, führen Sie manuell eine erzwungene rsync vom ausgefallenen primären Standort zum DR-Standort durch.
  Wenn das rsync-Skript deaktiviert ist, fordert der Parameter -f auf, mit einem erzwungenen rsync fortzufahren. Eine erzwungene rsync konsultiert die Datenbank nicht, um die Standortrolle zu bestimmen, und führt dann die angeforderte rsync aus.
  
  Hinweis:
  Dies sollte nur erfolgen, wenn während eines Site-Failovers eine letzte Aktualisierung erzwungen wird. Die Option FORCE wird protokolliert.
  
  Sie können das Beispielskript im Skriptverzeichnis rsync_psft.sh als Benutzer psadm2 verwenden:
```
$ rsync_psft.sh path to file system/parameter file -f
```
  Beispiel:
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. Überwachen Sie das Prozesslog rsync, um zu prüfen, ob der Prozess erfolgreich abgeschlossen wurde.
Wenn der Zugriff auf die alte primäre Site auch für rsync vollständig nicht möglich ist, führen Sie die folgenden Schritte aus:
1. Deaktivieren Sie die rsync-Skripte auf der neuen primären Site mit disable_psft_rsync.sh für alle zu replizierenden Dateisysteme.
2. Wenn Sie die Aktivität auf den ursprünglichen Middle Tiers zu einem späteren Zeitpunkt fortsetzen können, aktivieren Sie die rsync-Skripte erneut, und lassen Sie sie nachholen.
Wenn Sie die Middle Tiers neu erstellen müssen, befolgen Sie die oben beschriebenen Prozesse.