My team mates work really hard. And I’m really proud on all of them. We try to fix upcoming issues or requirements with the new AutoUpgrade tool as quickly as possible and still maintain very high quality standards. And here it is, the September 2019 AutoUpgrade – and the AutoUpgrade video as a bonus in addition. Just in case you haven’t seen it in action and can’t join us at OOW 2019.
Download the September 2019 AutoUpgrade Tool
You can simply download the tool from MOS Note: 2485457.1 – AutoUpgrade Tool.
Watch the AutoUpgrade Video
I just uploaded the 12 minute video. It just covers the basics – for all the special things you can do with the AutoUpgrade, please see the section below.
AutoUpgrade – Step-by-Step
If you use the AutoUpgrade, make sure you browse through these blog posts as well. It guides you not only to the standard documentation but also to an increasing number of blog posts.
- 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
–Mike
Hi Mike,
Looking at your video the upgrade jobs looks and make life of a DBA very very simple. Having a life time experience using the Oracle database products I find it hard to believe it all but I will have a GO and keep you posted. Related to the 19c upgraded I am having two more questions :
-1- Does the db size mater for the duration of the upgrade ?
-2- What is the best way to upgrade a Data Guard configuration with onePhysical Standby database and a minimum of downtime ?
Best Regards,
Willy.
Hi Willy,
we have a good number of customers who use it already in production. Unfortunately, Upgrade is just a minor piece of the process – most time will be spend in testing. But at least we can reduce the DBA’s effort for a reoccuring a bit 🙂
Reg questions:
1- no, not all all – we don’t touch data. Main driver is the number of components in DBA_REGISTRY. But also AWR size can have an impact.
2- Please precise “minimum downtime”. You can use Transient Logical Standby (see our Upgrade / Migrate / Consolidate to 19c slide deck or MOS).
This usually gives you less than 5 minutes downtime – and you’ll end up with a physical standby database again.
Cheers,
Mike
Hi Mike,
I have the below doubts .
1. To minimize downtime ,can we use the auto upgrade option along with the transient logical method , where the actual upgrade runs in the logical standby databases .
2. Will auto upgrade take care of movement of oracle files (orapwd, spfile) from old db home to the new homes
3. Will the auto upgrade update the CRS with the new db home information
Anjith
Hi Anjith,
reg 1. Yes, you can.
reg 2. Yes, it does – even for the wallet
reg 3. Not yet – see my post about RAC and AutoUpgrade.
Cheers,
Mike
Thanks Mike ,
I had tested the autoupgrade locally ( source & target home in same server ) . But can we use the auto upgrade tool from a remote location.
For Eg ; If we want to use Server A as a central server from where we can call the autoupgrade.jar to upgrade databases running in Server B(source & target db home is in Server B) . Server A don’t have any databases to be upgraded . Oracle documentation is not mentioning anything about this scenario
Anjith
Why do you want to use it remotely?
There is no reason and no need for that.
The tool is small and you can easily deploy it everywhere.
If you need “central” than you can create a “central” config file which differs execution by a match of the hostname (instead of “localhost” your actual hostname).
Cheers,
Mike
Hi Mike! I enjoyed your presentation and lab on Autoupgrade at Open World and am looking forward to using it for my upcoming 12.1.0.2 to 19c upgrade. I am following your recommendations and best practices and am testing it, but just have a couple of questions/issues. I have created an SR but am not having much luck (I sense that the analyst isn’t really familiar with autoupgrade), so I hope it’s okay to ask a couple of questions here:
1. The analyze step warned me that my pga_aggregate_limit is too low for 19c. I ran the fixups step and it successfully increased the value for me (confirmed in the log file). But, when I ran the deploy step, it failed and I got an error that pga_aggregate_limit was still too low. I got past the error by manually increasing the value, but I’m confused about why I had to do that, when it seems like the fixups step should do it. (The fixups step did complete the other critical fixes successfully, such as removing a couple of parameters that are now obsolete in 19c.)
2. After I fixed pga_aggregate_limit manually, the upgrade got to 97% completed, but then it failed on ORA-29532: Java call terminated by uncaught Java exception, followed by 19 of these: ORA-38824: A CREATE OR REPLACE command may not change the EDITIONABLE property.
If you have any ideas, I would really appreciate it!
Patricia,
can you please share the SR number with me? mike.dietrich — at — oracle.com
Cheers,
Mike
Done! Thanks so much Mike!
Hi,
I have tried latest version of autoupgrade, but it fails in analyze step with There was an error initializing the patching information for entry upg1. It failed on UpgradeConfigDBValidator.findPatchInfo java.lang.ArrayIndexOutOfBoundsException: 4. I have created SR 3-21501947181 but no response yet. Maybe my database version 11.2.0.4.5 is too old.
Regards
Arnost
Arnost,
your database is not too old. But please update the SR.
Tell support which version of the autoupgrade you are using (you should use the most recent one).
And please upload the entire log directory.
Then Support can follow up. But you haven’t replied to Support’s question yet.
Cheers,
Mike
I think I had exactly the same problem as you, and from what I found out the problem is with the upgrade entries in the DBA_REGISTRY_HISTORY. One of the entries (a upgrade entry related to 11.2.0.3) had ID (null) and when I removed that row, the analyze ran like a charm. Not sure if this has some unwanted consequences somewhere though.
Did you get any feedback from Oracle on this issue?
Hi,
no feedback from Oracle yet. I have tried to update registry$history table (update registry$history set id=0 where id is null;) and analyze were completed successfully.
Regards
Arnost
Hi Arnost,
I dropped the engineer a message – I hope he’s getting back to you quickly.
And glad that Jon’s solution helped – but I think we need an official clarification. It’s clearly not an upgrade issue – but “upgrade” detects it. The problem seems to be this NULL value in the patch registry.
Cheers,
Mike
Regarding my solution,
I have ended up with a datapatch error later on in my upgrade process. This error occurs both with DBUA (where I don’t have to do the DBA_REGISTRY_HISTORY fix) and Autoupgrade, so I am assuming this error is related to the patch itself and not a consequence of the modification of DBA_REGISTRY_HISTORY. Still, it would be interesting to see what comes out of SR 3-21501947181 so I hope either you or Arnost can follow up with an update on this when Oracle resolves the issue.
I have just raised a SR about my failing upgrade, but I am pretty sure it will end up being about the patch and not Autoupgrade. The SR might be interesting for you though, as it deals with how patching is supposed to occur when you have to patch a database that is in the process of being upgraded. So if you want to take a look, the ticket is SR 3-21599538881.
Jon,
in order to clean up the situation at first (before rolling back anything) make sure your PDBs are all open, then run “datapatch -verbose” from your home environment. It should clear and correct all missing information. You will find a check_patches_18.sql script on my blog in the “SCRIPTS” section you may use to verify the contents of the patching tables inside the database.
Cheers,
Mike
Hi,
successfully upgraded 3 of 4 databases. Now I am stuck with Internal Bug # 30084975 – 19C UPGRADE FAILS WITH ERROR “ORA-01403: NO DATA FOUND”. It is time for new SR maybe.
Regards
Arnost
Hi Arnost,
is the database up and running?
The bug you are referencing is NON public for a simple reason: The root cause is not clear yet. And the database the bug (and SR) was logged for, was up and running. The bug got “only” filed to ensure that database is in healthy state. Hence, the bug tagline is wrong saying “upgrade fails”. The upgrade didn’t fail in this case.
Did Support point you to this bug?
Please check the upgrade logs for when and how the error happens.
Cheers,
Mike
Hi
Same issue I’m facing tonight and I found above update. Upgrade is from 11.2.0.4 (BP190416)
[oracle@anonymousdb01 autoupgrade]$ java -jar $ORACLE_HOME/autoupgrade/autoupgrade.jar -config $ORACLE_HOME/autoupgrade/anydb01.cf -mode analyze
AutoUpgrade tool launched with default options
There was an error initializing the patching information for entry upg1
[oracle@anonymousdb01 autoupgrade]$
[oracle@anonymousdb01 autoupgrade]$ cat autoupgrade_err.log
2019-11-19 21:36:03.441 ERROR 4 – UpgradeConfigDBValidator.findPatchInfo
java.lang.ArrayIndexOutOfBoundsException: 4
at oracle.upgrade.autoupgrade.config.UpgradeConfigDBValidator.findContainerPatches(UpgradeConfigDBValidator.java:396)
select * from registry$history where id is null;
ACTION_TIME ACTION NAMESPACE VERSION ID COMMENTS BUNDLE_SERIES
11.06.2016 13:48:46.240057 UPGRADE SERVER 11.2.0.4.0 Upgraded from 11.2.0.2.0
and yes, running this did fix the issue:
update sys.registry$history set id=0 where id is null;
Regards,
Henry
Hi Henry,
thanks a lot – and you are right, this is not an autoupgrade issue but autoupgrade is verifying this information and stumbling across it with a very “nice” error message. I will try to dig deeper and put something on the blog within the next days.
Cheers,
Mike