Site Logo

IzzySoft


Das inoffizielle Android-HandbuchDas inoffizielle Android-Handbuch
Für 16,99 € bei Amazon kaufen
Das inoffizielle Android-SystemhandbuchDas inoffizielle Android-Systemhandbuch
Für 6,99 € bei Amazon kaufen
Die besten Android-Apps: Android-Systemtools. Fotografie & Freizeit. Büro-Tools, Schule und StudiumDie besten Android-Apps: Android-Systemtools. Fotografie & Freizeit. Büro-Tools, Schule und Studium
Für 2,94 € bei Amazon kaufen
Stand: 2024-03-28 04:07
Preis & Verfügbarkeit können sich geändert haben.

Manueller Switchover im Data Guard Setup ohne Verwendung von dgmgrl

Wer Data Guard nutzt und einen SwitchOver per dgmgrl auslöst, riskiert eine Lizenzverletzung: Die neue Standby-Datenbank befindet sich anschließend in einem open_mode von READ ONLY WITH APPLY – was die Active Data Guard Lizenz erfordert, welche man (besonders anbetrachts ihres hohen Preises von ca. 25% der kompletten Enterprise Edition) nicht unbedingt erworben hat. Und nein: Das ist nicht auf einen Anwender-Fehler zurück zu führen, sondern „works as designed“. Besonders gemein: Abgesehen vom Einsatz der Oracle Clusterware oder einer kompletten Grid-Installation gibt es ab 11g keine Möglichkeit, dies zu vermeiden (Details dazu finden sich hier).

Mit anderen Worten: Die Verwendung von Data Guard liegt völlig im Bereich der Enterprise Edition Lizenz – solange man keinen Switchover via dgmgrl durchführt. Man kann und darf sogar FSFO konfigurieren, da hierbei ausschließlich die (neue) Primär-Datenbank überlebt (die ehemalige primäre Datenbank ist im Normalfall ja „kaputt“, was Grund für den Failover war, und bleibt dies auch – sofern man auto-reinstate ausgeschaltet hat) – hier findet daher keine Lizenzverletzung statt. Ein für die Anwendungen transparenter Switchover ist jedoch nicht möglich.

Aber wie bekommt man nach einem Failover die Primärdatenbank zurück auf ihren angestammten Server? Natürlich könnte man einen weiteren Failover auslösen (indem man beispielsweise den smon Prozess killt). Dann muss jedoch die Standby DB noch einmal aufgebaut werden.Und auch wenn RMAN diesen Schritt relativ einfach macht, ist ein Failover immer mit einem gewissen Rest-Risiko verbunden, welches man nicht unbedingt hinnehmen möchte.

Also erledigen wir das Ganze auf dem „althergebrachten“ manuellen Weg:

Inhalt

Vorbereitung

  1. Idealerweise fährt man zuerst die Anwendung(en) herunter, um weitere Änderungen zu vermeiden
  2. Hat man Services eingerichtet: Sessions beenden lassen und die Services herunterfahren
    Auf der Primär-DB: exec dbms_service.disconnect_session('${service_name}',1), exec dbms_service.stop_service('${service_name}')
    (0: POST_TRANSACTION, 1: IMMEDIATE, 2: NO_REPLAY)
  3. Optional: Listener stoppen, um Neuanmeldungen zu vermeiden (wenn alle Anmeldungen ausschließlich über die Services stattfinden, kann dieser Schritt entfallen)
    Nur auf der (noch-) Primary: lsnrctl stop <listener>
  4. Prüfen, ob alle Anwender-Sessions auch wirklich verschwunden sind:
    select username,count(*) from v$session group by username order by 1;
  5. DG-Status mit dem Observer prüfen: dgmgrl sys@myPrim, show configuration
  6. Observer beenden (stop observer)
  7. Letzte Prüfungen auf Primary & Standby (Standby-Befehle sind hier auskommentiert; alle anderen Befehle sind ausschließlich für die Primär-DB gedacht. Dies ist ein optionaler Schritt für die Vorsichtigen; hat DG „Success“ statuiert, sollten diese (zumindest bei MaxAvailibility) selbiges lediglich bestätigen:
ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS';
alter system archive log current;
SELECT * FROM (
  SELECT sequence#, first_time, next_time, first_change#, next_change#, applied
    FROM v$archived_log
   WHERE dest_id=2
   ORDER BY sequence# desc
) where rownum <10;

-- mit der Standby vergleichen:
-- select sequence#,first_time,last_time,first_change#,last_change# from v$standby_log where sequence# > 0;
-- first_change# auf der Standby wird next_change# der Primary entsprechen
-- (und die sequence# einen Schritt voraus sein)

col dest_name for a50
select dest_name,status,error from v$archive_dest where dest_name='LOG_ARCHIVE_DEST_2';

col message for a120
select * from (
  select timestamp,message from v$dataguard_status order by timestamp desc
) where rownum < 10;

(ich habe hier bewusst alter system archive log current genutzt: anders als alter system switch logfile, welches sofort den SQL-Prompt zurück gibt und den LogSwitch Hintergrund-Prozessen überlässt, gibt dieses den SQL-Prompt erst nach getaner Arbeit zurück – man wird also informiert, wann der Logwechsel abgeschlossen ist)

Alternative Prüfmethode:

select status, gap_status from v$archive_dest_status where dest_id = 2;
-- erwartete Ausgabe: VALID, NO GAP
select name, value, datum_time from v$dataguard_stats;
-- kein "transport lag" oder "apply lag", "finish time" Zero
select switchover_status from v$database;
-- erwartete Ausgabe: TO STANDBY (evtl. SESSIONS ACTIVE) auf der Primary, TO PRIMARY (oder SESSIONS ACTIVE) auf der Standby

Commit the primary

Jetzt kann die Primär-DB in eine Standby umgewandelt werden. Während dieses Prozesses wird sie auch der noch-Standby ihre letzten Änderungen übermitteln:

alter database commit to switchover to standby;
shutdown immediate
startup nomount
alter database mount standby database;
alter database recover managed standby database disconnect from session;
select name,open_mode,database_role from v$database;

Hinweis: alter database commit to switchover to standby impliziert eigentlich bereits das folgende shutdown immediate (und beendet auch die aktuelle Anmeldung). Erhält man also bei letzterem Befehl die Fehlermeldung ORA-01012: not logged on, ist das hier „völlig normal“: einfach neu anmelden (conn / as sysdba) und mit dem nächsten Schritt fortfahren.

Managed Recovery sollte bei Verwendung des Brokers innerhalb etwa einer Minute automatisch starten. Wer es eilig hat (oder keinen Broker verwendet), setzt den Befehl händisch ab. Die erwartete Ausgabe des letzten Befehls ist: open_mode MOUNTED, database_role PHYSICAL STANDBY. Jetzt sind wir bereit für das…

Öffnen der Standby DB

alter database commit to switchover to primary;
shutdown immediate
startup
alter system register;
select name,open_mode,database_role from v$database;

Hier erwarten wir als Ausgabe: open_mode READ WRITE, database_role PRIMARY. Bei Verwendung von Services sollte der entsprechende Startup-Trigger für deren Start gesorgt – und diese sich auch beim Listener registriert haben. Dies prüft man nun auf der Maschine der neuen Primär-DB mit:

lsnrctl services <listener>

Alles grün? Dann folgen jetzt…

Abschließende Schritte

Ging alles glatt gilt es nun wieder zu starten, was eingangs beendet wurde:

  1. Den Applikations-spezifischen Listener auf der neuen Standby starten: lsnrctl start <listener>
  2. optional: Auf der neuen Standby alter system register absetzen und mit lsnrctl services <listener> prüfen, dass die Applikations-Services NICHT angezeigt werden (der zugehörige Startup-Trigger sollte dafür Sorge getragen haben)
  3. Per dgmgrl mit der Datenbank verbinden und den Status via show configuration prüfen
    Gibt es Fehler, sind diese nun zu beheben. Und wir erwarten Fehler: Beide DBs befinden sich im falschen Modus (DG war nicht in den Switchover involviert, seine Konfiguration spiegelt daher die ursprünglichen Rollen wider). Um dies zu beheben: edit configuration set protection mode as MaxPerformance;, disable fast_start failover;, remove configuration – dann die originale Konfiguration wieder herstellen, natürlich mit vertauschten Rollen.
  4. Observer starten:
    nohup dgmgrl sys@myPrim \
    "start observer file='/<path/to>/fsfo_${ORACLE_SID}.dat'" \
    | tee -a /<path/to>/observer_${ORACLE_SID}.log &
  5. Dem Oberver ein wenig Zeit geben, dann den Zustand mit einem finalen show configuration prüfen.

Damit sollte alles erledigt sein. Hat alles mehrfach „wie am Schnürchen“ geklappt, lassen sich einige Schritte sogar verskripten (was jeder gute faule Admin tun würde), damit es beim nächsten Mal auch noch schneller von der Hand geht.

Hat man sich diesen ganzen Stress angetan, möchte man nach einem etwaigen späteren Failover keine böse Überraschung erleben – und bei einem eventuellen automatischen Re-Instate die Standby im Modus READ ONLY WITH APPLY vorfinden. Also daran denken, die passende Vorkehrung zu treffen:

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverAutoReinstate=FALSE;
2020-11-18