Rolling Upgrade mit Logical Data Guard

Administratoren und Systembetreuer haben den Anspruch, geplante Ausfallzeiten in Datenbanksystemen auf ein Minimum zu reduzieren. Diese Funktionalität bietet das Feature „Rolling Upgrade“, welches Oracle mit der Version 10.1.0.3 eingeführt hat. Dieser Artikel beschreibt, wie man mit Hilfe eines Logical Data Guard, der nach einem Switchover die Rolle der Primärdatenbank annimmt, ein Upgrade mit minimaler Ausfallzeit durchführen kann (hier von Oracle 11.1.0.6 nach Oracle 11.1.0.7). Außerdem wird erläutert, welche Vorüberlegungen getroffen werden müssen.

Abb. 1: Ablauf des Rolling Upgrade. ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE KEY) COLUMNS; Abb. 2: Supplemental Logging einschalten. ALTER DATABASE STOP LOGICAL STANDBY APPLY; Abb. 3: Befehl zum Stoppen des SQL-Apply. ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Abb. 4: Befehl zum Starten des SQL-Apply. ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY; Abb. 5: Die Primärdatenbank kündigt die Bereitschaft für den Switchover an. ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY; Abb. 6: Vorbereitung der Standby-Datenbank auf den Switchover. Primary ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY; Standby ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; Abb. 7: Switchover und Rollentausch. ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY dblink; Abb. 8: Befehl zum Starten des SQL-Apply. Abb. 9: Ausgangssituation.

Konzept des Rolling Upgrade im Überblick

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:

1. Aufsetzen der Logischen Standby-Datenbank
2. Anhalten des SQL-Apply und Upgrade der Standby-Datenbank
3. Reaktivierung des SQL-Apply im Mischbetrieb (11.1.0.6 der Primärdatenbank und 11.1.0.7 der Standby-Datenbank)
4. Switchover: Nachdem alle Transaktionen erfolgreich an die logische Standby-Datenbank übertragen wurden und beide Datenbanken den gleichen Stand beinhalten, folgt der Switchover. Ab jetzt sind die Rollen der Datenbanken getauscht. Die alte Primärdatenbank besitzt die Rolle der Standby-Datenbank und die alte Standby-Datenbank agiert nun mit dem aktuellen Oracle-Release als neue Primärdatenbank.

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.

Voraussetzungen und Vorüberlegungen

Um ein Rolling Upgrade erfolgreich durchführen zu können, bedarf es einiger Voraussetzungen und Vorüberlegungen.

• Der Archivelog-Modus auf der Primärdatenbank muss aktiviert sein.
• Die Datenbankeinstellung Force Logging muss aktiviert sein, damit alle DML-Operationen in den Redolog-Dateien protokolliert werden.
• Damit alle Datensätze beim SQL-Apply eindeutig identifiziert werden können, bedarf es der Datenbankeinstellung Supplemental Logging (siehe Abbildung 2).
• Es muss untersucht werden, ob es Tabellen gibt, die keinen Primärschlüssel haben. Ein Primärschlüssel wird bei einer logischen Standby- Datenbank, anders als bei einer physikalischen Standby-Datenbank, zur Identifizierung eines Datensatzes genutzt. Besitzt eine Tabelle keinen Primärschlüssel, sollte ein solcher angelegt werden oder zumindest ein Unique-Spaltenindex mit NOT NULL-Wert in der Tabelle vorhanden sein, damit die Datensätze eindeutig identifiziert werden können. In der View dba_logstdby_not_unique kann diese Anforderung überprüft werden. Falls diese Anforderung nicht realisiert werden kann und kein Primary Key oder Unique Index für Tabellen angelegt werden kann, sollte das Supplemental Logging für alle Spalten aktiviert werden. Hierbei muss allerdings mit Performance-Einbußen gerechnet werden.
• Des Weiteren werden nicht alle Objekte durch das SQL-Apply in der logischen Standby-Datenbank nachgefahren. Nicht unterstützte Objekte und Datentypen werden in den Views DBA_LOGSTDBY_UNSUPPORTED und DBA_LOGSTDBY_SKIP ermittelt. Die Basistechnologie für das SQL-Apply ist der Oracle LogMiner. Dieser unterstützt jedoch nicht alle bei Oracle möglichen Datentypen. Diese Datentypen werden gegen Ende des Artikels im Abschnitt „Möglichkeiten und Grenzen“ aufgeführt.
• Der Data Guard Protection Mode muss entweder auf Maximum Performance oder Maxium Availability stehen. Dieses kann in der Spalte PROTECTION_ LEVEL in der Tabelle V$DATABASE überprüft werden.
• Die Parameter COMPATIBLE der Primärdatenbank und der Standby-Datenbank muss identisch sein (in unserem Beispiel 11.1.0.6).

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.

Implementierung des logischen Data Guard

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.

• Werden alle Objekte vollständig übertragen und/oder gibt es einen Workaround für Objekte, die nicht übertragen werden können?
• Sind PROTECTION_MODE und PROTECTION_LEVEL richtig gesetzt?
• Werden die Informationen von der Primärdatenbank korrekt an die Standby-Datenbank übertragen?
• Wurde die letzte Log-Datei erfolgreich übertragen?

Ablauf des Rolling Upgrade im Detail

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).

Möglichkeiten und Grenzen

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:

• BFILE
• Collections
  (VARRAYS und Nested Tables)
• Multimedia Datentypen
  (Spatial, Image und Oracle Text)
• ROWID und UROWID
• Benutzerdefinierte Datentypen
• LOBs gespeichert als SecureFiles
• XMLType gespeichert als Object Relational
• Binary XML

Des Weiteren werden keine Objekte vomUser SYS übertragen.

Fazit

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).

Seitenanfang

Seite drucken

Seite weiterempfehlen