Aufgrund der Notwendigkeit, endlich das Long Term Support Release 19c einzusetzen, gibt es wohl kaum ein Unternehmen bzw. einen DBA, der sich nicht damit beschäftigt, wie der Upgrade oder auch die Migration in die Multitenant-Architektur aussehen kann. Da kommt der Autoupgrade gerade recht. Es ist verblüffend, wie einfach das Tool funktioniert. Man gibt einfach ein paar Basisdaten an und nach ca. 30 bis 60 Minuten ist die Datenbank fertig "upgegradet".
So funktioniert das im Einzelnen:
- Zunächst einmal liest man sich den Blog von Mike Dietrich zu dem Thema durch: mikedietrichde.com/2019/04/29/the-new-autoupgrade-utility-in-oracle-19c/.
- Danach lädt man sich die neueste Version des Java-Packages autoupgrade.jar über dieses My Oracle Support Dokument herunter: "2485457.1 – AutoUpgrade Tool".
- Wenn noch kein Konfigurationsbeispiel existiert, kann man sich dieses anschließend erstellen lassen:
$ORACLE_HOME/jdk/bin/java -jar ./autoupgrade.jar -
create_sample_file config config.cfg
Das Konfigurationsbeispiel (config.cfg) füllt man dann mit den eigenen Daten. Dabei kann man, wenn man mehrere Datenbanken auf einem Rechner betreibt, auch alle gleichzeitig "upgraden" – sofern man die Fachabteilungen unter einen Hut bekommt. Ich selbst verwende immer eine Datei pro Datenbank, weil ich das einfacher kontrollieren kann.
Hier das Beispiel für die Datenbank JOSEPH:
cat configJOSEPH.cfg
upg1.log_dir=/home/oracle/autoupgrade
upg1.sid=JOSEPH
upg1.source_home=/u01/app/oracle/product/12.2.0/dbhome_1 upg1.target_home=/u01/app/oracle/product/19.0/dbhome_1
upg1.start_time=NOW
upg1.upgrade_node=haydn
upg1.run_utlrp=yes
#upg1.timezone_upg=[yes|no]
#upg1.target_version=[12.2|18|19|21]
Einfacher kann eine Konfigurationsdatei nicht aussehen!
Bis zum endgültigen Upgrade ist es jetzt nur noch ein kleiner Schritt. Um festzustellen, ob die Datenbank alle Voraussetzungen erfüllt, sollte man diese analysieren. Das kann durchaus ein oder zwei Wochen vor dem eigentlichen Upgrade passieren.
java -jar ./autoupgrade.jar -config configJOSEPH.cfg -mode analyze
Das Resultat sieht dann (hoffentlich) so aus:
No parameter 'global.autoupg_log_dir' found in config file, using /u01/app/oracle/cfgtoollogs/autoupgrade
AutoUpgrade tool launched with default options
Processing config file ...
+--------------------------------+
| Starting AutoUpgrade execution |
+--------------------------------+
1 databases will be analyzed
Type 'help' to list console commands
upg> Job 100 completed
------------------- Final Summary --------------------
Number of databases [ 1 ]
Jobs finished [1]
Jobs failed [0]
Jobs pending [0]
Please check the summary report at: /u01/app/oracle/cfgtoollogs/autoupgrade/cfgtoollogs/upgrade/auto/status/status.html
/u01/app/oracle/cfgtoollogs/autoupgrade/cfgtoollogs/upgrade/auto/status/status.log
Die Analyse dauert ca. 5 Minuten. Während dieser Zeit passiert vordergründig erst einmal nichts. Am besten ist es daher, während dieser Zeit einen Kaffee oder Tee zu trinken. Wenn die Analyse erfolgreich war, steht dem Upgrade nichts mehr im Wege. Generell gibt es auch die Möglichkeit, einen Fixit-Lauf durchzuführen, um ggf. Fehler zu beheben. Da der Autoupgrade die meisten Fehlerquellen aber schon kennt, habe ich das bisher noch nicht benötigt.
Für den Upgrade wird dann der Modus "deploy" verwendet:
java -jar ./autoupgrade.jar -config configJOSEPH.cfg -mode deploy
Auch hier gilt wieder, dass im Vordergrund erst einmal nichts passiert. Kaffeetrinken hilft dabei aber nicht, weil man von so viel Kaffee Herzrasen bekommt. Je nachdem, ob es sich um eine NON-CDB oder eine Multitenant-Datenbank handelt, dauert der Upgrade zwischen 30 Minuten (NON-CDB) und 1,5 Stunden (Multitenant).
Schließlich meldet sich der Autoupgrade aber mit folgender Information:
upg> Job 101 completed
------------------- Final Summary --------------------
Number of databases [ 1 ]
Jobs finished [1]
Jobs failed [0]
Jobs pending [0]
Please check the summary report at:
/u01/app/oracle/cfgtoollogs/autoupgrade/cfgtoollogs/upgrade/auto/status/status.html
/u01/app/oracle/cfgtoollogs/autoupgrade/cfgtoollogs/upgrade/auto/status/status.log
Damit ist der Upgrade der Datenbank auf 19c fertig.
Tipps:
Mittlerweile habe ich über 200 Datenbanken mit dem Autoupgrade auf die Version 19c angehoben. Hier noch ein paar Tipps für den Erfolg:
- Der Listener wird nicht neu gestartet. D.h. man sollte zum Schluss nicht vergessen, diesen mit dem neuen ORACLE_HOME zu starten.
- Bei Verwendung eines Schedulers ist zu empfehlen, den Parameter -noconsole bei Autoupgrade mitzugeben. In einem Fall, bei dem wir Control-M von BMC als Scheduler für den Autoupgrade verwendet haben, ist uns das Tool mit einem Memoryproblem im Java abgestürzt. Der Grund dafür war eine Logdatei, in der fortlaufend der Status des Upgrades geschrieben wird.
- Bei einer Multitenant-Datenbank muss man darauf achten, dass es keine Einträge in der View v$recover_file gibt. Aufgrund eines "Features" werden dort oft nach einem Data Guard Switchover oder Failover die Datafiles der PDB$SEED angezeigt (MOS Doc ID 2428841.1). Das ist unschön, laut Oracle aber so gewollt (Not a Bug).
- Wenn es offene, verteilte Transaktionen in dba_2pc_pending gibt, wird der Upgrade ebenfalls abbrechen. Also besser nachsehen, ob es dort nicht noch uralte Einträge gibt.
Ansonsten funktioniert das Tool hervorragend und vereinfacht den Upgrade nach Version 19c erheblich. Da das Tool restartfähig ist, ist es auch nicht schlimm, wenn man tatsächlich mal auf einen Fehler läuft (z.B. weil der SYSAUX Tablespace voll ist). Man ruft einfach den Java-Befehl noch einmal auf und nach kurzer Zeit macht das Tool an der Stelle weiter, wo es aufgehört hat. Selbst wenn die Datenbank zwischenzeitlich gecrasht war.
Johannes Ahrends,
Mitglied der Delegiertenversammlung Datenbank,
Themenverantwortlicher Datenbankadministration der DOAG Datenbank Community
