Autoupgrade E-Business Suite 12.2 to Exascale - Part 2 Remote Clone

In the first part of this series of blogs I covered the overall idea of migrating and upgrading E-Business Suite to 26ai on Exascale Infrastructure. Furthermore I showed how to provision a basic Exascale environment including an empty CDB. We'll now cover the actual upgrade of the database including the relocation.

Before doing the Database Upgrade including the relocation for an E-Business Suite environment it is required to apply a bundle of EBS interopability patches. For me this was 32360310,35876968,36960053,37012872,3831080; but make sure to check the latest official documentation in Oracle Support Document KA1151 . Obviously you have to be at least on EBS 12.2.7 (minimum patching baseline) and AD/TXK16 as a starting point, but other than that the patch impact of those apps patches on my environment (12.2.14) was rather minimal.

Upgrading an EBS database requires a robust strategy. We utilized the Oracle Autoupgrade tool to perform the upgrade as part of a PDB relocation from our 19c source to our target Exascale 26ai environment equipped with a storage vault.

Before starting the deployment, we configured our myconfig.cfg using the Autoupgrade composer for a pdbrelocation:

global.global_log_dir=/home/oracle/autoupgrade/log
upg1.sid=CDBUPG
upg1.log_dir=/home/oracle/autoupgrade/log/CDBUPG_Upgrade
upg1.source_home=/u01/install/APPS/19.0.0
upg1.target_home=/u02/app/oracle/product/23.0.0.0/dbhome_1
upg1.pdbs=UPG
upg1.target_cdb=CDBUPG1
upg1.target_pdb_name.UPG=UPG
upg1.source_dblink.UPG=UPG.INTERN.DNS CLONE_ONLY
upg1.target_pdb_copy_option.UPG=file_name_convert=NONE
upg1.target_version=26
upg1.target_is_remote=yes

Keep in mind to:

• put the Instance SID as the target_cdb

• run the autoupgrade preparation steps on the source

• think about a downtime strategy for production: This approach allows to refresh the PDB for some time until you actually shut down the application on the source side and perform the cutover/upgrade

• Create a database link "UPG.INTERN.DNS" that points from the new CDB to the old PDB

So create a user on the source:

alter session set container=UPG;
create user dblinkuser identified by Promatis1;
grant create session, create pluggable database, select_catalog_role to dblinkuser;
grant read on sys.enc$ to dblinkuser;
exit

And then create the database link:

create database link UPG.INTERN.DNS connect to dblinkuser identified by Promatis1 using '(DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=10.22.15.210)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=ebs_UPG) (INSTANCE_NAME=CDBUPG)))';

select * from v$version@UPG.INTERN.DNS; 

During our implementation, we encountered a behavior where the migration required the SPFILE to temporarily reside on the local file system instead of the Exascale vault. To work around this currently investigated bug (Oracle is in the process of creating and releasing a fix for this; a beta version looks promising already), we temporarily disabled the cluster database and moved the SPFILE out of the Exascale ASM alias prior to the Autoupgrade deployment. For this I connected to the first node:

sqlplus / as sysdba
SQL>alter system set cluster_database=false scope=spfile;
SQL>show parameter spfile;
SQL>exit;

xsh cp @wHw8P6k0/EXAUPG3-1F025C8A8D43CFB9BFDCCA7344F9AC1F/CDBUPG/PARAMETERFILE/spfile.OMF.4871035D $ORACLE_HOME/dbs/spfileCDBUPG.ora 

srvctl stop database -d $ORACLE_UNQNAME

srvctl modify database -db $ORACLE_UNQNAME -spfile $ORACLE_HOME/dbs/spfileCDBUPG.ora

srvctl start instance -db $ORACLE_UNQNAME -node exaupg31-klkfm

With those preparations in place you can start the actual autoupgrade:

java -jar autoupgrade.jar -config myconfig.cfg -mode deploy

Then you have to wait - eventually you have to wait for a long time if your network is slow and your source environment just as a single CPU core while you want to migrate 6 TB of data:

The overall procedure is very smooth. Since the CLONEPDB part can be done in an incremental way the pure upgrade took roughly 2 hours of downtime plug another 30 minutes for the utlrp run. In the third part of the blog posts we'll have a look at the results and reconnect the Oracle E-Business Suite application server with our database.