Autoupgrade - Organisatorisches
- Christian Floreck
- 28. Juli 2023
- 4 Min. Lesezeit
Autoupgrade - Das Schweizer Taschenmesser Organisatorisches
Dieser Beitrag nicht technisch. Aus meiner Sicht heißt dies aber nicht, dass der weniger relevant ist. Als Datenbank Administrator muss man - so meine Erfahrung - die Brille des "IT-Nerds" absetzen und organisatorisches berücksichtigen. Dieser bewusst launige Blogbeitrag beschäftigt sich mit dieser Thematik.
Ich komme zu einem Kunden mit der Aufgabenstellung einen Upgrade einer 12er DB eine 19er Datenbank durchzuführen. Ich erhalte Zugangsausweis, Anmeldedaten, man zeigt mir mein Büro, wo die Kaffeemaschine steht. Eine kurze Besprechung im Tenor: "Dann mal los, Upgrades sind die Sache für die IT-Nerds im Hochsicherheitsbereich!" Ich schüttle den Kopf. "Nein, Upgrades sind die Sache aller Fachbereiche." Erstaunte Blicke.... "Wieso denn das?" Ich erläutere meine Sichtweise: "Ein Upgrade ist sehr umfangreiches Projekt. Und Projekte können nur dann erfolgreich abgeschlossen werden, wenn alle betroffenen Bereiche offen und regelmäßig mit einander kommunizieren." Zustimmendes Kopfnicken. Aber wer bittschön ist "betroffen"? "Zuerst einmal die Anwender, die auf die Datenbank zugreifen." Wieder Kopfnicken. "Downtime und so, klar!" Ich schüttle den Kopf.
"Nicht nur. Bevor man an die Produktivsysteme geht, müssen Tests durchgeführt werden. Und diese Tests betreffen die Anwendungen und können also nur von den Anwendern durchgeführt werden.
Welche Funktionen der Software müssen getestet werden (Dialogsystem, Batchläufe, etc.)
Laufen diese ohne Fehler?
Laufen sie ohne Performance Probleme?
Auch die Definition, welche Abläufe getestet werden müssen, können nur die Anwender durchführen, eben weil nur sie die Anwendung kennen."
Erstaunte Blicke "Stimmt!"
Ich komme in Fahrt: "Getestet werden muss nicht nur ein erfolgreiche Migration. Getestet werden muss auch ein Rollback, also das Vorgehen bei einem Fehlschlag des Upgrades. Auch über eins müssen wir uns klar sein. Wenn die Anwender testen ist das extrem wichtig, denn sie stellen sicher dass der Betrieb nach dem Upgrade sauber läuft. Soll heißen: Tests sind nichts was man irgendwann mal macht, wenn gerade Zeit ist."
Ich merke: Man wird zunehmend hellhörig. Ich fahre fort: "Natürlich muss auch die Entwicklung intensiv eingebunden werden. Es ist möglich, dass mit dem Releasewechsel Oracle Features nicht mehr verfügbar sind, oder neue interessante Features bereitgestellt werden. Je nach dem wie schnell der Zugriff auf die Entwicklung möglich ist, kann dies ein signifikanter Zeitfaktor sein. Bei einer externen Entwicklung können auch Kosten entstehen." Nach einem Schluck Kaffee geht es weiter: "Zudem wird das Controlling sicher gerne wissen, welche Kosten entstehen. Zum Beispiel weil die Anwender "testen", die Software angepasst werden muss, etc." Kopfnicken, das Controlling ist da immer sehr interessiert. Ich schlage vor: "Wir müssen als erstes zusammen einen Projektplan erstellen, Wer kümmert sich um was, wie lange brauchen wir für die einzelnen Schritte. Die Ansprechpartner müssen allen bekannt sein. Wir brauchen regelmäßig Meetings zu festen Zeitpunkten, Wenn alle nur sagen "Alles ok!" ist das Meeting in ein paar Minuten beendet. 'Wir treffen uns bei Problemen' ist - so meine Erfahrung - ein schlechter Ansatz,"" Wieder Kopfnicken und ich ahne, was gedacht wird. "Die Projektleitung sollte idealerweise in den Händen einer "neutralen" Person liegen. Zumal Projektleitung ja auch Zeit kostet und diese fehlt dann bei den eigentlichen Tätigkeiten." Wieder ein Schluck Kaffee, dann mein Mantra: "Ganz wichtig ist, dass wir offen kommunizieren. Wenn etwas unverständlich ist, darf und muss nachgefragt werden. Wenn mögliche Probleme auftauchen, müssen diese auf den Tisch gebracht werden."
Ich habe die Erfahrung gemacht, dass diese Aspekte oft nicht gesehen wurden - was auch völlig verständlich ist.
Bei den folgenden Besprechungen geht es manchmal auch heftig zur Sache.
Wenn Ihr merkt: Das läuft aus dem Ruder - sucht Euch einen Moderator, holt Euch Tips von Kollegen, wie Ihr die Lage entspannen könnt.
Regelmäßige Datenbank Upgrades sind eine Pflicht für jeden Datenbank Administrator. Eine ungeliebte Pflicht, zugegebenermaßen, Die Schritte sind "im Prinzip" transparent, sicherlich keine "Raketentechnik". Aber die Arbeiten sind zeitaufwendig, erforderten permanente Aufmerksamkeit und bieten viel Spielraum für kleine "Fehler." In Umgebungen mit vielen Datenbanken müssen die gleichen Schritte für jede Datenbank immer wieder wiederholt werden, sicherlich keine effektive
Herangehensweise.
Mit dem Autoupgrade Tool bietet Oracle nun ein Möglichkeit, Upgrades komfortabel und schnell durchzuführen.
Insbesondere in großen und komplexen (bis hin zu Data Guard und RAC) Umfeldern spielt autoupgrade seine Vorteile aus.
Was aus meiner Sicht besonders positiv ist:
Ich habe - nach Tests - einen zuverlässig laufenden Ablauf - und gehe entspannter an die Arbeit.
Durch die Automatisierung des Upgrade Ablaufes kann ich mich auf eventuell auftretende Probleme konzentrieren,
Die Installation:
Die Installation von autoupgrade ist denkbar einfach: Bei Oracle Support anmelden, nach Doc ID 2485457.1 suchen, das Tool herunterladen und auf dem Datenbank Server in einem dedizierten Verzeichnis bereitstellen.
Wichtig: Immer die aktuelle Version herunterladen! Denn mit jeder neuen Version werden nicht nur Fehler bereinigt, es kommen immer wieder neue nützliche Funktionen hinzu.
Das autoupgrade Tool benötigt Java Version 8. Diese befindet sich im Oracle Home Verzeichnis. <ORACLE_HOME>/jdk/bin
Wichtig: Wenn Ihr eine 11er Datenbank upgraden wollt, müsst Ihr das Java Binary aus der 19er Home starten, da im 11er System kein 8er Java vorhanden ist.
Prüfen könnt Ihr die Version mit dem Befehl java -version. Am einfachsten ist des den Pfad zum Java in den Suchpfad einbindet.
java -version |
java version "1.8.0_331" Java(TM) SE Runtime Environment (build 1.8.0_331-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.331-b09, mixed mode) |
Die Version des installierten autoupgrade Tools Ihr mit dem Befehl java -jar autoupgrade.jar -version prüfen.
java -jar autoupgrade.jar -version |
build.version 22.3.220503 build.date 2022/05/03 11:55:20 -0400 build.hash 9e84e228 build.hash_date 2022/05/03 11:37:00 -0400 build.supported_target_versions 12.2,18,19,21 build.type production |
Damit ist die Installation des Tools abgeschlossen.
Ablauf eines Upgrades:
Der Ablauf eines Upgrades ist identisch mit einer manuellen Migration
Überprüfung der Quelldatenbank auf "Kompatiblität" für ein Upgrade (Ausreichende Prozesse, Größe der Tablespaces, nicht mehr unterstützte Features)
Durchführung der notwendigen Änderungen
Durchführung des Upgrades
Autoupgrade bezeichnet diese Schritte als analyze, fixups und upgrade. Diese drei Schritte werden im Schritt deploy zusammengefasst. Beim Schritt "upgrade" ist zu beachten, dass die Datenbank im Upgrade Modus sein muss. Diese Option wurde früher bei serverübergreifende Migrationen verwendet. Mittlerweile ist aus meiner Sicht nicht mehr nötig, da dieses Aufgabenstellung über Datenbank Links komfortabel abgedeckt werden kann.
Der genaue Ablauf von 3 Upgrade Pfaden wird in diesen Blogs beschrieben
Scenario 1 Arbeit im Umfeld einer Standard Edition Upgrade einer nonPDB (12c) in eine 19c PDB
Senario 2 Upgrade eine PDB (18c) in PDB (19c)
Sencario 3 Migration einer nonPDB (19c) in eine PDB (19c)
Was sonst zu beachten ist Was ist im Data Guard Umfeld zu beachten Wie kann der Upgrade von PDBs beschleunigt werden Wie kann der Upgrade von RAC System Systemen beschleunigt werden?
Nun viel Spaß beim Lesen
Bei Fragen schreib mich einfach an: oracle.wasistwas@outlook.com
Comments