In my previous blog post I demonstrated how you can upgrade with AutoUpgrade between two servers. This a very typical scenario where you get new server, often also with a newer operating system version installed. But I was wondering if you can use Oracle AutoUpgrade between two servers – and Plugin?

Photo by Frederick Tubiermont on Unsplash
AutoUpgrade between two servers
Please see my previous blog post about all the details:
Upgrade and Plugin?
At the end of it, I was curious if I couldn’t just plugin afterwards. But I failed at first.
It turned out that I needed a slight change in actions and parameters. And it works smoothly.
Starting point is again my DB12 database, but now upgraded to Oracle Database 19.8.0. And I have an existing container database, CDB2, up and running in 19.8.0 as well.
Adjustments to the config file
I recycle my config file but make some adjustments:
- source_home
- target_cdb
- target_pdb_name
I certainly could have added target_pdb_copy_option as well. But I wanted to have my files stay in place.
This is how my config file DB12NEW.cfg looks like now:
global.autoupg_log_dir=/home/oracle/logs upg1.dbname=DB12 upg1.start_time=NOW upg1.source_home=/u01/app/oracle/product/19 upg1.target_home=/u01/app/oracle/product/19 upg1.sid=DB12 upg1.log_dir=/home/oracle/logs upg1.upgrade_node=localhost upg1.target_version=19 upg1.restoration=no upg1.target_cdb=CDB2 upg1.target_pdb_name=PDB1
Call it with DEPLOY
The secret to make this work is now that you must have the database open regularly – and use -mode deploy to start the plugin.
I kick it off with:
java -jar $OH19/rdbms/admin/autoupgrade.jar -config DB12NEW.cfg -mode deploy
After a few minutes, I receive confirmation from the AutoUpgrade job console:
$ java -jar $OH19/rdbms/admin/autoupgrade.jar -config DB12NEW.cfg -mode deploy AutoUpgrade tool launched with default options Processing config file ... +--------------------------------+ | Starting AutoUpgrade execution | +--------------------------------+ 1 databases will be processed Type 'help' to list console commands upg> lsj +----+-------+-----------+---------+-------+--------------+--------+------------------+ |Job#|DB_NAME| STAGE|OPERATION| STATUS| START_TIME| UPDATED| MESSAGE| +----+-------+-----------+---------+-------+--------------+--------+------------------+ | 101| DB12|NONCDBTOPDB|EXECUTING|RUNNING|20/07/31 17:23|17:23:39|Executing describe| +----+-------+-----------+---------+-------+--------------+--------+------------------+ Total jobs 1 upg> Job 101 completed ------------------- Final Summary -------------------- Number of databases [ 1 ] Jobs finished successfully [1] Jobs failed [0] Jobs pending [0] ------------- JOBS FINISHED SUCCESSFULLY ------------- Job 101 for DB12
Let me check this …
It really works. Very cool!
But let me check my receiving CDB:
[oracle@hol auto]$ . cdb2
[CDB2] oracle@hol:~/logs/cfgtoollogs/upgrade/auto
$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Fri Jul 31 17:42:58 2020
Version 19.8.0.0.0
Copyright (c) 1982, 2020, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.8.0.0.0
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB1 READ WRITE NO
SQL>
Here we go – plugged in safely! It has a new name now. But still the old files which you can easily rename and move around if needed:
SQL> alter session set container=pdb1; Session altered. SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- /u02/oradata/DB12/system01.dbf /u02/oradata/DB12/sysaux01.dbf /u02/oradata/DB12/undotbs01.dbf /u02/oradata/DB12/users01.dbf
Further Information and Links
- Oracle AutoUpgrade between two servers – Aug 3, 2020
- More Information on AutoUpgrade’s TARGET_PDB_COPY_OPTION – July 21, 2020
- MOS Note: 2485457.1 – AutoUpgrade Tool
–Mike
This is a pretty cool feature, something I’ve been doing manually with scripts for a while. I’m curious, can the auto upgrade tool also upgrade by unplugging a PDB from a lower version CDB and plugging it in to a higher version CDB?
Hi Brooks,
we are working on unplug/plug/upgrade with highest priority. So it will be there soon.
Thanks,
Mike
Hi Mike,
thanks for Your WEBCAST on 17.08 about PDBs.
I came to the conclusion autoupgrade can help me here:
I’ve got an 19.6 nonCDB database and want to convert it into an cdb.
So I have to setup an empty CDB.
Then I define an configfile like this:
upg1.dbname=DB19Q
upg1.start_time=NOW
upg1.source_home=/u01/app/oracle/product/19c/home1
upg1.target_home=/u01/app/oracle/product/19c/home1
upg1.sid=DB19Q
upg1.target_cdb=DB19Z
upg1.target_pdb_name=PDB19
upg1.log_dir=/u01/app/oracle/product/19c/home1/rdbms/admin/upg_logs
upg1.upgrade_node=sts.darkwing.net
upg1.target_version=19
upg1.restoration=no
Would this do the trick?
I run into this error: [DB19Q][TARGET_CDB_COMPATIBILITY][ERROR]
Thanks
Christian
Hi Christian,
the CDB needs the same components than your non-CDB – and it this case, it has to be a 19.6.0 as well.
But there may be two nits:
1. I haven’t verified it with 19.6.0 – I know that it works with 19.8.0
2. You may need to check to have the newest AU version – this functionality came in just with the July 2020 one.
Otherwise you will need to drill to the logs to find out what the compatibility issue is.
Cheers,
Mike
Hi Mike
Yeah, Admin to stupid-error. 🙂
Thanks a lot
Christian
Hi Mike,
What about upgrading database 11g on Oracle Linux 6 with File System storage to 19c on Oracle Linux 8 and ASM(Grid Infrastructure) type?
How to transfer data files to new server and is there a specific option to use in AU config file?
Do we need double size of source datafiles on new server?
See my other answer: RMAN.
Cheers
Mike
Hi Mike,
What about upgrading from File System(source database) to ASM (new server)?
Do we need double size of source data files on new server?
Source : OEL 6 – Database 11g ( File System )
target : OEL 8 – Grid infrastructure 19c and Database 19c (ASM)
Very simple – you restore with RMAN into ASM, and then you upgrade.
If you want this with less downtime, you will have RMAN to create a standby, then you do the steps as indicated in the blog post.
AutoUpgrade does not move your database (unless you don’t migrate into a PDB).
Cheers,
Mike
thanks,
but database 11g not supported on OEL 8 so I can not create standby.
And if I want to migrate my 11g database from File System on OEL6 to 19c as a PDB (ASM) on OEL8, what are the steps?
Please check the certification matrix on MOS:
Oracle Database 11.2.0.4.0 is certified on Linux x86-64 Oracle Linux 8
Cheers,
Mike
You are right, Thank you so much
Welcome 🙂
Cheers,
Mike
Hi Mike,
Thanks for great post. As I read the official documentation (https://docs.oracle.com/en/database/oracle/oracle-database/19/upgrd/understanding-non-cdb-to-pdb-upgrades-autoupgrade.html#GUID-D739E4A4-F1B9-45BE-B0E2-F213FE70F665) this functionality you illustrate on 19.8 is first supported for 21c. So what is up and down 🙂 ? Is this supported for 19c as well?
Hi Brian,
this is generally supported.
Cheers,
Mike
Hi Mike,
I am trying to upgrade database from 12.2 to 19c having mutiple pdbs.
below is my config file. but when I am trying to analyze it getting error. can you please help to prepare the config file having multiple pdbs. PDB name we like to keep same as source? Autoupgrade version is 23.4
## db1 parameter ##
upg1.log_dir=/opt/bt/oracledb19c/autoupgrade
upg1.sid=SBXTTS
upg1.dbname=SBXTTS
upg1.pdbs=pdb1,pdb2,pdb3.pdb4
upg1.source_home=/app/oracledb-12c/product/12.2/db1
upg1.target_home=/app/oracledb19c/product/19/db1
upg1.start_time=NOW
upg1.upgrade_node=****************
upg1.run_utlrp=yes
upg1.timezone_upg=yes
upg1.target_version=19
upg1.target_cdb=SBXTTS19
upg1.target_pdb_name=JIRASBXD1,BITBSBXD1,CONFSBXD1,CRDSBXD1
upg1.target_pdb_copy_option=file_name_convert=(‘+DATA’, ‘+DATA’)
######### Error
Ambiguous entry found for prefix upg1, specify the PDB options using format prefix.option.container=value when multiple PDBs are being processed
Hi Saumil,
please remove:
upg1.dbname
upg1.upgrade_node
upg1.run_utlrp
upg1.timezone_upg
upg1.target_version
upg1.start_time
This makes a much leaner config file and will still do the same.
Then I guess you want the PDBs: pdb1,pdb2,pdb3.pdb4 unplugged and plugged into SBXTTS19 but all of them with new names: JIRASBXD1,BITBSBXD1,CONFSBXD1,CRDSBXD1
I don’t spot a failure in your config file.
If it still fails, you please need to open an SR.
So, do the following:
1. Shorten your config file and try again
2. If it still fails, open an SR and upload the entire zip: “java -jar autoupgrade.jar -config yourcfg.cfg -zip”
Thanks,
Mike
Hi Mike & Team,
Thanks for sharing this wonderful knowledge.
It seems that the examples given are for upgrading to the SAME SERVER, but what if my source and target DBs are on different servers/hosts?
Is there a blog for this? If not, could you share the high-level steps, like what the config file is on Source, what needs to be edited on the target side in the config file, and whether we need to copy the files manually from source to target?
The source DB is running on 12C CDB (12.2.0.1) and has one PDB named PDB12C & needs to be plugged into 19C CDB, which is running on a different server/host.
Please see:
https://mikedietrichde.com/2020/08/03/oracle-autoupgrade-between-two-servers/
It has been twice mentioned in the article you commented on.
And I confess that the title of the “plugin” article is not ideal – but impossible to change afterwards since it will break a lot of things.
Please check:
https://mikedietrichde.com/2020/08/03/oracle-autoupgrade-between-two-servers/
Cheers,
Mike
From what I understand, it can’t be done using only autoupgrade. You have to copy you database from source to target.
Hi Christiano,
correct, AutoUpgrade DOES NOT copy your database with this technique. But when you use a refreshable clone PDB instead (where your source must be at least 12.2.0.1, and it can be a non-CDB or a PDB), then the database is cloned by AutoUpgrade. See our video for Multitenant on mikedietrichde.com/videos.
Cheers,
Mike