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:
Fall A: Master DB voll funktionsfähig
../runDorecover auf dem Slave aufrufen um letzte Synchronisierung sicherzustellen
Master Listener stoppen
aktive Benutzer abmelden ( Applikationen stoppen)
DB durchstarten mit shutdown immediate und startup
Letzte Archivelogs erzeugen
DB mit shutdown immediate stoppen
Fall B: Master DB Server zeigt Fehler auf
Master DB mit shutdown immediate stoppen wenn möglich ansonsten
Listener stoppen falls möglich
Vom Standby System letzte Archivelogs des produktiven Masters „retten“
DNS anpassen (Masterdb auf neuen produktiven Master!)
Letztes Recovery der noch anstehenden, nicht verarbeiteten Archivelogs
Shutdown Standby DB
'DNS Umschaltung auf DB1 und DB2 prüfen, bei Bedarf Cache aktualisieren
Standby System als Master DB öffnen
Listener und connect per SQL*Net prüfen (lokal und remote)
Applikationen je nach Bedarf neu starten
Nagios Skripte anpassen
Genau Details und Scripts und die Unterstützung bei der Umsetzung biete Ich Ihnen gerne an!
Bitte melden Sie sich über mein Kontaktformular .
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
"Autor: Gunther Pipperr"
dba/standby_db_per_script.txt · Zuletzt geändert: 2014/12/15 15:44 von gpipperr