All of you upgrading your databases with AutoUpgrade or planning to do so can now download the newest version of our AutoUpgrade tool. We are offering the 20191220 version. If you ask yourself why we release the December version in January 2020, there’s a simple answer. We do extensive system testing with it before releasing it to the public.
Photo by pixel | visuals – Patrick Humm on Unsplash
Download 20191220 AutoUpgrade
You can always download the newest and some previous versions of the AutoUpgrade tool via this note:
At the bottom of the note you’ll find the previous version as well, just in case the current one has an issue we didn’t detect. Or you did your upgrade testing with one of the previous versions and need to download it again.
And of course, you find also the changelog with the fixed issues in each release.
Further Information
–Mike
We will be going to 19c from 11.2.0.4 that is running EBS. Oracle support told us NOT to use autoupgrade and instead use DBUA. We would prefer using autoupgrade after reading all of the good information about it.
Hi Jeffey,
the EBS upgrade not is scripted for DBUA with several workarounds. Hence, I guess you need to follow their guidelines as EBS doesn’t allow much flexibility for mind-driven decisions. We told the guys to use AutoUpgrade but as far as I know, it gets tested right now. I can’t tell you when or if ever the EBS note will be updated. I put a lot of review comments into the note but not sure if it has been adjusted.
Cheers,
Mike
Hi Mike
I’m trying to upgrade from 12.2.0.1 to 19.5.0.0 with the latest autoupgrade.jar.
During the POSTFIXUPS stage I get an UPG-1604
Digging around I found the following Error in the autoupgrade_20200120_user.log:
Adding patches to installation queue and performing prereq checks…done
Installation queue:
For the following PDBs: PDBTEST
No interim patches need to be rolled back
Patch 30125133 (Database Release Update : 19.5.0.0.191015 (30125133)):
Apply from 19.1.0.0.0 Feature Release to 19.5.0.0.0 Release_Update 190909180549
The following interim patches will be applied:
30128191 (OJVM RELEASE UPDATE: 19.5.0.0.191015 (30128191))
Installing patches…
Patch installation complete. Total patches installed: 2
Validating logfiles…done
Patch 30125133 apply (pdb PDBTEST): WITH ERRORS (RU)
logfile: /u00/app/oracle/cfgtoollogs/sqlpatch/30125133/23151502/30125133_apply_DB12OP17_PDBTEST_2020Jan20_08_43_16.log (no errors)
ru_logfile: /u00/app/oracle/cfgtoollogs/sqlpatch/30125133/23151502/30125133_ru_apply_DB12OP17_PDBTEST_2020Jan20_08_43_14.log (errors)
-> Error at line 297: script RU_apply/RU_rollback for 30125133/23151502
– ORA-04068: existing state of packages has been discarded
– ORA-04061: existing state of package body “SYS.DBMS_REGISTRY_SYS” has been
– invalidated
– ORA-04065: not executed, altered or dropped package body
– “SYS.DBMS_REGISTRY_SYS”
– ORA-06508: PL/SQL: could not find program unit being called:
– “SYS.DBMS_REGISTRY_SYS”
– ORA-06512: at “SYS.DBMS_REGISTRY”, line 2798
– ORA-06512: at line 1
Patch 30128191 apply (pdb PDBTEST): SUCCESS
logfile: /u00/app/oracle/cfgtoollogs/sqlpatch/30128191/23093535/30128191_apply_DB12OP17_PDBTEST_2020Jan20_08_43_15.log (no errors)
It seems I hit a known error from the patch (Doc ID 2568305.1) which says just to run datapatch -verbose a second time, but since I’m using autoupgrade how should I handle this recommendation?
Regards
Franco
Hi Franco,
did the database upgrade successfully or did the tool error out and exit?
Thanks,
Mike
Hi Mike
In the meantime I stripped down my test environment, now I have only a CDB and the PDB$SEED on 12.2.0.1 and the target version is 19.3.0.0 (so I dont apply any patches myself to the target)
Upgrade is OK in logfile:
+———+—————————————–+
|CONTAINER| PERCENTAGE|
+———+—————————————–+
| CDB$ROOT|SUCCESSFULLY UPGRADED [db12op17-cdb$root]|
| PDB$SEED|SUCCESSFULLY UPGRADED [db12op17-pdb$seed]|
+———+—————————————–+
It seems something went wrong with applying the patches, querying PDB_PLUG_IN_VIOLATIONS gives en ERROR
19.3.0.0.0 Release_Update 1904101227: APPLY with status WITH ERRORS (RU) in the PDB
and then PDB$SEED is only opened in restricted mode.
To be honest I already opened a case (3-21908522281) but unfortunately till now we didn’t find the problem and I was hoping you could give me a hint.
Regrads
Franco
Franco,
this is a known issue – you’d fix it by running “datapatch” a second time. Or – easier and better – when you apply 19.6.0 to your home, and then run the upgrade. Then the datapatch issue should not happen again as far as I know.
Cheers,
Mike
PS: Please apply 19.6.0 and don’t go to 19.3.0. 19.3.0 is from April 2019 – code freeze was almost 1 year ago. We fixed some crucial issues afterwards.
Great
19.6.0 did it.
autoupgrade works when the target HOME is 19.6.0
Thank you Mike
Hi Mike,
We are using 2 Oracle 12.2.0.1 single servers, last week I received a notice from Oracle regarding the latest 12.2.0.1.0 database Jan 2020 RU 12.2.0.1.200114 (patch 30593149), I’ve applied it successfully, at the same time I also noticed the database Jul 2019 RUR 12.2.0.1.200114 (patch 30446254), shall I apply the this revision patch please?
Vielen dank fuer Hilfe!
Nope – please take the January 2020 RU – not the RUR.
See https://mikedietrichde.com/2018/11/08/why-release-update-revisions-rur-are-tricky/
Cheers,
Mike
Hi Mike,
we are trying to upgrade from Oracle Database 12.2.0.1 (2-node-rac) to 19c with AutoUpgrade.
In our database we have apex 19.2 installed only in pdb as recommended by you.
We are using the actual AutoUpgrade Version:
“build.hash 6b4cba8
build.version 19.7.4
build.date 2020/01/21 18:31:03
build.max_target_version 19
build.type production”
But when starting AutoUpgrade analyze we receive following error:
“AutoUpgrade tool launched with default options
Processing config file …
There were conditions found preventing AutoUpgrade from successfully running
*Mismatching components
The PDB [Pxxxxx] contains the following components [APEX Oracle Application Express] which are not present in CDB$ROOT cxxxxx1, Install missing components in CDB$ROOT before proceeding.”
I don’t think that installing APEX into cdb should be the solution.
Regards
Stefan
PS: We already opened a SR (SR 3-22020460881) for this issue
Hi Stefan,
you are the 2nd one raising this today to me – I’ll get this to the team asap.
Cheers,
Mike
Hi Mike,
thanks for your reply.
Oracle support requests us to install same apex version in cdb and pdb which is in contradiction to your recommendation apex never to install in cdb.
So we are in doubt that this is the correct approach. We are quite sure that the cause for this issue is an erroneous check of installed components in autoupgrade tool.
Do you have news about this issue from your team?
I’m quite a bit nervous about this issue as we have a deadline on Feb. 10th and we want to do some testing before this date.
Regards
Stefan
Hi Stefan,
as we went on without Support, here’s an update for everybody in case you are interested.
1. Initial Problem
—
Autoupgrade reported an issue as APEX was installed in the PDB only but not in the CDB.
This is something not only I recommend for years for several reasons but of course allowed.
2. Solution
—
AutoUpgrade got fixed. It incorrectly triggered this ERROR. In this specific case, there’s an “Everything At Once” upgrade of a CDB with PDB(s). No such error should have been thrown. Customer received already a patched version – the fix will be included in the next uploaded version.
3. Support
—
Well, this is the frustrating part. Support at first didn’t understand the problem, and then gave the wrong recommendation (Please install APEX in the CDB$ROOT, too). Of course, this may have remedied the current case and allowed to close the SR, but there would have been several issues afterwards.
Cheers,
Mike
Hi Mike,
many thanks for your assistance and provisioning an AutoUpgarde version over night which solved our problem!
I acknowledge that in this case (again) it was very frustrating to work with Oracle support.
Best Wishes
Stefan
Hi Stefan,
thanks for your feedback – and we try our best 😉
Cheers,
Mike
Hi Mike,
Thank you very much for such a awesome blog! I’m running autoupgrade to upgrade a 12.1.0.2 to 19c. The compile step after upgrading took lot of time:
11:15:09 SQL> DECLARE
11:15:09 2 threads pls_integer := &&1;
11:15:09 3 BEGIN
11:15:09 4 utl_recomp.recomp_parallel(threads);
11:15:09 5 END;
11:15:09 6 /
PL/SQL procedure successfully completed.
Elapsed: 01:47:05.27
And I found that it is done in paralell degree of 8:
11:15:09 8 IF cnt > 0 THEN
11:15:09 9 :utlprp_name := ‘/oracle/oracle12/productRDBMS_19/rdbms/admin/utlprp.sql 8’;
11:15:09 10 :utldtchk_name := ‘/oracle/oracle12/productRDBMS_19/rdbms/admin/utldtchk.sql’;
11:15:09 11 END IF;
We had, in our database, lots of events like this:
cursor: pin S wait on X
cursor: pin S wait on X
SQL*Net message to client
cursor: pin S wait on X
library cache pin
cursor: pin S wait on X
cursor: pin S wait on X
Is it possible to modify the parallel degree or is it hardcoded? Any other possibility to avoid this events?
Thank you very much Mike for your help!
Kind regards,
José Antonio
Hi José Antonio,
I doubt that this has to do with the number of slaves. I furthermore suspect that it may be related to this one here:
https://mikedietrichde.com/2018/09/11/oracle-12-2-and-higher-set-_cursor_obsolete_threshold-to-old-default/
Having tons of “cursor: pin S wait on X” wait events is a typical indication for this “present” from the Multitenant team.
Cheers,
Mike
Hi Mike,
Thanks for your help! I’ll check it out.
Kind regards,
Mike
Hi Mike,
It seems we have the same issue as Stefan running upgrade tool (19.7.4 version) “The PDB [PDBNAME] contains the following components [APEX Oracle Application Express] which are not present in CDB$ROOT XXX, Install missing components in CDB$ROOT before proceeding. ”
We are trying to upgrade from 12.2.0.1 to 19.5.0.0 RAC one on Exadata. Version 19.7.2 seem to work just fine but would be nice to use the latest upgrade tool.
If we also could have the patched version it would be much appreciated as we have several cdb´s to upgrade.
Please let me know if you want me to create a SR.
Regards
Lars
Hi Lars,
I’ll drop you an email.
Cheers,
Mike
Hi Mike,
Sounds great
/Lars
Hi Lars,
let me know if you DIDN’T receive the file. Our mailgateway is sometimes a bit “strange” and does not tell me once an email got rejected …
Cheers,
Mike
Hi Mike,
Aha, sorry to say but I have not received any file.
/Lars
Thanks – our lovely mailgateway …
I’ll send you another message – cheers,
Mike
Thank you Mike
The script work just fine – case closed.
Much appreciated
/Lars
Hi
Mike, we are running 12.1.0.2 to 19.6 upgrade. 12.1 is not cdb/pdb. Can autoupgrade do the upgrade and than plug upgraded instance into cdb/convert to pdb. I tried going through your posts and documentation but don’t see how to set this up. Please, point me if I am missing something obvious.
Regards,
Artem
Hi Artem,
yes it can. You need to create the CDB at first, then you add
target_cdb=
to the config file.
Please see the Hands-On Labs instructions for an example:
https://mikedietrichde.com/hands-on-lab-autoupgrade-to-oracle-19c/
Cheers,
Mike
PS: THis is currently BETA functionality we will release later this year officially – we add some extra features to it to give you more flexibility and do more checks.
PPS: Make sure you create your CDB with the same options you have in DBA_REGISTRY on your current 12.1.0.2 database
Hi, Mike thank you for pointing this out. Our database has tde enabled and we are struggling with upgrade&plug in shot using autoupgrade. Can you, please, provide example for tde enabled database ?
Regards,
Artem
Hi Artem,
you must copy the wallet to the new home – and I think the wallet must currently be set to autologon.
Let me know if you need more information – I have it somewhere …
Cheers,
Mike
Hi
Mike, what we found is that you need to export key from non-cdb before conversion. and after conversion you need to import key back. like an example here: http://www.oaktable.net/content/converting-non-cdb-database-pdb-when-tde-use Not sure how this is handled in autoupgrade. If you can share moe information that will be much appreciated. Artem
Hi,
Thanks for good session at OOW – London!
Using autoupgrade (newset version) going from 11.2.0.4 to 19.5 I face problems regarding the XML DB (everything valid before upgrade):
10:12:53 23 /
XINCLUDEXSD BFILE := dbms_metadata_hack.get_bfile(‘xinclude.xsd.12.1’);
*
Fel p? rad 5:
ORA-06550: rad 5, kolumn 24:
PLS-00201: identifierare ‘DBMS_METADATA_HACK.GET_BFILE’ m?ste vara deklarerad
ORA-06550: rad 5, kolumn 15:
PL/SQL: Item ignored
REASON:
ERRORS FOUND: During Upgrade
FILENAME: /home/oracle/upg_logs/employee/BALA/103/dbupgrade/catupgrd20200225101220bala0.log AT LINE NUMBER: 149858
——————————————————
Identifier XDB 20-02-25 10:12:53
SCRIPT = [/u01/app/oracle/product/19c/dbhome_1/rdbms/admin/xdbud121.sql]
ERROR = [PL/SQL: Item ignored ORA-06550: rad 9, kolumn 3:
PLS-00201: identifierare ‘DBMS_METADATA_HACK.CRE_DIR’ m?ste vara deklarerad
ORA-06550: rad 9, kolumn 3:
PL/SQL: Statement ignored
ORA-06550: rad 11, kolumn 49:
PLS-00320: typdeklarationen for detta uttryck ar ofullstandig eller felaktigt utformad
ORA-06550: rad 11, kolumn 5:
PL/SQL: Statement ignored
]
STATEMENT = [as above]
Anything you have seen before?
Regards
Peter
Hi Peter,
you need to open an SR please. It could be that XDB is invalid (my guess) and you may have to rebuild XDB.
But please check with Support – I haven’t seen this before (and don’t hesitate to open this as a Sev1 (non 24×7).
Cheers,
Mike
Hi,
Doc ID 2506690.1 was the answer here. I had only found the other doc when the user had to be locked for the error to occur.
Upgraded to 19.5
Regards
Peter
Thanks for the update, Peter!
Cheers,
Mike