Autoupgrade - DataGuard

Autoupgrade - Das Schweizer Taschenmesser

Neues beim Data Guard

---

Der Ablauf beim Upgrade bei Data Guard hat sich geändert

Die unangenehme Nachricht zuerst: Das autoupgrade Tool unterstützt nach wie vor nicht den kompletten Upgrade von Data Guard Systemen.

Aber dies bei leibe nicht so schlimm, wie es klingt.

---

Was hat sich denn geändert ?

Bisher empfahl Oracle zur Sicherstellung eines Rollbacks die Replikation von Primary zur Standby zu deaktivieren.

Nun heißt die Empfehlung: Sicherstellen des Rollbacks durch einen .garanteed Restore Point auf der Standby. Die Begründung ist schlüssig. Ein garanteed Restore Point ist eine sichere Technik für Fallbacks. Deaktiviert man die Replikation verzichtet man in diesem Moment auf die Ausfallsicherheit, die der Data Guard bereitstellt - es entsteht ein Gap, den das Data Guard System aufholen muss. Allerdings sind beim Setzen von garanteed Restore Points auf der Standby zwei Dinge zu beachten: Man könnte vermuten, dass der Data Guard auch das Setzen eines garanteed Restore Points von der Primary auf die Standby repliziert. Dies ist aber nicht der Fall. Auf der Standby entsteht ein "normaler" Restorepoint - und dieser wird beim Volllaufen der FRA überschrieben. Des weiteren muss vor dem Erstellen des garanteed Restore Points der apply Prozess auf der Standby gestoppt und nach dem Setzen des garanteed Restore Points wieder aktiviert werden.

In der Praxis sieht es also so aus:

Die Primary Instance ist über den Alias PRIMARY_DB zu erreichen, die Standby Datenbank über den Alias STANDBY_DB. Wichtig: Man sollte immer über das dgmgrl Interface arbeiten. Dieses übernimmt auch beim Setup des Data Guard die komplette Konfiguration der Datenbanken. Auch beim Betrieb macht es das Arbeiten einfacher und sicherer.

Schritt 1 - deaktieren des Apply Prozesses auf der Standby

dgmgrl sys@PRIMARY_DB edit database ‘STANDBY_DB' set state='APPLY-OFF';

exit:

Schritt 2 Setzen eins garanteed Restore Points auf der Standby Datenbank

sqlplus / as sysdba

create restore point standby_rp guarantee flashback database;

exit;

Schritt 3 - aktieren des Apply Prozesses auf der Standby

dgmgrl sys@PRIMARY_DB edit database ‘STANDBY_DB' set state='APPLY-on';

exit;

Ich empfehle den Data Guard in einer GRID Infrastructure laufen zu lassen.

Dies ist nicht zwingend vorgeschrieben, macht aber den Betrieb des Data Guard einfacher (z.B. switchover / failover).

Schritt 4 - Stoppen der Datenbank auf der Standby

srvctl stop database -db <DB_UNIQUE_NAME>

Schritt 5 - Ändern des Oracle Homes

srvctl modify database -db <DB_UNIQUE_NAME> -oraclehome <HOME_19>

Schritt 6 - Starten der Datenbank in den mount modus (Read Only wäre (Active Data Guard und kostenpflichtig)

​srvctl start database -db <DB_UNIQUE_NAME> -o mount

Damit sind die Arbeiten auf der Standby abgeschlossen. Schritt 7 - Der Upgrade der Primary Datenbank Dieser wird wie in den vorherigen Kapiteln beschrieben, mittels autoupgrade durchgeführt. Die Änderungen in der Datenbank werden durch den DataGuard repliziert. Schritt 8 - Tests

Schritt 9 - Löschen der Restorepoints (auf Primary und Standby)

Ermitteln der Restore Points

select name, to_char( time,'dd-mm-yy hh24:mi:ss'), guarantee_flashback_database from v$restore_point where guarantee_flashback_database = 'YES';

Löschen der Restorepoints

drop restore point <RESTOREPOINT_NAME>;

Bei Fragen schreib mich einfach an: oracle.wasistwas@outlook.com

---