Oracle Datenbankupgrades mit autoupgrade.jar - Anleitung zum Überspringen von Fixups
Autoupgrade-Tool
Was ist das überhaupt?
Das Autoupgrade-Tool wird in Zukunft immer wichtiger, um Oracle Datenbanken auf neuere Releases (18c, 19c, 20c, ...) upzugraden. Mike Dietrich hat u.a. an der DOAG Konferenz 2019 in seinem Vortrag mitgeteilt, dass das Autoupgrade-Tool auch für die Exadata DAS Instrument sein wird, um Datenbanken upzugraden.
Es handelt sich beim Autoupgrade-Tool um ein spezielles jar File. Dieses wird zwar bereits mit der Datenbank jeweils mit ausgeliefert, allerdings wird das Tool sehr schnell weiter entwickelt und hat sich in den letzten 12 Monaten rasant verbessert. Außerdem werden Fehler, die das Tool selbst betreffen, innerhalb kürzester Zeit behoben, so dass man beinahe alle 3-4 Wochen unter support.oracle.com eine aktuelle Version herunterladen kann - und dieses auch unbedingt sollte. Eine Verwendung der mit den Datenbanken mitgelieferten Versionen ist nicht empfohlen.
Dieses Jar-File beinhaltet die Möglichkeit, mit einer sehr einfachen Konfiguration Datenbanken von einem Release auf ein neueres Release upzugraden, es macht also die Arbeit des Datenbankadministrators einfacher. Für das eigentliche Upgrade werden allerdings die unter $ORACLE_HOME/rdbms/admin bekannten Skripte verwendet. Das Tool selbst kann also Fehler beim Upgrade selbst nicht unbedingt vermeiden, man kann Fehler allerdings "korrigieren" und dann das Upgrade fortsetzen.
Wie bei jedem neuen Tool sind die Informationen allerdings noch nicht an allen Stellen so, wie man es sich erhofft und auch in der Dokumentation gibt es noch einige Stellen, die missverstanden werden könnten, wenn man seine ersten Schritte mit dem Tool unternimmt. Das Ergebnis ist dann nicht unbedingt das, welches man sich erhofft - und erwartet - hat.
Pre- und Postfixups
Pre- und Postfixups erstellt das Autoupgrade Tool automatisch und lässt diese dann auch laufen. Dieses ist auf der einen Seite sehr hilfreich, auf der anderen Seite gibt es aber ggfs. Tasks, die man selbst erledigen möchte. So kann man z.B. die Datenbank mit dem pre-upgrade vorbereiten, das Autoupgrade-Tool aber zeitgesteuert (am Abend/Wochenende) dann das Upgrade in einem silent/batch-Modus durchführen lassen. Dadurch spart man Zeit bei der Upgrade-Phase (einer der "typischen" Pre-Fixups ist z.B. Datenbankstatistiken zu erstellen/upzudaten).
Hinzu kommt, da das Autoupgrade-Tool sowohl im "deploy", als auch im "upgrade" Modus die Post-Fixups ausführt, gibt es keine andere Möglichkeit, diese zu überspringen, um ggfs. Dinge (wie Gather Database Statistics) nach dem Upgrade manuell durchführen zu können. Hier muss also zwingend diese Methode angewendet werden.
Schritt-für-Schritt-Anleitung
So überspringt man Fixups
1. Download der aktuellen autoupgrade.jar
Immer vom Oracle Support die neueste autoupgrade.jar herunterladen. Man findet diese unter "AutoUpgrade Tool (Doc ID 2485457.1)". Als Java Runtime hat es sich bewährt, die aus dem jeweiligen Oracle Home zu verwenden, in das die Datenbank upgegradet werden soll. Insbesondere auf Linux Servern muss somit keine passende Java Version installiert werden (bei MS Windows ist oftmals schon eine kompatible Java Version installiert, falls nicht kann auch hier die aus dem Oracle Home verwendet werden).
2. Config-Datei erstellen
Für das autoupgrade-jar gibt es eine kleine Anzahl von möglichen Input-Parametern (nachfolgend eine Übersicht). Die einfachste Methode ist es, sich ein Sample-File erstellen zu lassen und dieses manuell anzupassen (-create-sample-file config).
Der Inhalt einer Konfigurationsdatei könnte z.B. wie folgt aussehen:
global.autoupg_log_dir=C:\oracle\autoupgrade\logs
#
# Database number 1
#
upg1.dbname=ECKES
upg1.start_time=NOW
upg1.source_home=C:\oracle\product\12.1.0\dbhome_1
upg1.target_home=C:\app\Administrator\product\19.1.0\dbhome_1
upg1.sid=ECKES
upg1.upgrade_node=WIN-LCHH5KOA3RM
upg1.target_version=19
upg1.run_utlrp=yes
upg1.timezone_upg=yes
3. Analyze-Mode ausführen
Mit der erstellten (Standard-) Konfiguration und des Sample-Files als Input kann dann das Autoupgrade-Tool im "Analyze"-Modus ausgeführt werden. Dieses analysiert die Datenbank und erstellt eine Reihe von Dateien. Innerhalb weniger Minuten erhält man somit in einem Unterverzeichnis des Autoupgrade-Logs verschiedene Dateien, darunter ein HTML und eine cfg-Datei. Wichtig dabei ist, sich die Job-Nummer zu merken/zu notieren. Da der Analyze-Modus für eine Datenbank beliebig oft ausgeführt werden kann, ist die Job-Nummer nicht immer die beim ersten Durchgang verwendete "100".
4. Fixup überspringen - Konfigurationsdatei
Nach der gewissenhaften Überprüfung der HTML-Datei und den allen dort aufgeführten Informationen/Warnungen/Fehlern kann die Konfiguration vorgenommen werden. Dazu kommen alle Fixups in Frage, die in der HTML-Datei als "automatisch" gekennzeichnet sind. Alle anderen Fixups werden nicht automatisch ausgeführt und können/müssen damit auch nicht übersprungen werden. Die zu verwendende Datei ist die <Datenbank>_checklist.cfg Datei, die im jeweiligen Jobnummer-Unterverzeichnis vorhanden ist.
In dieser Datei können hinter dem Punkt [runfix] stehende "YES" auf "NO" geändert werden. Ist z.B. das DICTIONARY_STATS durchgeführt worden oder soll übersprungen werden, so ist hier bei [runfix] der Wert "NO" einzutragen.
5. Fixup-Konfiguration in der Datenbank-Konfigurationsdatei eintragen
Wirft man einen Blick in die Dokumentation zum Überschreiben der "Default Fixups" landet man schnell bei folgendem Satz (sinngemäss):
"Als default verwendet Autoupgrade das neueste, generierte File." => siehe Punkt "How to override default fixups".
Allerdings gibt es somit gleich 2 Wege, die leicht irreführend sind. Auf der einen Seite kann zwar das autoupgrade im Modus "Upgrade" gestartet werden, dies bedeutet aber gleichzeitig, dass alle Pre-Fixups nicht durchgeführt werden (alle Post-Fixups schon). Wird dagegen der Modus "deploy" verwendet, so wird die Analyze-Phase erneut ausgeführt, somit ein neues <Datenbank>_checklist.cfg File erstellt und dieses für die Fixups verwendet - und nicht das speziell modifizierte.
Wichtig ist nun, dass in der Datenbank-Konfigurationsdatei ein neuer Eintrag angelegt wird. Dieser muss auf das entsprechend modifizierte <Datenbank>_checklist.cfg File verweisen. Der Eintrag lautet "checklist". In nachfolgender Grafik ist ein entsprechende Eintrag in der letzten Zeile als Platzhalter bereits vorbereitet. Somit muss nur noch der Pfad zur richtigen Datei angegeben werden (und selbstverständlich die # als Kommentar entfernt werden).
6. Autoupgrade starten
Der letzte Schritt ist nun, das Autoupgrade im "Deploy"-Modus zu starten. Da bereits eine Konfigurationsdatei für die Checkliste der Pre- und Postfixes angegeben ist, überspringt das Autopugrade-Tool die darin befindlichen Fixups, sofern diese mit einem [runfix] "NO" versehen worden sind. Nach der Pre-Upgrade-Phase wird dann das Upgrade der Datenbank durchgeführt, bevor im Post-Step dann wieder eventuell vorhandene Fixes mit [runfix] "NO" übersprungen werden.
Ist das nicht einfach im Vergleich zu all den manuell notwendigen Schritten, die man durchführen muss, wenn man das Autoupgrade-Tool nicht nutzt?
Kommentare
|
Die Lösung war einfach. In der SQLNET.ora fehlte der NTS Eintrag für Authentication. Danach ging das Login auf der Source DB.
|
Hallo,
das ist schwierig zu sagen. Das Autoupgrade-Tool wirft diesen "Fehler" nämlich generisch, wenn es nicht mit "sqlplus / as sysdba" auf die Datenbank zugreifen kann. Ich gehe mal davon aus, Sie testen mit dem autoupgrade.jar 19.9.0, also dem aktuellsten.
Es kann an verschiedenen Dingen liegen:
- SQLNet Einstellungen (die den direkten Connect verbieten, z.B. SQLNET.AUTHENTICATION_SERVICES )
- Der Service läuft unter einem anderen Benutzer (für das Autoupgrade würde ich die Services immer zurückstellen auf Lokales System/Lokaler Dienst
- Das Home ist fehlerhaft in der Config-Datei (falscher Pfad -> Leerzeichen bzw. ein Teil des Pfades fehlt)
- Genauso könnte auch ein Eintrag in der übergebenen Config-Datei für SID oder DB_UNIQUE_ID falsch sein (Blank, Typo, …)
Ein Beispiel:
Meine lokale DB unter Windows 10 heisst ORCL, ich habe aber die Config noch wie im Sample (nur die Verzeichnisse angepasst:
upg1.dbname=employee
upg1.start_time=NOW
upg1.source_home=C:\app\oracle\product\12.2.0
upg1.target_home=C:\app\oracle\product\19.3.0
upg1.sid=emp
Wenn ich das Autoupgrade jetzt im Analyze Mode starte erhalte ich den Fehler:
Processing config file ...
------------ ERROR ------------
Fehlerursache: Die Datenbank emp scheint heruntergefahren oder mit den falschen Binärdateien für den Modus ANALYZE geöffnet zu sein. Stellen Sie sicher, dass sie mit C:\app\oracle\product\12.2.0 geöffnet ist
------------ ERROR ------------
Fehlerursache: Die Datenbank emp ist aktuell mit dem Status CLOSED geöffnet. Für den Modus ANALYZE muss sie in einem der folgenden Status geöffnet sein: [OPEN, MOUNTED].
Verbindung zur Datenbank für Eintrag emp nicht möglich
-----------------------------------------
Ich hoffe, ich konnte Ihnen ein paar Anregungen geben. Wenn Sie den Fehler gefunden haben, bitte ich Sie, doch gerne die Lösung als Kommentar zum Post hinzuzufügen.
Viele Grüsse
Jörg Sobottka
|
Haben sie vielleicht einen Tipp für mich ? Der Analyze Mode läuft in einen Fehler. Das Tool behauptet, daß die zu upgradende DB im status CLOSED ist. Das ist jedoch nicht der Fall, die DB ist ganz normal offen und läuft auch normal im Archivemode = yes. Die DB ist auch "connectable". Der Oracle Service hat bis dato keine Idee. Herzlichen Dank in voraus. Ich verwende übrigens Windows Server 2012, ja ich weiß, da gibt es immer Probleme.
Freundliche Grüße
Helmut Mehlhart