Database Migration from non-CDB to PDB - The Patch Level Pitfall

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.

Photo by Piron Guillaume on Unsplash

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 WARNINGs and 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 12.2.0.1 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 WARNINGs and ERRORs:
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 12.2.0.1 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 12.2.0.1.190416): Not installed in the CD
			  B but installed in the PDB

     1 DB12	ERROR	  '19.3.0.0.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 12.2.0.1 of April 2019. And of course, this is not installed in the CDB which is 19c. Makes sense. For sure isn’t an ERROR.
Vice versa, the CDB has the RU 19.3.0 of April 2019 installed – and hopefully your 12.2.0.1 non-CDB doesn’t have it. Makes sense, too.
Finally, 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 12.2.0.1. Now this is flagged as a WARNING which 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 12.2.0.1 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	  '19.3.0.0.0 Release_Update 1904101227' is installe PENDING
			  d in the CDB but '19.4.0.0.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

Applying a patch to a single-/multitenant environment – March 19, 2015

Typical Plugin Issues and Workarounds

–Mike

Database Migration from non-CDB to PDB – The Patch Level Pitfall