Last week I did some upgrade tests from 19c to 21c. The plan was to copy a 19c PDB to a CDB 21c using Online Clone and then upgrade it to 21c. I have done this many times for 19c as well and just wanted to verify that it still worked with 21c.<\/p>\n
Clone PDB to 21c CDB<\/strong> Now I clone the 19c pdb into the 21c CDB over the dblink<\/p>\n Upgrade PDB to 21c<\/strong> And now with Oracle 21c the magic part happens, or i would say, that a autonoumous Feature found the way to the on prem word. Here you can see a very interesting snipped of the alert.log<\/p>\n On the first line you can see, that oracle has started to upgrade my pdb immediate after i issued the open command. With the next command oracle tries to upgrade the application APP$CDB$CATALOG <\/em>to 19.0.0.0.0 what’s in fact the data dictionary version. This gives an error. I can’t confirm it, but in context of application containers the begin install command always install the newest application version in the pdb. In this context i would expect, that oracle tries to apply the newest 19c patches to my pdb but this failed for some reason.<\/p>\n Then the next stage is upgrade of the catalog from version 19.0.0.0.0 to 21.0.0.0.0.partial. The syntax is exactly the same if you upgrade an application pdb to a new version.<\/p>\n And in the last step oracle performs the upgrade from the version 21.0.0.0.0.partial to 21.0.0.0.0. I have no idea why this additional step to 21.0.0.0.0.partial is necessary.<\/p>\n Finally the Upgrade of the Application APP$CDB$CATALOG is done and oracle open the pdb with the new version 21c<\/p>\n Reverse Engineering<\/strong> We can see that we have an application APP$CDB$CATALOG <\/em>that holds the upgrade scripts to upgrade a pdb to 21c and also we have a application APP$CDB$PDBONLY$NCDBTOPDB <\/em>which is responsible auto upgrading a non cdb to 21c and additionally including the scripts for the conversion from noncdb to pdb
\nSince it is a LAB, I gave the user SYSTEM in the CDB19c the appropriate duplicate permissions and then I created from the CDB 21c the appropriate DB link for the clone<\/p>\nSQL*Plus: Release 19.0.0.0.0 - Production on Fri Sep 17 13:17:06 2021\nVersion 19.3.0.0.0\nCopyright (c) 1982, 2019, Oracle. All rights reserved.\nConnected to:\nOracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production\nVersion 19.3.0.0.0\nSQL> grant sysoper, create pluggable database to system container=all;\nGrant succeeded.\n-- create db link for clone\noracle@ora21:\/home\/oracle\/ [cdb01] sqh\nSQL*Plus: Release 21.0.0.0.0 - Production on Fri Sep 17 13:18:31 2021\nVersion 21.3.0.0.0\nCopyright (c) 1982, 2021, Oracle. All rights reserved.\nConnected to:\nOracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production\nVersion 21.3.0.0.0\nSQL> create database link cdb19c2 connect to system identified by manager using 'cdb19c2';\nDatabase link created.<\/pre>\n
SQL> create pluggable database pdb19c_copy from pdb19c@cdb19c2;\nPluggable database created.<\/pre>\n
\nSo the next step is to open the PDB and afterwards execute the upgrade script for upgrading the catalog of the pdb to 21c.<\/p>\nSQL> alter pluggable database pdb19c_copy open;<\/pre>\n
\nAfter a few seconds the opening of the PDB was still not finished, but no error was displayed on the prompt, I looked into the alert log of the database to see what exactly the problem was. When I looked through the entries, I was quite surprised to see that my PDB was in the middle of an upgrade to 21c without Oracle giving me a choice.
\nA look on the pdb state confirmed what oracle tells me in the alert.log<\/p>\nSQL> show pdbs<\/pre>\n
CON_ID CON_NAME OPEN MODE RESTRICTED\n---------- ------------------------------ ---------- ----------\n2 PDB$SEED READ ONLY NO\n3 PDB19c_COPY MIGRATE YES<\/pre>\n
PDB19C_COPY(6):Starting Upgrade on PDB Open\n2021-09-17T13:21:09.305411+02:00\nPDB19C_COPY(6):alter pluggable database application APP$CDB$CATALOG begin install '19.0.0.0.0' on error capture\nPDB19C_COPY(6):ORA-65229 signalled during: alter pluggable database application APP$CDB$CATALOG begin install '19.0.0.0.0' on error capture...\nPDB19C_COPY(6):alter pluggable database application APP$CDB$CATALOG end install '19.0.0.0.0'\nPDB19C_COPY(6):Completed: alter pluggable database application APP$CDB$CATALOG end install '19.0.0.0.0'\nPDB19C_COPY(6):alter pluggable database application APP$CDB$CATALOG begin upgrade\n'19.0.0.0.0' to '21.0.0.0.0.partial' on error capture\nPDB19C_COPY(6):Completed: alter pluggable database application APP$CDB$CATALOG begin upgrade\n'19.0.0.0.0' to '21.0.0.0.0.partial' on error capture<\/pre>\n
\nThe next lines are very interesting. If you look at the statements beginning with “alter pluggable database application … ” you can see, that oracle uses Multitenant application container functionality to upgrade the pdb to the new version. It seams, that they manage different versions of the cdb catalog as applications.<\/p>\nDB19C_COPY(6):alter pluggable database application APP$CDB$CATALOG begin install '19.0.0.0.0' on error capture \nPDB19C_COPY(6):ORA-65229 signalled during: alter pluggable database application APP$CDB$CATALOG begin install '19.0.0.0.0' on error capture...<\/pre>\n
PDB19C_COPY(6):alter pluggable database application APP$CDB$CATALOG begin upgrade \n'19.0.0.0.0' to '21.0.0.0.0.partial' on error capture \nPDB19C_COPY(6):Completed: alter pluggable database application APP$CDB$CATALOG begin upgrade '19.0.0.0.0' to '21.0.0.0.0.partial' on error capture<\/pre>\n
PDB19C_COPY(6):alter pluggable database application APP$CDB$CATALOG begin upgrade '21.0.0.0.0.partial' to '21.0.0.0.0' on error capture\nPDB19C_COPY(6):Completed: alter pluggable database application APP$CDB$CATALOG begin upgrade '21.0.0.0.0.partial' to '21.0.0.0.0' on error capture<\/pre>\n
PDB19C_COPY(6):alter pluggable database application APP$CDB$CATALOG end upgrade\nPluggable database PDB19C_COPY opened read write<\/pre>\n
\nTo see if my assumptions are correct, we can query the most important app container views in the CDB and the PDB and see what is in there.
\nLet’s check the applications that are registered in the cdb$root<\/p>\nSQL> select app_name, app_id, app_version, app_capture_module from dba_applications;\n\nAPP_NAME APP_ID APP_VERSION APP_CAPTURE_MODULE\n------------------------------ ---------- ------------------------------ ----------------------------------------------------------------\nAPP$CDB$SYSTEM 2 1.0 catcon(pid=26657)\nAPP$CDB$PDBONLY$NCDBTOPDB 21 1.0 catcon(pid=26657)\nAPP$CDB$CATALOG 4294967293 21.0.0.0.0 catcon(pid=24698)\nAPP$CDB$CATALOG 4294967292 21.0.0.0.0 catcon(pid=8832)\nAPP$CDB$CATALOG 4294967291 21.0.0.0.0 catcon(pid=1120)<\/pre>\n
\nAnd if we have a look at the app versions, we can see, that oracle stores the catalog upgrade scripts from 12.2 onwards. This allows to auto upgrade the pdb to 21c for all versions beginning with 12.2<\/p>\nSQL> select app_name, app_version from dba_app_versions;\n\nAPP_NAME APP_VERSION\n---------------------------------------- ------------------------------\nAPP$CDB$SYSTEM 1.0\nAPP$CDB$PDBONLY$NCDBTOPDB 1.0.upgmode\nAPP$CDB$PDBONLY$NCDBTOPDB 1.0\nAPP$CDB$CATALOG 12.2.0.1.0\nAPP$CDB$CATALOG 21.0.0.0.0.partial\nAPP$CDB$CATALOG 21.0.0.0.0\nAPP$CDB$CATALOG 18.0.0.0.0\nAPP$CDB$CATALOG 21.0.0.0.0.partial\nAPP$CDB$CATALOG 21.0.0.0.0\nAPP$CDB$CATALOG 19.0.0.0.0\nAPP$CDB$CATALOG 21.0.0.0.0.partial\nAPP$CDB$CATALOG 21.0.0.0.0<\/pre>\n