Zwei Strategien werden dazu ergänzend umgesetzt:

1. redundantes Backup der Produktionsdatenbank
2. permanentes Recovery der Archivelogs der Master DB in die Standby Datenbank

Übersicht:

Umschaltverfahren – Slave wird Master Im Fall A ist der Master noch voll funktionsfähig, es wird z.B. aus Wartungsgründen umgeschaltet.
Im Fall B ist der Master durch z.B. einen Hardwaredefekt aufgefallen und nur bedingt/gar nicht mehr funktionsfähig.

Prinzipieller Ablauf:

1. Fall A: Master DB voll funktionsfähig
   1. ../runDorecover auf dem Slave aufrufen um letzte Synchronisierung sicherzustellen
   2. Master Listener stoppen
   3. aktive Benutzer abmelden ( Applikationen stoppen)
   4. DB durchstarten mit shutdown immediate und startup
   5. Letzte Archivelogs erzeugen
   6. DB mit shutdown immediate stoppen
2. Fall B: Master DB Server zeigt Fehler auf
   1. Master DB mit shutdown immediate stoppen wenn möglich ansonsten
   2. Listener stoppen falls möglich
   3. Vom Standby System letzte Archivelogs des produktiven Masters „retten“
3. DNS anpassen (Masterdb auf neuen produktiven Master!)
4. Letztes Recovery der noch anstehenden, nicht verarbeiteten Archivelogs
5. Shutdown Standby DB
6. 'DNS Umschaltung auf DB1 und DB2 prüfen, bei Bedarf Cache aktualisieren
7. Standby System als Master DB öffnen
8. Listener und connect per SQL*Net prüfen (lokal und remote)
9. Applikationen je nach Bedarf neu starten
10. Nagios Skripte anpassen