It’s download time again. So please refresh the AutoUpgrade release you are using with the new one since the March 2023 release of AutoUpgrade is available now for download.

Photo by Mario von Rotz on Unsplash
Where to download?
As usual, please download the newest version of AutoUpgrade via MOS Note:2485457.1 – Download AutoUpgrade.
What does this version improve?
A lot.
Really, a lot of things got improved.
You’ll find the change.log for tracking purposes at the bottom of the note. I’d wish everybody would do such a transparent change tracking as the AutoUpgrade team does. This makes your life hopefully much easier. And as usual, we kept the previous versions of AutoUpgrade at the bottom of the MOS Note:2485457.1 as well … just in case … 🙂
At first, the new release greets you as 23c. You may guess why that is – and as from day 1 of AutoUpgrade, you will need only ONE SINGLE AUTOUPGRADE for all your upgrades. So fetch the newest one, and it will upgrade everything from 11.2.0.4 to 23c.
AutoUpgrade will greet you with:
java -jar autoupgrade.jar -version build.version 23.1.230224 build.date 2023/02/24 14:53:24 -0500 build.hash a1e2990e build.hash_date 2023/02/24 14:44:39 -0500 build.supported_target_versions 12.2,18,19,21 build.type production build.label (HEAD, tag: v23.1, origin/stable_devel, stable_devel) 32 bug fixes since v22.5 release Tag: V23.1 Description: This is the release for 23.1 on MOS
New Features
- AUPG-3055 – Support RU Patching for Windows platform
- AUPG-3155 – Patching support for Monthly Recommended Patches and same version Oracle Homes
- AUPG-3190 – Support Datapatch checks in AutoUpgrade. See checks below that start with SC_
Enhancements
- AUPG-1430 – Allow DBA to ignore certain upgrade and datapatch errors
- AUPG-2644 – AutoUpgrade to recompile only invalid objects owned by Oracle-maintained users
- AUPG-2083 – Move or copy Oracle Database Gateway for ODBC files from source home to target home
Behavior changes
- AUPG-3155 – timezone_upg configuration parameter defaults to NO for RU patching
- AUPG-3144 – Stop & Disable non-CDB Resource when using refreshable clones
- BUG-34802929 – Timezone is not upgraded when moving a Database from 19.3 with timezone version 32 installed and patching to 19.16 RU with
timezone version 39 installed. AutoUpgrade will now dynamically figure out the Timezone version at runtime and install the lastest timezone files found in the target home
Additonal command option
The Autoupgrade listchecks parameter generates descriptions of all of the checks AutoUpgrade performs for both upgrade and patching.
java -jar autoupgrade.jar -listchecks
Additionally added checks
- AUPG-2475 – Add check PARAM_VALUES_IN_MEM_ONLY to validate memory and pfile/spfile parameters are in sync
- AUPG-3090 – Add check PREVENT_EMPTY_DATAPATCH_DIRECTORY_ERROR by copying patch directories from the source home to the target home
- AUPG-3095 – Add check PATCH_33557344_INSTALLED to check if patch 33557344 is installed
- AUPG-3151 – Add check SC_GUARDIUM checks for Guardium security software enabled
- Add check SC_IMPERVA checks for Imperva security software enabled
- Add check SC_LOCALE checks environmental variables LC_ALL and LC_CTYPE are correctly set
- Add check SC_OPTIM_UPGRADE_PARAM checks for parameter _optim_dict_stats_at_db_cr_upg is set to TRUE
- Add check SC_DATAPUMP_RUNNING checks for any running Data Pump jobs
- AUPG-3164 – Add check DISK_SPACE_FOR_LOGGING which calculates the amount of disk space required to run the AutoUpgrade jobs
- AUPG-3172 – Add check SC_GG_LOGMINER_TRIGGERS to warn about enabled GoldenGate and LogMiner triggers
- AUPG-3180 – Add check SC_BACKUP_JOBS to warn about running RMAN jobs
- AUPG-3186 – Add check SC_SCHEDULE_JOBS to warn about having jobs in execution or scheduled in the next hour
- AUPG-3190 – Add check SC_SYS_PUBLIC_GRANTS to check if schema SYS objects have the correct grants
- AUPG-3191 – Add check MAX_STRING_SIZE_ON_DB to stop a plugin for MAX_STRING_SIZE where the source contains extended MAX_STRING_SIZE and the target cdb contains standard MAX_STRING_SIZE
- AUPG-3197 – Add check SC_STATS_GATHERING to warn about statistics gathering running in the database
- AUPG-3244 – Add check TBLSPACE_FLASHBACK_OFF Flashback is not possible if at least one tablespace in the database has flashback disabled
Fixes included
- AUPG-3161 – Preserve oratab entry when remove_rac_config is set to no
- AUPG-3162 – In a check action/rule/broken rule that has text and a table, only the table is displayed in status.html
- AUPG-3168 – Checks with RunScope DATAPATCH must run only for RU Patching scenarios
- AUPG-3209 – Noncdbtopdb same version was not executing before and after Actions
- AUPG-3194 – AutoUpgrade version check does not work as expected
- AUPG-3219 – The network files are not being merged for Noncdbtopdb, Unplug-Plug, and Unplug relocate on the same system
- AUPG-3248 – Increase threshold to trigger MIN_RECOVERY_AREA_SIZE check
- AUPG-3249 – keystore directory being incorrectly identified as a subdirectory of global logging directory
- AUPG-3254 – Add build label to -version output
- BUG-34661883 – AutoUpgrade to execute dbms_stats.gather_schema_stats() with force set to true
- BUG-34082156 – TABLESPACE_INFO check does not warn that autoextensible tablespace’s maxbytes could be exceeded during upgrade
- BUG-34904206 – AutoUpgrade fails with prefix source_home not defined when target_home is defined globally for unplug-relocate
Summary
The new AutoUpgrade 23c build has not only a lot of improvements but also some important changes. And of course, we fixed some open issues. As usual, we tested the tool to the bones on all available platforms. But we are only humans. In case something is not working as expected, please open an SR and upload the necessary logs collected with:
java -jar autoupgrade.jar -config myconfig.cfg -zip
to the SR. And you may want to add an opatch lsinventory output as well.
Time to download the new version of AutoUpgrade from MOS Note:2485457.1.
–Mike
Hi Mike
Is it also possible executing DBMS_OPTIM_BUNDLE with autoupgrade
https://mikedietrichde.com/2021/08/10/should-you-enable-_fix_controls-with-dbms_optim_bundle/
Hi Juerg,
technically you can easily with an after_action script.
Just add upg1.after_action=/home/user/run_optim.sh
In this run_optim.sh you point to the SQL script running DBMS_OPTIM_BUNDLE.
This should be doable.
For general use, we are still in discussion about whether we are allowed to enforce it, or not.
Cheers
Mike
The Oracle Note says the latest AutoUpgrade (20230224) is only compatible with 12.2 through 21.3. No mention of 11g or 23c. Also, you previously posted that there would be no supported upgrade path to 23c except from 19c, so has this changed now? Thanks.
Hi Mark,
this is just because 23c is not out yet – it is in Beta-1 phase, and beta-1 does not support upgrading.
As soon as a release is out which supports upgrading to it, the MOS note will be updated.
And the minimum requirement for upgrades to 23c is 19c.
Cheers
Mike
Oracle 23c support ?
cbron:/opt/oracle/product/19/dbhome_1/rdbms/admin >java -jar autoupgrade.jar -preupgrade “target_version=23,dir=/tmp/logauto” -mode analyze
PREUPGRADE logs output location: /tmp/logauto
AutoUpgrade is not fully tested on OpenJDK 64-Bit Server VM, Oracle recommends to use Java HotSpot(TM)
AutoUpgrade 23.1.230224 launched with default internal options
Processing config file …
There were conditions found preventing AutoUpgrade from successfully running
*Unsupported Upgrade
cbron An unsupported source database version [19.17.0.0.0] when upgrading to target database version [23] has been found
cbron:/opt/oracle/product/19/dbhome_1/rdbms/admin >java -jar autoupgrade.jar -version build.version 23.1.230224
build.date 2023/02/24 14:53:24 -0500
build.hash a1e2990e
build.hash_date 2023/02/24 14:44:39 -0500
build.supported_target_versions 12.2,18,19,21
build.type production
build.label (HEAD, tag: v23.1, origin/stable_devel, stable_devel)
cbron:/opt/oracle/product/19/dbhome_1/rdbms/admin >
Seems not.
Did you try this with the beta of 23c?
Or did you just set the VERSION in the config file?
The latter is not needed, but beta-1 which is out now does not support upgrading to 23c-beta-1 – hence, AU is blocking it as well.
Cheers,
Mike
Mike,
No I just wanted to test the latest AU with preupgrade . I ran the AU on a 19C installation and give as target version 23c. This triggerd me: “So fetch the newest one, and it will upgrade everything from 11.2.0.4 to 23c.”
Actually, I did check with the team and the 23c version is only given to BETA customers right now.
So the available version per download is not allowing upgrades to 23c.
And of course (I may not been too clear), you need to be on 19c or 21c in order to be able to upgrade to 23c directly.
Cheers
Mike
Hi Mike,
Can you confirm that rolling patch installation is not supported in the latest version of the AutoUpgrade tool as stated in the restrictions section of the documentation? https://docs.oracle.com/en/database/oracle/oracle-database/21/upgrd/autoupgrade-oracle-database-config-options.html#GUID-79B47B14-A05D-4D0A-8D3B-4436383B2BA5
if so, is it on the roadmap to be available soon?
Thank you for everything you do.
Regards
Alessandro
Hi Alessandro,
this is correct – AU does not support/implement the ROLLING PATCHING yet.
We are working on it, at first for “out of place” patching, later for “in-place” patching.
But this is not as trivial as it may look like at first sight. Still, we need to implement it for Exadata as well.
Cheers
Mike
Hi Mike, an interesting post,
In relation to the post we see that the Autoupgrade 23c tool is already available, does this mean that Database version 23 will be out soon?
When is the release date of the Database version 23?
Hi Adrian,
I can’t tell you – but please watch out for some announcements soon.
Cheers,
Mike
What is the thought process of adding “AUPG-2644 – AutoUpgrade to recompile only invalid objects owned by Oracle-maintained users”? It’s more of a problem for us, as it leaves all user owned schema objects invalid. We are having to move back to old v22.5, which takes care of both set of users.
Is there way we can disable AUPG-2644 and still use v23.1?
Only other option I see is to call upg1.after_action=”utlrp”
Hi Yogesh,
actually I can’t follow your point. Can you explain to me why the database upgrade should recompile your user owner objects?
We made a very important improvement by only recompiling oracle-maintained (aka owned) objects during a database upgrade. The general problem with invalid user objects is that you may struggle a lot with dependencies. Views for instance can be a true nightmare when underlying objects don’t exist.
If you want an upgrade to recompile, then just add a after_action script which triggers the compilation of everything left invalid as you proposed already. But keep in mind that this needs to be a shell script, so it must be (on non-Windows ports):
upg1.after_action=recompile.sh
That is simple and easy. But it shouldn’t be an upgrade task to recompile user-owned objects.
Cheers,
Mike
V23.1
— PRE
Application User Name Number of INVALID Objects
————————— ————————-
USER1 8
USER2 4
USER3 1
— POST autoupgrade
— autocompile20230606012919xxxx.log
# of invalid User-owned objects: 1055
The Following Invalid Objects have been found. (MAX 250 Listed)
….
AUTOUPGRADE_INVALID_OBJECT_FOUND
OWNER COUNT(*)
———— ———-
PUBLIC 12
USER3 728
USER1 272
USER2 56
— Post manual utlrp
OWNER COUNT(*)
———— ———-
USER3 1
USER2 3
++++++++++++++++++++++++++++++++++++++++
V22.5
— PRE
Application User Name Number of INVALID Objects
————————— ————————-
USER1 8
USER2 4
USER3 1
after autoupgrade i.e. where it compiled both oracle-maintained + user objects
OWNER COUNT(*)
———— ———-
USER3 1
USER2 3
We are upgrading hundreds of boxes and manually running utlrp, is just adding another step. That’s where earlier autoupgrade.jar was helping us and kind of made me think, why this enhancement!!
I see your point – and thanks for the overview.
Let me check something with the team.
Cheers
Mike
Hi Yogesh,
could it be that these objects depend on “Oracle maintained objects”, such as dictionary views for instance?
We don’t see any reason why an object in USER3 should become invalid as part of the upgrade. This can only happen when the user has objects which settle on dictionary objects.
Now do us a favor please.
1. You open an SR -zip
2. We need: select owner, object_name, object_type from dba_invalid_objects order by owner, object_type, object_name;
3. We need: java -jar autoupgrade.jar -config
4. Put the SR number in the comment on the blog or send it directly to me to mike.dietrich …. oracle.com
Cheers,
Mike