Release Update einspielen mit Autoupgrade
Vor etwa einer Woche hat Oracle eine neue Version des Autoupgrade-Tools veröffentlicht, dass nicht nur Updates sondern auch Patches kann. Gestern kam das quartalsmäßige Release Update heraus. Grund genug, diese beiden Dinge miteinander zu verbinden und den RU mit AutoUpgrade einzuspielen.
Dabei macht AutoUpgrade nur den Datenbank-Teil, d.h. vorher muss ein neues Oracle-Home-Verzeichnis mit dem gewünschten Ziel-Patchstand vorbereitet werden.
Mitspieler in meinem Labor-Test sind also:
1. Die aktuelle Version von AutoUpgrade – erhältlich über die MOS-Note 2485457.1
2. Ein installiertes Oracle-Home mit Oracle Database 19c – Stand 19.15 (Release-Update April 2022) – auf diesem Stand ist meine Test-Datenbank
oracle@abel:~/ echo $ORACLE_HOME /u00/app/oracle/product/19.15-ee oracle@abel:~/ $ORACLE_HOME/OPatch/opatch lspatches 33912872;DATABASE PERL UPDATE IN 19C TO V5.32-1 (CVE-2022-23990 - LIBEXPAT UPDATE) 33808367;OJVM RELEASE UPDATE: 19.15.0.0.220419 (33808367) 33806152;Database Release Update : 19.15.0.0.220419 (33806152) 29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399) OPatch succeeded.
3. Ein installiertes Oracle-Home mit Oracle Database 19c – Stand 19.16 (Release-Update Juli 2022) – das ist der Ziel-Release-Stand für meine Test-Datenbank
oracle@abel:~/ echo $ORACLE_HOME /u00/app/oracle/product/19.16-ee oracle@abel:~/ $ORACLE_HOME/OPatch/opatch lspatches 34113634;JDK BUNDLE PATCH 19.0.0.0.220719 33912872;DATABASE PERL UPDATE IN 19C TO V5.32-1 (CVE-2022-23990 - LIBEXPAT UPDATE) 34086870;OJVM RELEASE UPDATE: 19.16.0.0.220719 (34086870) 34133642;Database Release Update : 19.16.0.0.220719 (34133642) 29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399) OPatch succeeded.
4. Eine Datenbank, die im 19.15-er Oracle-Home läuft. In meinem Fall ist es einen Non-CDB namens “DEMONCDB”.
Für Autoupgrade brauchen wir eine Konfigurationsdatei, die im Minimalfall etwa so aussieht:
oracle@abel:/u00/app/oracle/stage/ cat autoupgrade_patch_DEMONCDB.txt patch_DEMONCDB.log_dir=/home/oracle/ patch_DEMONCDB.sid=DEMONCDB patch_DEMONCDB.source_home=/u00/app/oracle/product/19.15-ee patch_DEMONCDB.target_home=/u00/app/oracle/product/19.16-ee patch_DEMONCDB.start_time=NOW patch_DEMONCDB.run_utlrp=yes
Erster Schritt ist dann das “analyze”, bei dem Autoupgrade prüft, ob es ggf. zu Problemen kommen könnte:
oracle@abel:/u00/app/oracle/stage/ $ORACLE_HOME/jdk/bin/java \ -jar /u00/app/oracle/stage/autoupgrade.jar \ -config /u00/app/oracle/stage/autoupgrade_patch_DEMONCDB.txt \ -mode analyze No parameter 'global.autoupg_log_dir' found in config file, using /u00/app/oracle/cfgtoollogs/autoupgrade AutoUpgrade 22.4.220712 launched with default internal options Processing config file ... +--------------------------------+ | Starting AutoUpgrade execution | +--------------------------------+ 1 Non-CDB(s) will be analyzed Type 'help' to list console commands upg> Job 101 completed ------------------- Final Summary -------------------- Number of databases [ 1 ] Jobs finished [1] Jobs failed [0] Please check the summary report at: /u00/app/oracle/cfgtoollogs/autoupgrade/cfgtoollogs/upgrade/auto/status/status.html /u00/app/oracle/cfgtoollogs/autoupgrade/cfgtoollogs/upgrade/auto/status/status.log
Der Job war erfolgreich, d.h. AutoUpgrade erwartet keine Probleme. Sicherheitshalber schauen wir uns noch die Log-Datei an:
oracle@abel:/u00/app/oracle/stage/ cat /u00/app/oracle/cfgtoollogs/autoupgrade/cfgtoollogs/upgrade/auto/status/status.log
==========================================
Autoupgrade Summary Report
==========================================
[Date] Wed Jul 20 10:17:02 CEST 2022
[Number of Jobs] 1
==========================================
[Job ID] 101
==========================================
[DB Name] DEMONCDB
[Version Before Upgrade] 19.15.0.0.0
[Version After Upgrade] 19.16.0.0.0
------------------------------------------
[Stage Name] PRECHECKS
[Status] SUCCESS
[Start Time] 2022-07-20 10:16:54
[Duration]
[Log Directory] /home/oracle/DEMONCDB/101/prechecks
[Detail] /home/oracle/DEMONCDB/101/prechecks/demoncdb_preupgrade.log
Check passed and no manual intervention needed
------------------------------------------
Es sieht alles gut aus und wir können somit das eigentliche Patchen starten. Vorher müssen natürlich die Applikationen heruntergefahren werden, denn für den Wechsel des Oracle-Homes muss auch die Datenbank kurz heruntergefahren werden.
oracle@abel:/u00/app/oracle/stage/ $ORACLE_HOME/jdk/bin/java \ -jar /u00/app/oracle/stage/autoupgrade.jar \ -config /u00/app/oracle/stage/autoupgrade_patch_DEMONCDB.txt \ -mode deploy No parameter 'global.autoupg_log_dir' found in config file, using /u00/app/oracle/cfgtoollogs/autoupgrade AutoUpgrade 22.4.220712 launched with default internal options Processing config file ... +--------------------------------+ | Starting AutoUpgrade execution | +--------------------------------+ 1 Non-CDB(s) will be processed Type 'help' to list console commands upg> Job 102 completed ------------------- Final Summary -------------------- Number of databases [ 1 ] Jobs finished [1] Jobs failed [0] Jobs restored [0] Jobs pending [0] ---- Drop GRP at your convenience once you consider it is no longer needed ---- Drop GRP from DEMONCDB: drop restore point AUTOUPGRADE_9212_DEMONCDB1915000 Please check the summary report at: /u00/app/oracle/cfgtoollogs/autoupgrade/cfgtoollogs/upgrade/auto/status/status.html /u00/app/oracle/cfgtoollogs/autoupgrade/cfgtoollogs/upgrade/auto/status/status.log
Es scheint alles erfolgreich gelaufen zu sein, aber kontrollieren wir doch mal:
oracle@abel:~/ [rdbms21] grep DEMONCDB /etc/oratab DEMONCDB:/u00/app/oracle/product/19.16-ee:Y
Die oratab-Datei ist also korrekt angepasst.
Und wie sieht es in der Datenbank aus?
oracle@abel:~/ [DEMONCDB] sqlplus "/ as sysdba" SQL*Plus: Release 19.0.0.0.0 - Production on Wed Jul 20 10:32:56 2022 Version 19.16.0.0.0 Copyright (c) 1982, 2022, Oracle. All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.16.0.0.0 SQL> set pagesize 100 SQL> column comp_name format a40 SQL> column version_full format a20 SQL> column status format a15 SQL> select COMP_NAME,VERSION_FULL,STATUS from dba_registry; COMP_NAME VERSION_FULL STATUS ---------------------------------------- -------------------- --------------- Oracle Database Catalog Views 19.16.0.0.0 VALID Oracle Database Packages and Types 19.16.0.0.0 VALID Oracle Real Application Clusters 19.16.0.0.0 OPTION OFF JServer JAVA Virtual Machine 19.16.0.0.0 VALID Oracle XDK 19.16.0.0.0 VALID Oracle Database Java Packages 19.16.0.0.0 VALID OLAP Analytic Workspace 19.16.0.0.0 VALID Oracle XML Database 19.16.0.0.0 VALID Oracle Workspace Manager 19.16.0.0.0 VALID Oracle Text 19.16.0.0.0 VALID Oracle Multimedia 19.16.0.0.0 VALID Spatial 19.16.0.0.0 VALID Oracle OLAP API 19.16.0.0.0 VALID 13 rows selected.
Alle Komponenten sind “Valid” und auf “Release-Stand” 19.16 – Perfekt.
Wenn wir nicht mehr zum alten Stand (19.15) zurückwollen, dann können (und sollten!) wir auch den Restore Point löschen, den AutoUpgrade gesetzt hat:
SQL> select time,name from v$restore_point; TIME NAME -------------------------------- ---------------------------------------- 20-JUL-22 10.18.59.000000000 AM AUTOUPGRADE_9212_DEMONCDB1915000 SQL> drop restore point AUTOUPGRADE_9212_DEMONCDB1915000; Restore point dropped. SQL> exit Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.16.0.0.0
Damit wäre das Patchen mit AutoUpgrade abgeschlossen. In diesem Fall mit einer Non-CDB, aber mein Test mit einer 19c-CDB war genauso erfolgreich.
Links & weitere Informationen:
- MOS-Note: AutoUpgrade Tool (Doc ID 2485457.1)
- Oracle Database 19c Upgrade Guide
- MOS-Note: Critical Patch Update (CPU) Program Jul 2022 Patch Availability Document (DB-only) (Doc ID 2867871.1)
Nachtrag:
Auf einem weiteren Testsystem ist mir ein Fehler aufgefallen, den ich allerdings noch weiter analysieren muss 🙂
Beim Start einer Datenbank-Instanz nach dem Upgrade via Autoupgrade kann die Instanz die Patch-Informationen nicht auslesen. Die Meldungen in der alert.log-Datei sind:
2022-07-20T23:40:40.189717+02:00 Unable to obtain current patch information due to error: 20001, ORA-20001: Latest xml inventory is not loaded into table ORA-06512: at "SYS.DBMS_QOPATCH", line 2327 ORA-06512: at "SYS.DBMS_QOPATCH", line 854 ORA-06512: at "SYS.DBMS_QOPATCH", line 937 ORA-06510: PL/SQL: unhandled user-defined exception ORA-06512: at "SYS.DBMS_QOPATCH", line 932 ORA-29913: error in executing ODCIEXTTABLEFETCH callout ORA-29400: data cartridge error KUP-04095: preprocessor command /u00/app/oracle/product/19.16-ee/QOpatch/qopiprep.bat encountered error "pipe read timeout" ORA-06512: at "SYS.DBMS_QOPATCH", line 919 ORA-06512: at "SYS.DBMS_QOPATCH", line 2286 ORA-06512: at "SYS.DBMS_QOPATCH", line 817 ORA-06512: at "SYS.DBMS_QOPATCH", line 2309 =========================================================== Dumping current patch information =========================================================== Unable to obtain current patch information due to error: 20001 ===========================================================
Das Problem betrifft sowohl 19.16 als auch 21.7. Nachdem ich dann manuell datapatch für die Datenbanken aufgerufen habe – wobei da kein Patch in die Datenbank eingespielt wurde, trat der Fehler nicht mehr auf.
Amazon-Partner-Link
