Yes, we did it again. A new version of AutoUpgrade has been released. With important fixes.
Download the May 2022 version
So it is time to update your AutoUpgrade and download the most recent version.
Changes / Fixes / Enhancements
As usual, we document the changes and fixes as well as the enhancements in the change log you’ll find in MOS.
At first, this is the new build:
build.version 22.3.220503 build.date 2022/05/03 11:55:20 -0400 build.hash 9e84e228 build.hash_date 2022/05/03 11:37:00 -0400 build.supported_target_versions 12.2,18,19,21 build.type production 20 bug fixes since v22.2 release Tag: V22.3 Description: This is the release for 22.3 on MOS
And these are the enhancements:
AUPG-2795 - Corrected unplug-relocate to use the local pdb name in analyze mode AUPG-2800 - Noncdbtopdb with relocation on the same system may produce error during analyze AUPG-2811 - Use term "AutoUpgrade keystore" instead of "keystore"
There is only one behavior change:
AUPG-2815 - Runtime error in pre-check was not stopping deploy and the status was reported as success
And of course you can find also the list of fixes:
AUPG-2753 - Support SEPS when used with WALLET_ROOT AUPG-2774 - setJobProtections failing intermittently due to ConcurrentModificationException AUPG-2786 - TDE Password check failing unexpectedly when wallet has OPEN_NO_MASTER_KEY status AUPG-2788 - Proactive fixups are not creating status files AUPG-2791 - AutoUpgDrainActions does not handle rerunnable exceptions properly AUPG-2793 - TARGET_CDB_COMPATIBILITY check failed due to no Container instance defined for the source noncdb in unplug/relocate AUPG-2806 - Failing to copy wallets because wallet_location has "" in the path AUPG-2812 - Enable local_undo on CDB upgrade fails because maximum db_files is reached AUPG-2813 - AutoUpgrade now checks for any plugin violations leaving PDBs left in open restricted mode and reports them accordingly AUPG-2817 - Wrong message printed when orabase utility fails AUPG-2822 - Database is shutdown when running custom post actions scripts in RAC AUPG-2848 - Pfile incorrectly written when had nested quotes and apostrophes AUPG-2833 - OracleBaseEvaluator throws a NullPointerException when using -load_password AUPG-2856 - Enable proactive fixups by default when distributed RAC is enabled and proactive fixups are not defined BUG-34033745 - SOURCE_BASE is not taking effect in initial autoupgrade queries when ORACLE_BASE is set to a space BUG-34075960 - AutoUpgrade failed with string index out of range and FILE_COPY option equal to NONE.
–Mike
Hi Mike,
one question. We just trying to migrate an instance from 11.2.0.4 to 19.11 with this most recent version of AutoUpgrade. We are running into UPG-1321.
In the autoupgrade.log we’ve gotten the following error
2022-05-13 17:03:06.419 INFO [ADC967] Errors executing [/* ADC967 */select count(*) from sys.dba_invalid_objects where oracle_maintained=’Y’;
select count(*) from sys.dba_invalid_objects where oracle_maintained=’Y’
*
ERROR at line 1:
ORA-00904: “ORACLE_MAINTAINED”: invalid identifier
] [DBNG] – SQLClient.run
Do you have an idea what could be wrong?
Quick Google search revealed that ORACLE_MAINTAINED seems to be existing since 12c (which we never used). Given that is true, it makes me think this must be an issue with the AutoUpgrade…
Do you have an idea what’s wrong?
Hi Daniel,
I guess you are using the most recent version of AutoUpgrade, right?
If you do so, then please open an SR and upload the logs:
java -jar autoupgrade.jar -config myconfig.cfg -zip
Support needs to look at this.
Thanks
Mike
Thanks
Hello Mike,
Congratulation for your tool.
I have one question, we want to move datafiles from the source PDB’s datafile to the target CDB.
I see this option : prefix.target_pdb_copy_option=file_name_convert=NONE, it copies datafiles, but it lets the datafiles in the source CDB.
Is there any option like “prefix.target_pdb_move_option=file_name_convert=NONE” ?
Thanks.
Regards,
Gildas.
Hi Gildas,
the “NONE” is used for ASM since then ASM with OMF takes over control. There is no such “move” option in AU if you are in ASM. But you can easily use the Online Move of datafiles if you desire to.
ALTER DATABASE DATAFILE MOVE command:
ALTER DATABASE MOVE DATAFILE ( ‘filename’ | ‘ASM_filename’ | file_number )
[ TO ( ‘filename’ | ‘ASM_filename’ ) ]
[ REUSE ] [ KEEP ]
Cheers
Mike
Hi Mike,
is there a new video about the autoupgrade tool?
A fee weeks a ago I found one.
As far as I remember You showed some nice features like new handling of analyze, fixup and upgrade.
However, I can’t find I t
Regards
Christian
Hi Christian,
please scroll down towards the end:
https://mikedietrichde.com/videos/
Episode 14 is it.
Cheers
Mike
Hi Mike
Thanks alot.
Will there be an Episode 15 soon? 😉
Cheers
Christian
Coming in December most likely – we are checking our schedule for it this week.
Cheers
Mke
Hi Mike
Thanks for the info…
We’re very keen to see it 😉
Cheers
Christian
Hi Mike,
autoupgrade works really cool. Today, I have seamlessly upgraded and converted a NON-CDB 12.2 SE2 database into a PDB in a 19c CDB.
Encouraged by this success, I am now trying to do another NON-CDP to PDB from 12.2 EE to 19 EE. But this time, it fails during the “analyze” phase. The error is “TDE_PASSWORDS_REQUIRED”. What I do not understand is that the source database doesn’t use TDE. According to my info, TDE is not enabled at all in our in-house databases. How does it come this autoupgrade check fails?
Do you have a tip how to workaround?
Hi Reiner,
did you open an SR? Or please try the previous AutoUpgrade fromt he same MOS note where you can download the most recent version from (scroll down to the bottom of the note).
Mike
Thanks Mike. No, I haven’t opened up a SR. To be honest: The database was not valuable. I have used a freshly installed PDB instead.
This happened to me only once. And yes, the tip using an older version of “autoupgrade” is a good one. This saved me while doing another non-cdb to ppdb conversion.
Overall, this is just working great!
Thanks Reiner!
Cheers
Mike
Hi Mike,
we are just whatching your Video Autoupgrade 14.
Great stuff – as everything on Your Channel.
Something confused us – at first:
You turn off Apply before creating an restorepoint, than turn apply on again.
Well, this seems to be by the book (aka Oracle Docs)
But what should be pointed out more clearly we think:
If we issue an garanteed restorepoint on primary, it’s replicated to standby.
However, on standby it will be an “normal” restorepoint.
Therefore, it must be set on standby “by hand” to be a garanteed one.
Did we get it right?’
Cheers Christian
Let me check with Daniel, Christian. And if I don’t get back again, then you are 100% right.
The root cause is the propagation of the GRPs which has changed in releases as far as I remember.
Cheers,
Mike
See here:
https://dohdatabase.com/2022/08/23/upgrade-data-guard-and-restore-points/
Cheers
Mike
Hi Mike
Thanks a lot!
Cheers
Christian
Hi Mike
Using Databaselink and refresh for migration is realy great.
Now consider this scenario:
We’ve got some 19non multitenant dbs, big ones.
We set up an config file like this:
global.autoupg_log_dir=/home/oracle/upgrade19pdb
upg1.log_dir=/home/oracle/upgrade19pdb
upg1.sid=DBR19npdb (that’s nonmultitenant)
upg1.restoration=no
upg1.source_home=/u01/app/oracle/product/19c/home2
upg1.target_home=/u01/app/oracle/product/19c/home2
upg1.target_cdb=DBR19 (That’s the cdb to plug in)
upg1.source_dblink.DBR19npdb=CLONENONPDB19 300
upg1.target_pdb_name.DBR19npdb=nowpdb (That’s the name of the pdb to create)
upg1.target_pdb_copy_option.DBR19npdb=file_name_convert=NONE
upg1.start_time=+45m
Is this supported?
Thx
Christian
Yes, that is supported. But I would recommend you a later start time in case the database is large.
Cheers
Mike
Hi Mike
We are thinking about this scenario:
We’ve got an 12.2 Database (no pdbs) and need to upgrade to 19 with PDBs
Problem is, there is an dataguard system running.
Let’s say the 12 DB is named DBR12, the 19 DB should be named CDBDBR19 with PDB PDBR19.
With no dataguard I could handle it easy, even with cloning the database via databaselink before upgrade.
However, in dataguard I see trouble – even if we do not clone.
The name of the service of source database will change from DBR12 to CDBDBR19.
Data Guard uses the the service to connect to the datababase (via alias in the tnsnames.ora), if I’m correct. How to handle this?
I think the only way is to first setup an replication for the new CDB, making sure that the creation of pdbs is NOT replicated. Then we do an upgrade on source system.
After the upgrade we’ll create the pdb in the standby via
“restore pluggable database”
Hope I could figure out the problem.
Christian
Hi Christian,
please see our Virtual Classroom Seminars, Episode 4 (Multitenant) for the plugin portion when you move from non-CDB to CDB with a standby in place:
https://mikedietrichde.com/videos/
Furthermore, when you are there, see Episode 14 (AutoUpgrade 2.0) in the STANDBY chapter for further things to know.
Cheers,
Mike
Hi Mike
Sorry 😉
After taking a close look on the tutorials I got the answer.
Cheers
Christian
Hi Mike,
sorry for another question.
We’ve got an dataguard release 12.2 running.
Now, we want to do something like this.
Add another replikation to this configuration, however target would be an 19.17.
Then, we would like to decconfigure the replication and start the 19.17.
To do this, we have to run the upgrade before we can open 19.17.
(for example autoupgrade -mode upgrade.)
DocId 785347.1 says:
From Oracle Database 11.2.0.1 it is possible to configure the Physical Standby database with at a higher patchset or major release Primary database for purposes of a migration to new hardware
provided that after a switchover to that standby, the database is not allowed to open and is immediately upgraded in the normal manner.
This confuses me…
In the first step, I would duplicate the 12.2 into 19.17 and then set up DG, that’s fine.
But:
When I do an switchover, the standby becomes the primary – and therefore is open by the Dataguard Process.
Can you give me a helping hand again?
Thx
Christian
Hi Christian,
the devil is in the detail: This technique is sufficient to MIGRATE to a new hardware. But it is not capable of a switchover.
If you want to do what you want with a physical standby, you need to create a Transient Logical Standby setup where you use your physical standby, and convert it back after a while.
Cheers,
Mike
Hi Mike
Thanks, that put it strait.
Cheers,
Christian
welcome 🙂
Cheers
Mike