There are several pitfalls when you plugin a non-CDB into a CDB environment. I’d like to highlight some of them – and show you potential workarounds as well. This is part of a series of blog posts to make your migration from non-CDB to PDB a bit smoother.
Database Migration from non-CDB to PDB – The Patch Level Pitfall
When you consolidate on a larger scale, it is very likely that you have different patch levels in your database environments. But when you attempt to plugin a non-CDB into a CDB, you may see
ERRORs in PDB_PLUG_IN_VIOLATIONS when you do the plug compatibility check as I explained in Typical Plugin Issues And Workarounds.
The main question is whether you’ll have to do something, or not. I will clarify the typical situations you may see.
Meaningless patch warnings and errors
In my first example I plugin a 18.104.22.168 non-CDB into a PDB. I receive a lot of other
ERRORs when I do the plug compatibility check in
PDB_PLUG_IN_VIOLATIONS. Some of them are related to different patch levels.
But actually there can be two sorts of patch
Those which don’t tell you anything.
And those which tell you a lot.
How do your differ between the two? Pure logic!
In this first example I used the technique I wouldn’t recommend to plugin the non-CDB at first, and then upgrade it. I’m plugging in an 22.214.171.124 non-CDB directly into a 19c CDB. But if you do it this way, you may see the below
ERRORs (I removed some other messages which don’t matter here):
CON_ID NAME TYPE MESSAGE STATUS ------ -------- --------- -------------------------------------------------- --------- 1 DB12 ... ... 1 DB12 ERROR DBRU bundle patch 190416 (DATABASE APR 2019 RELEAS PENDING E UPDATE 126.96.36.199.190416): Not installed in the CD B but installed in the PDB 1 DB12 ERROR '188.8.131.52.0 Release_Update 1904101227' is installe PENDING d in the CDB but no release updates are installed in the PDB 1 DB12 WARNING Oracle opatch mismatch: opatch 29314339 is missing PENDING in the CDB.
What does this tell you?
- Your non-CDB has RU 184.108.40.206 of April 2019. And of course, this is not installed in the CDB which is 19c. Makes sense. For sure isn’t an
- Vice versa, the CDB has the RU 19.3.0 of April 2019 installed – and hopefully your 220.127.116.11 non-CDB doesn’t have it. Makes sense, too.
opatch 29314339 is missing??? First of all, with “
opatch” for sure “
patch” is meant. A quick search with the patch number 29314339 in MOS tells me that patch 29314339 is the April 2019 Release Update for 18.104.22.168. Now this is flagged as a
WARNINGwhich is ok for me. But I don’t know why this is coming twice in different ways.
So basically, as I plan to plug in an non-upgraded 22.214.171.124 non-CDB into a 19c CDB, none of these errors and warnings are useful. I can ignore them.
But there are cases when you need to pay attention.
Important patch warnings and errors
For my next test, I upgraded my non-CDB to Oracle 19c already. This is the recommended approach which we call Upgrade, Plugin, Convert. But in this case I upgraded it to 19.4.0 with the July 2019 RU. In contrast, my receiving CDB still stays at 19.3.0. I think this will be a common scenario when not all environments are patched up equally due to different outage windows in larger environments.
Once I created my XML manifest file in my 19.4.0 non-CDB I run the compatibility check on the file from my 19.3.0 CDB – and of course the check says “
No“. But let’s have a look PDB_PLUG_IN_VIOLATIONS at .
CON_ID NAME TYPE MESSAGE STATUS ------ -------- --------- -------------------------------------------------- --------- 1 DB12 ... ... 1 DB12 ERROR '126.96.36.199.0 Release_Update 1904101227' is installe PENDING d in the CDB but '188.8.131.52.0 Release_Update 190626 1711' is installed in the PDB
This is a real
ERROR. My source non-CDB has a higher patch level within the same release 19c (this is very important!) than the target CDB. This is something you must solve before plugging in.
Potential solutions are:
- Apply the matching patch to the CDB environment
- But unless you have a RAC system, this will require downtime for all PDBs – and if you run more than one CDB from this home, it has an effect on the other CDBs as well
- Remove the patch from the non-CDB
- Don’t do this – you would remove highly important security fixes
- Create a new CDB using the same home as the non-CDB is running from
- In this case you’ll have a separate CDB with the overhead of another CDB$ROOT and another PDB$SEED.
It highly depends on your environment and requirements which solution you should chose. I’d recommend the first one but it will require downtime.
Summary and Recommendation
Ideally you should make sure that your environments are patched to the same level. When you migrate from a lower non-CDB version to a higher CDB version, you don’t need to pay attention on the patch difference. But as soon as you move within the same release level (e.g. 19c), then you should be careful and pay attention.
My general advice of course is to be always with all environments on the newest patch levels. But I know that this isn’t possible everywhere for various reasons.
Further Information and Links
Typical Plugin Issues and Workarounds
- Typical Plugin Issues and Workarounds
- The Compatible Pitfall
- The Time Zone Pitfall
- The Component Pitfall
- The Patch Level Pitfall
- Various Pitfalls
- The Fallback Challenge
- The Minimal Downtime Challenge
- Upgrade, plug in, convert (noncdb_to_pdb.sql) – 184.108.40.206 and higher
- Plugin, upgrade, convert (noncdb_to_pdb.sql) – 220.127.116.11 and higher
- Clone via NON$CDB, upgrade, convert – 18.104.22.168 and higher