ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE KEY) COLUMNS;
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
Primary ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY; Standby ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY dblink;
Zu Beginn des Artikels geben wir Ihnen einen groben Überblick über das Konzept eines Rolling Upgrade. Anschließend beleuchten wir die Voraussetzungen, die dafür gegeben sein müssen und gehen danach auf den detaillierten Ablauf ein.
Als Basis für ein Rolling Upgrade benötigt man zusätzlich zur Primärdatenbank eine logische Standby-Datenbank. Zum Abgleich der beiden Datenbestände werden alle Änderungen in der Primärdatenbank mit Hilfe des SQLApply an die Standby-Datenbank übertragen. In Abbildung 1 wird der Ablauf des Rolling Upgrade in vier Teilschritten dargestellt:
Nach dem Switchover ist der SQL-Apply noch nicht aktiviert. Somit können wir analog zum vorherigen Upgrade die neue Standby-Datenbank (die alte Primärdatenbank mit dem alten Oracle Release) aktualisieren. Dieser Vorgang beeinflusst den Betrieb der Primärdatenbank nicht. Der Anwender nimmt somit nur die Ausfallzeit während des Switchover wahr.
Um ein Rolling Upgrade erfolgreich durchführen zu können, bedarf es einiger Voraussetzungen und Vorüberlegungen.
Nach dem groben Überblick und dem Klären der nötigen Voraussetzungen für ein Rolling Upgrade, gehen wir nun tiefer ins Detail und stellen Ihnen die einzelnen Schritte ausführlich vor.
Wie anfangs bereits erwähnt, benötigt man eine logische Standby-Datenbank, um überhaupt ein Rolling Upgrade durchführen zu können. Der erste Schritt zum Erzeugen einer logischen Standby-Datenbank ist das Anlegen einer physikalischen Standby-Datenbank. Aus der physikalischen Standby-Datenbank wird dann im weiteren Verlauf eine logische Standby-Datenbank. Bevor nun das Rolling Upgrade durchgeführt werden kann, muss die logische Standby-Datenbank noch einmal auf ihre Konfiguration hin überprüft werden.
Die Ausgangssituation ist Schritt 1 (siehe Abbildung 1). Nachdem die logische Standby-Datenbank erfolgreich implementiert ist, muss der SQL-Apply gestoppt werden (siehe Abbildung 3). Die Standby-Datenbank wird heruntergefahren und das Upgrade wird auf Oracle 11.1.0.7 anhand der Oracle Patch-Dokumentation durchgeführt.
Danach wird der SQL-Apply wieder gestartet (siehe Abbildung. 4). Zu diesem Zeitpunkt arbeiten beide Datenbanken mit unterschiedlichen Oracle-Versionen.
Mit Hilfe der View DBA_LOGSTDBY_EVENTS lässt sich überprüfen, ob der Ablauf innerhalb der logischen Standby-Datenbank fehlerfrei ist. Ein fehlerfreier Ablauf wird als letzter Eintrag in der View DBA_LOGSTDBY_EVENTS wie folgt dokumentiert: ORA-16111: log mining and apply setting up. Im nächsten Schritt folgt der Switchover bzw. das eigentliche Rolling Upgrade. Als erstes kündigt die Produktionsdatenbank ihre Bereitschaft zum Switchover an (siehe Abbildung 5). In der Spalte SWITCHOVER_STATUS in der View V$DATABASE prüfen wir auf der Standby-Datenbank den Switchover Status der Standby-Datenbank.
Im zweiten Schritt wird die Standby-Datenbank auf den Switchover vorbereitet (siehe Abbildung 6).
Daraufhin kann der eigentliche Switchover sowie der Rollentausch beider Datenbanken durchgeführt werden (siehe Abbildung 7).
Nach dem Upgrade der nun neuen Standby-Datenbank kann der SQL-Apply mit Hilfe eines Datenbank-Links wieder gestartet werden (siehe Abbildung 8 und 9).
Die Benutzung des logischen Data Guard bringt viele Möglichkeiten mit sich, beinhaltet aber auch Einschränkungen. Der entscheidende Vorteil ist, dass die Ausfallzeit während eines Upgrades einer Datenbank auf ein Minimum reduziert wird. Mit keinem anderen Verfahren von Oracle ist es möglich, diese minimale Ausfallzeit zu erreichen.
Die größte Einschränkung des logischen Data Guard ist, dass nicht alle Datentypen unterstützt werden. Aufgrund des SQLApply, der den Oracle LogMiner benutzt, werden nicht alle Datentypen übertragen, da der LogMiner nicht in der Lage ist, komplexere Datentypen nachzubilden.
Folgende Datentypen können in Oracle 11gR1 nicht übertragen werden:
Des Weiteren werden keine Objekte vomUser SYS übertragen.
Die Ausfallzeit minimiert sich bei der Anwendung eines Rolling Upgrades auf die Rollentausch- bzw. Switchover-Zeiten. Insgesamt kann als Ausfallzeit für das Switchover eine Zeitspanne von zwei Minuten eingerechnet werden, wenn alle Vorkehrungen getroffen werden. Das Upgrade-Verfahren der Standby-Datenbank läuft im Hintergrund ab und hat keinen Einfluss auf dem Betrieb der Primärdatenbank. Für Sie in der Praxis hat das vor allem den Nutzen, dass alle Anwender und Anwendungen nach nur sehr kurzer Zeit wieder produktiv auf die Datenbank zugreifen können. Dies ist mit kaum einem anderen Verfahren möglich.
Sie wollen mehr über das Rolling Upgrade oder andere Migrations- und Upgrade-Verfahren erfahren? Dann besuchen Sie das 3-tägige ORDIX Seminar „Oracle Migration und Patching“ [2].
Vanessa Prior (info@ordix.de).
