Over the almost past 6 years since we unleashed it, AutoUpgrade changed Oracle Database upgrades significantly. But we’ve been asked so many times about one missing feature. And now it is available. Still in V.1, not feature complete (yet). And we know that you have wishes and desires. Stay with us, it’s going to improve rapidly. So, let us kick off AutoUpgrade’s Patching: The feature you waited for.
Photo by Ashim D’Silva on Unsplash
Wait a bit … AutoUpgrade Patching??
Yes, you are right. AutoUpgrade can patch your database from home A to home B for a longer time. We have leading customers who embedded this into their scripting shortly after we released it in October 2023. One of the leading airlines in the world is using it. One of the largest cloud providers is using it. It misses still one important piece since it restarts the database and does not allow RAC rolling patching at the moment. But the team is working on it.
So, what’s the news here?
AutoUpgrade builds your Oracle Home
That’s big news. And something we worked on since you’ve asked us for a longer while. AutoUpgrade can not only move your database from the previous to a new home, it can now also download the patches and build up your new Oracle Home.
In V.1 from AutoUpgrade 24.7 on, we support this right now for:
- Single instance homes
- Database homes only
- On Linux only
- Oracle Database 19c support
This gives you also immediately a quick outlook into the future. We are working on one of the platforms used especially in smaller environments, companies who don’t have a dedicated DBA team but need to patch also on a regular basis.
And we are clearly not tapping into the court of FPP (formerly known as RHP): Fleet Patching and Provisioning. FPP is meant for larger environments, for Exadata, for the cloud, it offers this awesome new service, Exadata Fleet Update, and much more.
So please, allow us a bit more time, and watch out on all our blogs for announcements coming quickly.
Allow AutoUpgrade to download from MOS
The key part of the new patching feature is the ability to download the recommended but also the desired patches from My Oracle Support (MOS). You can store your MOS credentials in the Secure External Password Store (SEPS) AutoUpgrade uses also for fully unattended TDE upgrades and Multitenant migrations already.
At the moment, you need to download the base release at first, store it in a folder, and then have AutoUpgrade add all your desired (or just the recommended) patches to it. It will build your home, then switch your database from the previous to the new home.
Sounds to good to be true?
Watch our new Virtual Classroom Seminar – Episode #21
If you don’t believe it, then watch it first – and afterwards, try it out.
On October 24, 2024 we delivered our Virtual Classroom Seminar – Episode #21, One-Button Patching – Makes life easier for every DBA. In case you couldn’t attend, or you simply did not know, then take these 55 minutes and it’ll change your life 🙂
See what we have to offer, it is pretty cool already:
Well, and of course we share the slides already with you, too: https://mikedietrichde.com/videos/. Just scroll down to Episode #21 and click on the thumbnail.
Download the newest version of AutoUpgrade
Now you want to try it out?
Then please download the most recent version of AutoUpgrade: MOS Note:2485457.1 – Download AutoUpgrade or directly from oracle.com. It also contains a short TXT reference file with instructions for the commands but the “help” command option in AutoUpgrade shows you the options quickly as well.
Furthermore, over the coming days, Daniel, Rodrigo and Alex will post on their blogs short “How to start” instructions for your convenience.
And we really want you to try it out, and let us know how it works. In case of an issue, please please please … we need the logs. And you can’t send us megabytes of zip files. So, instead of sending an email, do this:
- In case of an unexpected error, collect the AutoUpgrade logs with:
java -jar autoupgrade.jar -config yourconfig.cfg -zip - Open a Service Request (SR) on the MOS portal and use “AutoUpgrade: Patching” as starting keywords in the subject. This is not needed but will make our life a bit easier as well
- Then share with us the SR number, either via email or via blog post comments.
We will check it, triage it and carry it forward to the development team if needed.
Now it is your turn …
In addition, please see MOS Note: 2888431.1 – AutoPatch : Using Autoupgradev24.7(or newer) to perform Out of Place Patching for DB Home for further explanation.
Further Links and Information
- Virtual Classroom Seminars – Episode 2 – 21
- MOS Note:2485457.1 – Download AutoUpgrade
- Download AutoUpgrade directly from oracle.com
- MOS Note: 2888431.1 – AutoPatch : Using Autoupgradev24.7(or newer) to perform Out of Place Patching for DB Home
- Team blogs with more information: Daniel, Rodrigo and Alex
–Mike
Hi Mike,
I’m really struggling to get a 19c RAC db upgraded to 23ai (base). I have the 23ai software downloaded and installed on Exadata. At this time, I do not want to have autoupgrade patch or install any software. Just do the db upgrade fully. Can you help with what I might be doing wrong? Errors at the bottom. My cfg file is as follows: (I excluded the global keystore and log dir stuff)
upg1.db_unique_name=test_dbu
upg1.sid=test1
upg1.target_home=/u01/app/oracle/product/23ai/dbhome_2410
upg1.source_home=/u01/app/oracle/product/19c/dbhome_2404
upg1.folder=/u01/patches/patch
upg1.download=NO
upg1.patch=RECOMMENDED
upg1.node_name=hosta
24.7.241021
*Validating AutoUpgrade Patching support
AutoUpgrade Patching is not currently supported on RAC
24.6.240905:
The following errors were found in the configuration file:
The directory defined by the target_home parameter for prefix upg1 should not exist or be empty
Hi Chris,
please remove the node_name from your config file.
Please remove also the db_unique_name from it. Use upg1.sid instead.
And you are mixing patching download parameters with upgrade.
Please tell me what you are trying to do:
a) upgrade a database (is it a non-CDB or a CDB or a PDB) from 19c to 23ai? It reads as upgrade-only
b) same server or across servers?
Remove:
upg1.download=NO
upg1.patch=RECOMMENDED
upg1.node_name=hosta
Cheers,
Mike
Hi Mike, Thank you for getting back to me. I had made some of the changes you specified last week and I was able to get it to run under autoupgrade v. 24.2. After reading this, I tried an analyze using the target and source home as the same 23ai base software version. As I mentioned, I want to have the software preinstalled. We will be upgrading multiple databases at various time and I want the target home set ahead of time. What I am doing is upgrading a 19c cdb with 1 pdb database right to 23ai. Below are my config and results of the analyze:
global.log_dir=/u01/app/oracle/autoupgrade/logs/patching/
global.global_log_dir=/u01/app/oracle/autoupgrade/logs/patching
global.autoupg_log_dir=/u01/app/oracle/autoupgrade/logs/patching2
upg1.sid=test1
upg1.target_home=/u01/app/oracle/product/23ai/dbhome_2410
upg1.source_home=/u01/app/oracle/product/23ai/dbhome_2410
upg1.folder=/u01/patches/patch
ran below command with the various versions:
java -jar autoupgrade.jar -config config3.cfg -mode analyze
———————————————
AutoUpgrade version is older than 180 days. Oracle recommends to download the latest software version from MOS Doc id 2485457.1 https://support.oracle.com/epmos/faces/DocumentDisplay?id=2485457.1.
AutoUpgrade 24.2.240411 launched with default internal options
Processing config file …
+——————————–+
| Starting AutoUpgrade execution |
+——————————–+
1 CDB(s) plus 2 PDB(s) will be analyzed
Type ‘help’ to list console commands
——————————————————————-
WARNING: The config file contains AutoUpgrade Patching parameters. The ‘-patch’ parameter appears to be missing from the command line. It will be added automatically.
AutoUpgrade Patching 24.6.240905 launched with default internal options
Processing config file …
The following errors were found in the configuration file:
The directory defined by the target_home parameter for prefix upg1 should not exist or be empty
——————————————————————–
WARNING: The config file contains AutoUpgrade Patching parameters. The ‘-patch’ parameter appears to be missing from the command line. It will be added automatically.
AutoUpgrade Patching 24.7.241021 launched with default internal options
Processing config file …
AutoUpgrade Patching has derived the version for prefix upg1 as [23.5.0.24.07]. AutoUpgrade Patching currently only supports the following major versions: [19].
Hi,
yes, you have the upg1.folder=/u01/patches/patch parameter in your config.cfg.
Currently, AU can either patch or upgrade. Try the 24.8 version, it has improvements or remove the upg1.folder=/u01/patches/patch from your config file, please.
If you want both, install the SW, then upgrade, you need to run currently two AU sessions, one after another. One with a patching config file, the other with an upgrade config file. And yes, we may combine this 🙂 in the future 🙂
Sorry for the confusion.
Cheers,
Mike
HI Mike.
Sorry for the delay getting back. I just did the same test I did earlier doing only an analyze, I removed the upg1.folder and below are the results:
Both 24.6 and 24.7 fail with the error:
upg1.folder has no value defined in the user configuration file and it is a mandatory parameter
However, 24.8 without the upg1.folder, worked with the analyze switch just fine.
Thanks for the help.
Waiting on downloading the grid patches also ;~)
Thanks for this grate option
Hi Holger,
this may take a longer while.
Cheers,
Mike
[FATAL] Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’ of makefile ‘/u01/test/oracle/product/19.25/dbhome_1/rdbms/lib/ins_rdbms.mk’. See ‘/u01/oraInventory/logs/InstallActions2024-12-02_11-45-52AM/installActions2024-12-02_11-45-52AM.log’ for details.
Trying to install new home (19.25) on RHEL9 fails with above. This is known issue ref 2982833.1 & 2760289.1.
My question is how to know what patches need to be in “folder”?
Hi Ian,
currently we use RECOMMENDED for the RU, DPBP, Opatch and OJVM for 19c.
We fully rely on MOS mechanisms, and there is currently no way for us to find out “what else” is needed. There may be a some solution coming but at this point you need to add the patch number manually by yourself.
Cheers,
Mike
Hi Mike,
So when download=no, I should 1) have the patches required in the folder and 2) create the home – i.e. autoupgrade -patch will not create an oracle home when download=no but does require the patches in the folder for validation purposes?
Thank you.
When you say DOWNLOAD=NO, then AU expects the patches in the folder you are pointing to. It will not download them but install the home then based on the parameter options you chose.
Please see our DOAG 2024 slides at https://mikedietrichde.com/slides – there we show all the phases in detail and what each of them does.
Cheers,
Mike
Hi Mike,
why is “-mode analyze” neccessary for out-of-place patching?
thank you
Hi Nael,
please see our DOAG slides about it:
https://mikedietrichde.com/slides/#WEB2024
It does:
– download
– analyze
And the “-mode analyze” does:
– Analyzes database for patch readiness
– Datapatch Sanity Checks
– It is lightweight and non-intrusive
And finally, it is recommended, but not required
Cheers,
Mike
Hi Mike:
I have recently started using autoupgrade (24.7.241021) to do out of place patching from RU 19.24 to 19.25. This seems like an easy way to get a bunch of databases on the same host patched to the newest home – awesome!!!. My destination home is already created with the latest RU, OVJM patch (eg, 19.25). I purposefully do not set patch_in_upgrade_mode to minimize downtime.
However, I just noticed that after patching, the database has been left started with the “after” pfile instead of the spfile that was generated in the new home. This means I will need to go through another manual restart to get it to start with the spfile.
Is this the expected behavior?
Hi Ed,
let me check this with the team. Meanwhile, do you have a chance to upload at least your config file but even better if you had your “java -jar autoupgrade.jar -config yourconfig.cfg -zip”?
Thanks,
Mike
I did one of the autoupgrade livelabs after this and the problem did not occur during the livelab. I noticed that the auotupgrade version was 24.8 in the lab.
I retried with this newer version of autoupgrade in my environment and it worked just fine – the database was restarted with the spfile.
If you want me to try to recreate the problem, just let me know where you would like me to upload the zip file.
Thanks.
Ed
Hi Ed,
thanks for getting back to me so quickly.
Meanwhile, I did check with the AU team and Joe confirmed that this issue was known as is fixed from AutoUpgrade 24.8 onward.
It is tagged with AUPG-4030, and it is supposed to be also in the list of fixed issues when you scroll down to the bottom of the MOS note in the tracking file.
Cheers,
Mike
Hi Mike,
I’d like to know if it’s possible to patch a database using AutoUpgrade when the new Oracle home is installed and set up manually. I’ve been testing a patch from 19.3 to 19.26, and my current configuration file works fine. Here’s what I’m using:
global.keystore=/home/oracle/scripts/autoupgrade/keystore
global.global_log_dir=/home/oracle/scripts/autoupgrade/log
patch1.source_home=/u01/app/oracle/product/19.3.0/dbhome_1
patch1.target_home=/u01/app/oracle/product/19.26.0/dbhome_1
patch1.sid=ocp
patch1.folder=/installer/patch
patch1.patch=RECOMMENDED
patch1.download=YES
I’m wondering how to adjust it for my requirement: installing and setting up the software binary for the new Oracle home manually beforehand. Specifically, which parameters should I change, add, or remove to achieve this? Or is this approach even supported by AutoUpgrade?
Thanks,
Niron
Hi Niron,
please help me a bit, I think I am not following 100% what you plan to do when you write “I’m wondering how to adjust it for my requirement: installing and setting up the software binary for the new Oracle home manually beforehand.”
Do you want to have AutoUpgrade build JUST the home, and nothing else?
Thanks,
Mike
Hello Mike,
Thanks for getting back to me and sorry for that unclear question. I just don’t want AutoUpgrade to build the new target home for me, which means that I will install and patch the new target home manually and use AutoUpgrade to move the DB for me. I have tested it again by removing some parameter and now this configuration works fine:
global.keystore=/home/oracle/scripts/autoupgrade/keystore
global.global_log_dir=/home/oracle/scripts/autoupgrade/log
patch1.source_home=/u01/app/oracle/product/19.3.0/dbhome_1
patch1.target_home=/u01/app/oracle/product/19.26.0/dbhome_1
patch1.sid=ocp
Thanks,
Niron
Got it now – thanks 🙂
And then your config file gets much simpler.
global.global_log_dir=/home/oracle/scripts/autoupgrade/log
patch1.source_home=/u01/app/oracle/product/19.3.0/dbhome_1
patch1.target_home=/u01/app/oracle/product/19.26.0/dbhome_1
patch1.sid=ocp
That’s it.
Cheers,
Mike
Hi Mike, I’m trying to upgrade an instance from 19.25 to 19.26 on OL95, I even opened an SR because although the analyze mode finishes without problems, the deploy’s one gives several errors, and the support (SR opened more than a month ago, btw) says that it seems that the oraInst.loc file is missing once the golden image used to download the RECOMMENDED is extracted to the target_home. The support suggests that I create the golden directly from the default $ORACLE_HOME. In your opinion, is this approach correct or is there something missing during the creation of the target_home from LINUX.X64_193000_db_home.zip?
Hi Leonardo,
can you share the SR please with me?
You need to download the base image since we can’t download it for you from MOS since we don’t have access to it.
Use the default base release, fetch the additional patches with AU or download them manually – and then this should work nicely.
But pass the SR on to me, than somebody from the team can have a look at it.
Cheers,
Mike
Hi Mike,
3-39750614361. From support, about a week ago the status changed to “Development Working”. They also have open a bug (same behavior tested by support engineer)
Thanks for any “boost”.
Thank you!
Cheers,
Mike
Mike. Please. I know you can.. help Support because they don’t know what to do.
Hi Leonardo,
in fact the support engineer has nailed down the issue and mailed my colleagues in AU development already. I see it since he copy/pasted it into the Sr as an internal message. The US has a public holiday today (Memorial Day) – it will take 1-2 extra days until Ben will reply to the support guy. I sent our folks a message in addition.
Thanks for your patience, and trust me, this isn’t as easy as it looks at first sight.
Cheers,
Mike
Hi Mike, for your information, I’ve had to close the ticket in a bad way because the support team was unable to figure out the problem, even after escalating it internally, despite me providing dozens of log files, screenshots, etc., and months of “we’ll get back to you.” A truly awful experience. But I managed to fix it myself after stumbling across a MOS that indicated a similar error was caused by the missing oraInst.loc file under /u01/oraInventory. Once I copied/created the file there, everything worked perfectly. There should probably be an additional check during the analyze phase (for the existence of the file under that path) because it didn’t report any error.
Hello Mike. We have to apply ru patch in oír production databases. Can we use in-place autoupgrade in the same Oracle home? Or we must use out place upgrade? Is better use traditional opatch? Thanks a lot
Hi Carlos,
you can always use in-place upgrade. As a matter of fact, by default the database upgrade will happen in-place.
When you want to PATCH, meaning AutoUpgrade downloading and creating a new home for you, then patch or upgrade your database, then this can be done OUT OF PLACE only at the moment. In-Place patching is way more tricky since it required deinstallation of one-offs etc at first, and causes a way longer downtime. It may be supported at a later stage but for now.
Thanks,
Mike
Hi Mike,
Recently opened SR 3-40377326701 and I wondered if you could have a look and possibly comment.
Autoupgrade creates new 23ai database but new PDB is in RESTRICTED mode.
Upgrade is on OCI databases. Same Tenancy, Same VPN, Same Subnet. Different Database Servers.
Yes, I know there is an OCI remote clone procedure, but that failed for me as well.
Source database is vanilla 19c SE PDB with APEX installed. Target is vanilla 23ai SE PDB.
The issue is that the PDB is in RESTRICTED mode because the installed options are now at status UPGRADED rather than OPTION OFF which is true of the source.
In the SR , I document , in detail, the steps I took with AUTOUPGRADE and show what the error is.
In summary , new PDB :
Database option DV mismatch: PDB installed version 23.0.0.0.0. CDB is not installed or enabled.
COMP_NAME VERSION STATUS
————————————————– —————————— ———–
Oracle Database Vault 23.0.0.0.0 UPGRADED
Source PDB:
COMP_NAME VERSION STATUS
————————————————– —————————— ———–
Oracle Database Vault 19.0.0.0.0 OPTION OFF
Hi George,
I think this has been solved as far as I can see?
Cheers,
Mike
Hi Mike,
Thanks for getting back to me. This has indeed been solved. User (i.e. me) error. I was watching the upgrade log and believed that the upgrade had finished. I inadvetantly opened the PDB before the fixups were completed.
Maybe a comment at the end of the upgrade log to let your users know to be patient and that other work is still ongoing and to watch the alert log instead?
Thank you and the team again for all the exemplary work you are doing daily.
Thanks George – and I will check with the team whether we can improve this.
Cheers,
Mike
I have a 19.14OH and a 19.27OH already built with all recommended patches.
I want autoupgrade to update a database from 19.14OH to 19.27OH.
When I run analyze, I get the error “patch1.folder has no value defined in the user configuration file and it is a mandatory parameter”
The config file is:
global.global_log_dir=/oracle/app/oracle/base/autoupgrade
patch1.sid=qatmpl
patch1.source_home=/oracle/app/oracle/db/19.14.0.SI
patch1.target_home=/oracle/app/oracle/db/19.27.0.SI
What am I missing? I do not need to download patches or create a new OH for 19.27.
Hi Pedro,
if the above config file is your complete config file, then I don’t see either why this is failing. Are you 100% you are using THIS config file? AU would not ask about a folder in this case since the patch1.folder= parameter isn’t even there.
Cheers,
Mike
Hmm… If I take out the switch “-patch” and run autoupgrade as shown below, then everything works.
It seems like if the new Oracle Home is already created then we run autoupgrade as if this was an upgrade and not a patch update. Please confirm.
./myjava8 -jar /oracle/app/oracle/db/19.27.0.SI/rdbms/admin/autoupgrade.jar -config ./autoupg_qatmpl.cfg -mode deploy
Hi Mike,
Is it possible to download Combo patches, eg. for 19c Patch 39062956?
Regards,
Matjaz
Yes, it is – see here:
Config file:
============
global.global_log_dir=/Users/mdietric/TEMP/AU/logsglobal.keystore=/Users/mdietric/TEMP/AU/keystore
global.folder=/Users/mdietric/TEMP/AU/patches
patch3.platform=LINUX.X64
patch3.target_version=19
patch3.patch=39062956
patch3.gold_image=no
===============
Output:
| => java -jar autoupgrade.jar -patch -config gp.cfg -mode downloadAutoUpgrade Patching 26.4.260701 launched with default internal options
Processing config file ...
Loading AutoUpgrade Patching keystore
AutoUpgrade Patching keystore is loaded
Connected to MOS - Searching for specified patches
----------------------------------------------------
Downloading files to /Users/mdietric/TEMP/AU/patches
----------------------------------------------------
COMBO OF OJVM COMPONENT 19.31.0.0.260421 + GI RU 19.31.0.0.260421
File: p39062956_190000_Linux-x86-64.zip \ 3% ...
Cheers,
Mike
Hi Mike,
Thank you for your feedback.
That’s true. However, you still need to know the latest Combo patch number and specify it in the configuration file.
What I meant is that it would be more convenient if you could simply specify **COMBO** (or something similar) in the patch line, and the system would automatically identify the latest Combo patch and download it.
Hi Matjaz,
I already told the developers about it.
Cheers,
Mike
Hi Mike,
I’m trying to download the patch for 26ai Grid Infrastructure.
I’ve tried using this configuration:
patch1.target_version=26
patch1.platform=LINUX.X64
patch1.patch=RECOMMENDED,OCW
patch1.gold_image=NO
but I only get the DB RU, Data Pump, OPatch, and AutoUpgrade patches – no GI patch.
Am I missing something?
If I specify the patch number directly, it gets downloaded, for example:
patch1.patch=39568945
Thank you in advance.
Regards,
Matjaz
Thanks Matjaz,
I confirm your finding – this is VERY strange but I have an idea why that is.
Let me check with the MOS team.
And thanks for providing a valid workaround already.
Cheers,
Mike
Our environment has two permanent Oracle Homes already. We patch the inactive one, switch the DB to the patched Home, then apply the patch to the database. Then patch the previously used Oracle Home when all databases have been migrated off of it. We want to transition to using AutoUpgrade. In this scenario, is AutoUpgrade expecting our inactive Oracle Home to already be patched?
In this scenario, we patching from 19.31 to 19.32. We operate in a Legacy environment that doesn’t connect to MOS, so I’ve manually downloaded the relevant 19.32 patches in a patches folder. But when I run AutoUpgrade to patching in analyze mode, I get the following error: “The target ORACLE_HOME, [.target_home], does not have the necessary patches: RU, OPATCH, OJVM, DPBP. Specify a different target ORACLE_HOME directory.” All I can think is that AutoUpgrade is either ignoring my .folder parameter or AutoUpgrade is expecting .target_home to be already patched. I’ve just been following the process that has existed since I got to my current position, but is it best practice to delete the old Oracle Home after out-of-place patching? Any ideas, or should I submit an SR?
Config file is below:
global.global_log_dir=/oracle/cfgtoollogs/sqlpatch/autoupgrade
upg1.sid=omsrepo
upg1.folder=/oracle/product/19.3/autoupgrade/patches
upg1.platform=sparc.x64
upg1.download=no
upg1.source_home=/oracle/product/19.3/db_2
upg1.target_home=/oracle/product/19.3/db_1
upg1.patch=RU,OPATCH,OJVM,DPBP
Hi Jeff,
if I understand you correctly, you are patching in-place.
I.e., you take home 1 and apply the patches. This is your “working” home.
Then you take home 2 and apply the next/newer set of patches.
You switch your database from home 1 to home 2.
Then you are going to apply the next set of patches to “old” home 1.
And at some stage, you swing your database from home 2 to home 1.
Is my understanding correct?
If this is the case, AU won’t help you since AU does strictly “out-of-place” patching, meaning it creates a brand-new-fresh Oracle Home.
When you clean out and remove home 1 after you switched to home 2, you can keep the home naming as you had it.
Currently, AU does not clean up the home (this is in the making). But you can name the home and tag it as you have named/tagged it from before. AU allows you to override all the home parameters and defined them by yourself.
So, in your case above, you would remove /oracle/product/19.3/db_1 with the deinstall routine which cleans out the inventory of the OUI as well.
Then you can run the same as above, and it will install the software you want into db_1.
In the SPARC case, you must download the base release as well and store it into the patch folder you are using.
Since we don’t have Gold Images for 19c for SPARC, AU needs the base release.
I know, this sounds a bit of extra work.
But the benefit is that you get a fresh home without ballast, and patching runs faster.
Cheers,
Mike