Since last night, the new version of the AutoUpgrade utility is available. Please download the new July 2019 (20190715) AutoUpgrade and exchange your previous version in your destination
$ORACLE_HOME/rdbms/admin with this one.
Please download the tool from: MOS Note: 2485457.1 – AutoUpgrade Tool
When you copied the new tool, call it for a version check to make sure you are using the most recent one:
$ java -jar $OH19/rdbms/admin/autoupgrade.jar -version build.version 20190715 build.date 2019/07/15 12:45:48
Please notice that the tool allows you to upgrade to Oracle 184.108.40.206 and Oracle 18c as well:
The listed releases are the minimum releases you can upgrade to. Minimum source version is Oracle 220.127.116.11.
What we fixed and improved
But why should you take the new tool? Take it because we fixed 26 issues to the June version. At the end of the MOS Note you find a text file called BUGS_20190715. This file contains all the fix descriptions included into this and of course the previous versions, too.
Especially for RAC environments,
cluster_database will be kept now at
FALSE until the very end of upgrade completion. The same behavior fixes issues with unsupported parameters which caused trouble during the restart of the database. But please, browse the list by yourself.
AutoUpgrade – Step-by-step
- The new AutoUpgrade Utility – Download, documentation and supported versions
- Create and adjust the config file for AutoUpgrade
- Config file for AutoUpgrade – Advanced options
- Config file for AutoUpgrade – Tweaking init parameters
- AutoUpgrade: ANALYZE, FIXUPS, UPGRADE and DEPLOY modes
- AutoUpgrade: Where do you find all the logfiles?
- UPG: The AutoUpgrade Command Line Interface
- Upgrading Multitenant databases with AutoUpgrade
- Moving to a new server with AutoUpgrade
- How to tweak the hidden settings in AutoUpgrade
- AutoUpgrade and Data Guard, RAC, Restart and non-CDB to PDB
- AutoUpgrade and Wallets
Hello, Mike! 19.4 was released recently. I read, it supports 19.3. Would it proper work with 19.4 target release?
Of course – it works with 19.3 and higher!
And we’ll phrase it more clear in the note!
To check if the source database is ready for upgrade, which is better, Autoupgrade or preupgrade? I do not want to use Autoupgrade just yet, since it is relatively new.
AutoUpgrade – trust me!
“New” doesn’t mean “new” in the typical sense – we tested it with 13 high profile customers through 2 beta phases. We have customers using it in production massively already.
It has some limitations (blog post soon – most likely tomorrow) but it works VERY well.
I fully trust your word. It is time tested.
I am sorry for not framing the question properly. I do not want to use Autoupgrade for upgrading the databases yet. I have tested DBUA and it does everything very well. It creates a GRP, I do not need to set CLUSTER_DATABASE=FALSE for RAC (all our databases are RAC), it upgrades the Timezone file, performs all post-upgrade actions…So, I guess first question would be: what does Autoupgrade offer over DBUA (other than scheduling capability)?
My problem with upgrade is that Oracle has too many different utilities to check for upgrade readiness. They ask to run Exachk, dbupgdiag, preupgrade.jar, then there are things they ask to check manually by running queries…Why not roll these checks into a single utility? The recommendations from these tools can never be 100% fulfilled. So, from a pre-upgrade perspective, does Autoupgrade run more checks than pre-upgrade.jar?
the DBUA settles exactly on the facility we provide: preupgrade.jar. The OraCHK people embed our checks quickly as well to allow OraCHK perform the same tests.
AutoUpgrade takes care on cluster_database as well – but not on the srvctl part yet (will be available later).
If you are happy with the DBUA, all is fine. I just had my share of experience with it 😉 And have it almost once per week …
Well, there are a lot of things the DBUA can’t do, for instance upgrading several databases in the same home in parallel. Or do a fallback after the tool failed.
So yes, AutoUpgrade offers more flexibility and a much easier handling: One config file, one call. You can script and schedule it. You don’t need a GUI.
But we don’t force you 🙂