Rolling Upgrade Verfahren mit Oracle Datenbank 11g

Transkript

1 Rolling Upgrade Verfahren mit Oracle Datenbank 11g Ralf Appelbaum TEAM GmbH Paderborn Schlüsselworte: Rolling, Upgrade, Update, Patch, One-off Patch, Interim Patch, Patch Set, CPU, PSU, Datenbank, 11g, Real Application Clusters, RAC, Clusterware, Automatic Storage Management, ASM, Fail Safe, Data Guard Einleitung Die im Datenbankumfeld möglichen Verfahren eine Minimale Downtime bei geplanten Wartungsarbeiten zu erreichen sind immer wieder Thema von Beratungsgesprächen beim Kunden und von Vorträgen auf Veranstaltungen wie z.b. der DOAG Konferenz. Dabei wird häufig das Database Rolling Upgrade mit Hilfe von Data Guard SQL Apply (Transient Logical Standby) in einem MAA Szenario mit zwei RAC Systemen präsentiert. Dies stellt sicher die optimalste aber auch die kostspieligste Konfiguration dar. Mit der 11g Datenbanksoftware sind aber weitere Möglichkeiten eines Rolling Upgrades bei einzelnen Softwarekomponenten hinzugefügt worden. So unterstützen Clusterware und ASM das rollierende Einspielen von Patches in einem RAC. Auch einzelne Patches der Datenbanksoftware sollen Rolling Upgrade oder Online Upgrade fähig sein. Somit sind zumindest teilweise Wartungsarbeiten ohne Downtime im RAC möglich auch wenn Data Guard nicht eingesetzt wird. Dies ist insbesondere dann interessant, wenn ein RAC in der Standard Edition lizensiert ist. Bei einer Lizensierung der Enterprise Edition können dedizierte Standby Server gespart und damit die Kosten für Data Guard reduziert werden, wenn der RAC ausreichend Ressourcen / Knoten zur Verfügung hat. Neben den verschiedenen Verfahren die Downtime bei geplanten Wartungsarbeiten zu minimieren soll hier dargestellt werden, an welchen Stellen der Verfahren Downtime in welchem Umfang etwa zu erwarten ist und von welchen Faktoren die Dauer der Downtime abhängt. Ich werde auch den Aufwand für Einrichten und Test der Verfahren darstellen, um die Antwort auf die Frage zu unterstützen: Wie viel Verfügbarkeit brauchen / wollen wir? Begriffsdefinitionen Im Kontext der Aktualisierung von Programmen bzw. dem Erneuern von Software geistern die verschiedenen Begriffe Release, Update, Upgrade, Patch, Hotfix und bei Oracle zusätzlich

2 die Begriffe Patch Set, One Of Patch, CPU, PSU herum. Diese gilt es zunächst voneinander abzugrenzen. Allgemeine Begriffe Laut Wikipedia (siehe bezeichnet ein Software- Update bzw. eine Programm-Aktualisierung eine neue Version eines Computerprogramms, die meist kostenlos ist und Programmmängel korrigiert oder kleinere Programmverbesserungen enthält. Diese Aktualisierungen werden auch als Service Release, Patch oder Hotfix bezeichnet. Die Hauptintention eines Updates ist es also, Fehler und Mängel der Basisversion eines Programms / einer Software zu beheben. Im Gegensatz dazu bezeichnet ein Software-Upgrade, laut Wikipedia (siehe die neue Version einer Basissoftware, die zusätzliche Funktionen enthält. Diese Upgrades sind durch eine Änderung der Versionsnummer im Produktnamen gekennzeichnet. Ein Upgrade stellt also eine neue Basisversion eines Programms / einer Software dar, dessen Hauptintention es ist, neue bzw. verbesserte Funktionalitäten bereit zu stellen. Da viele Anwendungen durchgehend, 24x7, verfügbar sein müssen, ist es notwendig, dass Programm-Aktualisierungen möglichst ohne oder nur mit sehr geringer Ausfallzeit / Stillstandzeit (Downtime) durchgeführt werden können. Bei einem normalen Update bzw. Upgrade steht die Anwendung so lange nicht zur Verfügung, wie die Programm-Aktualisierung benötigt. Daher sollten Software Updates bzw. Upgrades online oder rollierend durchgeführt werden können. Online Update bzw. Online Upgrade bezeichnet eine Methode, Software im laufenden Betrieb ohne Downtime zu aktualisieren. Die Software und damit auch die Anwendung ist durchgehend verfügbar! Im Umfeld einer Oracle DB Umgebung bedeutet dies, kein (betriebsnotwendiger) Teil der Oracle Software (Instanz, Listener, ASM, Clusterware usw.) muss gestoppt werden. Rolling Update bzw. Rolling Upgrade bezeichnet eine Methode Software ohne Downtime aus Sicht des Anwenders zu aktualisieren. Die Anwendung ist zwar durchgehend verfügbar aber einzelne Softwarekomponenten sind nacheinander, für den Anwender unbemerkt, nicht verfügbar. Bei einer Oracle DB Umgebung müssen also einzelne (betriebsnotwendige) Teile der Oracle Software (Instanz, Listener, ASM, Clusterware usw.) nacheinander zur Aktualisierung gestoppt werden. Dies ist also nur im Hochverfügbarkeitsszenario möglich, in dem alle (betriebsnotwendige) Teile der Oracle Software mehrfach alternativ vorhanden sein müssen. Somit erfordert ein Rolling Update bzw. ein Rolling Upgrade den Oracle Real Application Cluster (RAC)! Auch bei Data Guard (Standby DB) und Fail Safe (Failover Cluster unter Windows) spricht man von Rolling Update / Rolling Upgrade. Hier wird aber nur eine Minimierung der Downtime erreicht.

3 Upgrade und Update Arten bei Oracle Die Hilfe in My Oracle Support unter Patches & Updates definiert einen Patch als ein Software-Update das ein einzelnes spezifisches Problem adressiert / behebt. Patches sollen nur eingespielt werden, wenn Symptome des Problems in der Anwendung erkannt wurden. Ein Patch Set ist laut Hilfe dagegen eine Sammlung von einzelnen Software-Updates. Patch Sets sollten bevorzugt verwendet werden. Im Dokument My Oracle Support Doc ID: wird konkreter gesagt, dass einzelne Patches auch One-off Patches oder Interim Patches genannt nicht voll getestet sind und daher zuvor in einer eigenen Testumgebung geprüft werden sollten. Patch Sets dagegen sind voll getestete und integrierte Programm-Aktualisierungen, die keine neue Funktionalität, sondern nur Fehlerkorrekturen beinhalten bzw. Mängel beheben. Mit Patch Sets erhöht sich mitunter die Versionsnummer der Oracle DB Software an der 4ten Stelle. Tatsächlich sind in Patch Sets aber auch erkennbare Funktionsänderungen enthalten (z.b. beim Patch Set von oder früher auf ), die bei näherer Betrachtung aber eine Vervollständigung neuer Funktionen der Basisversion darstellen. Bei Oracle gibt es zwei Arten an Sammlungen von Patches, die regelmäßig im Quartalsrhythmus erscheinen, jeweils an dem Dienstag der am nächsten zum 15ten der Monate Januar, April, Juli und Oktober liegt. Critical Patch Updates (CPU) sind eine Sammlung von Patches zu sicherheitskritischen Schwachstellen der Oracle DB Software. Sie enthalten auch Patches, die nicht die Sicherheit betreffen, wenn sie als Voraussetzung für ein Sicherheitspatch erforderlich sind. CPUs werden auf der letzten Patch Set Version (Base Release, z.b ) eingespielt und sind kumulativ. Ab Version werden sie als so genannte n-apply CPU herausgegeben, d.h. sie bestehen aus einer Anzahl kleinerer Patch-Sammlungen (molecule), die auch differenziert eingespielt werden können. Patch Set Updates (PSU) sind recht neu, es gibt sie seit Juli 2009 für und seit Oktober 2009 für Sie sind kumulativ und beinhalten die Patches des zur selben Zeit erscheinenden CPUs und zusätzlich von Oracle empfohlene Patches zu Problemen, die häufig zu Anfragen im Support geführt haben. Mit den PSUs wird die Versionsnummer der Oracle DB Software an der 5ten Stelle erhöht (Ausnahme bei ). Wurde einmal ein PSU eingespielt, dürfen auf diese Version nur noch weitere PSUs und keine CPUs mehr eingespielt werden. Bezugsquellen von Oracle Versionen und Updates Im Oracle Technology Network (OTN) findet sich unter die gesamte Palette der Oracle Software zu Test-, Entwicklungs- und Prototyping-Zwecken zum Download.

4 Bei Oracle E-Delivery zu erreichen über erhält man ebenfalls die gesamte Palette der Oracle Software hier aber als lizensierte bzw. zu lizensierende Version. Tatsächlich unterscheiden sich die Versionen nicht von denen aus dem OTN, nur die Downloadverpackung (ZIP-Files) sind teilweise anders. In einem ersten Schritt wird hier eine Anfrage zur Prüfung der Downloadberechtigung (Exportbedingungen) erstellt. Erst nach einer Bestätigungsmail kann man in einem Zeitraum von 24 Std. tatsächlich downloaden. In My Oracle Support (früher Metalink) zu erreichen über kann man als Support Kunde von Oracle unter dem Punkt Patches & Updates alle Patches, Patch Sets, CPUs und PSUs zu lizensierter Oracle Software herunter laden. Wichtig für die Suche nach CPUs und PSUs unter Patches & Updates, diese findet man nicht unter Patch Set sondern als Patch. Online oder Rolling Update / Upgrade möglich? Im Readme eines jeden Patches sollte aufgeführt sein, ob dieser online eingespielt werden kann oder nicht. Weiterhin kann der Installationsdokumentation auch entnommen werden ob alternativ ein rollierendes Einspielen möglich ist. Da die Stellen aber nicht immer sofort zu finden sind, gibt es noch die folgenden weiteren Möglichkeiten. Um festzustellen ob ein heruntergeladener Patch online, also ohne Downtime der Software, eingespielt werden kann, kann man im entpackten Patch in der Datei..\<patch_id>\etc\config\inventory prüfen ob folgender Eintrag vorhanden ist: <instance_shutdown>true</instance_shutdown> wenn ja, dann ist eine Downtime erforderlich wenn nein, dann ist keine Downtime erforderlich (siehe My Oracle Support Doc ID: ) Alternativ kann man im Patchpfad auch die Ausgabe des opatch Utility prüfen: opatch query is_online_patch Um festzustellen ob ein heruntergeladener Patch rollierend im RAC, also ohne Ausfall aus Anwendersicht, eingespielt werden kann, kann man im entpackten Patch in der Datei..\<patch_id>\etc\config\inventory prüfen ob folgender Eintrag vorhanden ist: <online_rac_installable>true</online_rac_installable> wenn ja, dann ist der Patch Rolling Update fähig wenn nein, dann ist der Patch nicht Rolling Update fähig (siehe My Oracle Support Doc ID: ) Alternativ kann man im Patchpfad auch die Ausgabe des opatch Utility prüfen: opatch query is_rolling_patch

5 Rolling Upgrades und Patches mit Fail Safe Oracle Fail Safe (FS) ist eine Ergänzung zum Microsoft Cluster Server (MSCS). Dabei handelt es sich um einen Failover Cluster. Dieser ermöglich ein Upgrade oder Patchen von - Oracle Fail Safe Software - Oracle Datenbank und DB Software - andere Oracle Software rollierend für einzelne Knoten. Im Idealfall beträgt dabei die Ausfallzeiten weniger als 1 Minute für das Verschieben einer Ressourcengruppe auf einen anderen Knoten. Abb. 1: Oracle Fail Safe Manager Upgrade der Oracle Fail Safe Software Ein Upgrade der Fail Safe Software erfolgt in folgenden Schritten: 1. Failback-Modus aller Ressourcengruppen deaktivieren 2. Ressourcengruppen auf anderen Knoten verschieben 3. Oracle Fail Safe Software deinstallieren / neu installieren 4. Knoten neustarten 5. Schritte 2 4 für die übrigen Knoten durchführen 6. Verify Cluster durchführen und prüfen 7. Failback-Modus der Ressourcengruppen wieder aktivieren 8. Ressourcengruppen auf ihre bevorzugten Knoten verschieben 9. Verify Group Operation auf allen Ressourcengruppen durchführen

6 Mit diesem Upgrade sind je Ressourcengruppen zwei Ausfälle von wenigen Minuten verbunden. Die genaue Ausfallzeit ist abhängig von der Anzahl der Ressourcen in einer Gruppe. Ein Upgrade anderer, nicht Datenbankbezogener Oracle Software erfolgt äquivalent (z.b. AS). Patch der Oracle DB Software (mit FS) Das Patchen der DB Software erfordert die folgenden Schritte: 1. Failback-Modus aller Ressourcengruppen deaktivieren 2. Ressourcengruppen auf anderen Knoten verschieben 3. alle Oracle und Cluster Services auf dem Knoten beenden 4. Oracle DB Software Patch installieren 5. Cluster Services auf dem Knoten starten (ggf. Knoten neustarten) 6. alle Ressourcengruppen zurück schieben 7. Patch der DB durchführen (SQL Scripte ausführen) 8. Schritte 3 5 für die übrigen Knoten durchführen 9. Verify Cluster durchführen und prüfen 10. Failback-Modus der Ressourcengruppen wieder aktivieren 11. Ressourcengruppen auf ihre bevorzugten Knoten verschieben Auch mit diesem Upgrade sind je Ressourcengruppen zwei Ausfälle verbunden. Die Dauer des ersten Ausfalls (Schritt 2) ist nur abhängig von der Anzahl der Ressourcen in der Gruppe. Die Dauer des zweiten Ausfalls (Schritt 6) ist bei einer Datenbank zum Einen abhängig von der Anzahl der Ressourcen in der Gruppe und zum Anderen von der Zeit, die zum Ausführen der Patch Scripte (wenige Minuten) erforderlich ist. Upgrade der Oracle DB Software (mit FS) Die Schritte beim Upgrade der Oracle DB Software sind: 1. neue Datenbank Software auf allen Knoten installieren (in separates ORACLE_HOME) 2. Datenbank von Ressourcengruppe entfernen 3. Datenbank upgraden (SQL Scripte im Migrate Modus ausführen) 4. Verify Standalone Database durchführen 5. Datenbank wieder zu Ressourcengruppe hinzufügen Die Zeit des Ausfalls ist in diesem Fall viel größer als in den vorgenannten Fällen. Die Downtime zum Konfigurieren der Ressourcengruppen mit Failover-Test und Ausführen der DB Patch Scripte beträgt viele Minuten bis Stunde(n).

7 Rolling Upgrades und Patches mit Data Guard Ab Version kann ein Update/Upgrade der Oracle Datenbank Software mit Data Guard (DG) rollierend erfolgen. Das Einspielen von Patches und Patch Sets und die Migration auf eine neue Datenbankversion erfolgt dabei mit minimaler Downtime, z.b. - von Patch Set Release n auf das folgende Patchset Release (n+1) - vom Maintenace Release 10.1 nach 10.2 Darüber hinaus bietet ein Rolling Upgrade mit Data Guard folgende Vorteile: - Das Upgrade bzw. die aktualisierte Datenbank kann ohne - Einfluss auf die produktive Datenbank getestet werden. - Es entsteht keine zusätzliche Downtime für das - Recompilieren von PL/SQL der Anwendung. Upgrade der Oracle DB Software (mit DG) Die Schritte eines Rolling Upgrade mit Data Guard sind: 1. Aufsetzen einer Logical Standby Datenbank 2. SQL Apply stoppen, Upgrade der Logical Standby Datenbank 3. Wiederaufnehmen des SQL Apply 4. Monitoren der Ereignisse auf der Upgegradeten Standby DB 5. Switchover auf die Standby Datenbank durchführen 6. Upgrade der vormaligen Primärdatenbank durchführen 7. Wiederaufnehmen des SQL Apply 8. Optional, COMPATIBLE Instanz Parameter auf beiden Datenbanken anheben 9. Monitoren der Ereignisse auf der upgegradeten neuen Standby Datenbank 10. Optional, erneuter Switchover auf die ursprüngliche Primärdatenbank Die Voraussetzungen für ein Rolling Upgrade mit DG sind: - Der Data Guard Protektion Modus muss auf maximum availability oder maximum performance stehen. - Die Log Archive Destination (LOG_ARCHIVE_DEST_n) zur Standby Datenbank darf nicht mandantory sein. Die Primärdatenbank kann also während des Upgrades der Standby Datenbank weiter arbeiten. - Der COMPATIBLE Instanz Parameter beider Datenbanken bzw. Instanzen muss identisch auf die alte Version der Primärdatenbank gesetzt sein. Rolling Upgrades und Patches mit Oracle Real Application Cluster Ab Oracle Version 10g werden rollierende Upgrades und Patches zumindest teilweise unterstütz. Ab Oracle 11g sind Patches zu Clusterware und ASM grundsätzlich Rolling Upgrade fähig. Auch PSUs sollen im RAC Rolling Upgrade fähig sein. Neben dem Patch der Oracle Software unterstützt RAC auch Upgrades von: - Betriebssystem - Hardware

8 Der Ablauf beim Rolling Upgrade im RAC wird in folgender Abbildung veranschaulicht. Abb. 2: Rolling Upgrades und Patches mit RAC Bei Patches, die im RAC nicht "Rolling Update"-fähig sind, ist ein Totalausfall des RAC mit folgenden Schritten erforderlich: 1. Alle Instanzen (auch ASM) stoppen 2. Clusterware stoppen 3. Patch mit Hilfe des Universal Installer oder Patch auf allen Knoten installieren 4. Clusterware starten 5. ASM starten 6. In einer der Instanzen den Parameter CLUSTER_DATABASE auf FALSE setzen 7. Nur diese eine Instanz starten 8. DB-Upgrade durchführen 9. Instanz stoppen 10. Parameter CLUSTER_DATABASE wieder auf TRUE setzen 11. Alle Instanzen starten Getestete Patches (im RAC) Die folgende Tabelle listet die getesteten Patches auf. Alle wurden im RAC auf ihre Rolling Update Fähigkeit hin getestet. Patch Typ von zu installieren rolling / Filename Nummer auf online fähig CPU Juli DB / ASM p _111060_linux.zip Bundle Patch April 2009 CRS p _111070_linux-x86.zip

9 Patch Nummer Typ von zu installieren auf PSU Oktober DB / ASM X CPU Oktober DB / ASM Oktober Opatch rolling / online fähig ja Filename p _111070_linux-x86.zip p _111070_linux-x86.zip p _111000_generic.zip Anmerkung: Zum Zeitpunkt der Fertigstellung dieses Dokuments sind noch nicht alle Tests durchgeführt worden. Die Ergebnisse können in einer späteren Version des Dokuments oder bei TEAM erfahren werden. Quellen / Literatur Quellen / Literatur zu Fail Safe: Oracle Fail Safe Installation Guide Release for Microsoft Windows Anhang A: Rolling Upgrades and Patches Quellen / Literatur zu Data Guard: White Paper: Database Rolling Upgrade Using Data Guard SQL Apply Oracle Database 11g and 10gR2 White Paper: Database Rolling Upgrade Using Transient Logical Standby: Oracle Data Guard 11g My Oracle Support: Note g Rolling Upgrades with Logical Standby OTN: SQL Apply Rolling Upgrade Best Practices Quellen / Literatur zu Real Application Clusters: Oracle Data Sheet: Database Rolling Patch Updates with Real Application Clusters Howto: Oracle Clusterware (formerly CRS) Rolling Upgrades My Oracle Support: Note

10 White Paper: Best Practices for Optimizing Availability During Planned Maintenance Using Oracle Clusterware and Oracle Real Application Clusters RAC.pdf Kontaktadresse: Ralf Appelbaum TEAM Partner für Technologie und angewandte Methoden der Informationsverarbeitung GmbH Hermann-Löns-Str Paderborn Telefon: +49 (0)5254 / Fax: +49 (0)5254 / ra@team-pb.de Internet: