Database Migration from non-CDB to PDB – The COMPATIBLE 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.

Database Migration from non-CDB to PDB – The COMPATIBLE pitfall

When you migrate your non-CDB to PDB, in most cases the COMPATIBLE setting of the non-CDB will be lower than the setting of the receiving CDB. But still in this case you may see warnings. I will explain how to deal with the different situations – and where you need to pay attention and adjust your settings.

See also the related blog posts regarding potential plugin pitfalls with Database Migration from non-CDB to PDB:

• Typical Plugin Issues and Workarounds
• The Compatible Pitfall
• The Time Zone Pitfall
• The Component Pitfall (Wednesday)
• The Patch Level Pitfall (Thursday)
• Various Pitfalls (Friday)
• The Fallback Challenge (Monday)

Different Compatible warnings and errors

Actually there can be two sorts of COMPATIBLE warnings: Those which don’t tell you anything. And those which tell you a lot. How do you differ between these two? See below.

The first example is a message you may see in typical situations.

When I try to plugin a 12.2.0.1 non-CDB into a 19.3.0 CDB I receive this WARNING in PDB_PLUG_IN_VIOLATIONS when doing the plug compatibility check:

CON_ID NAME	TYPE	  MESSAGE					     STATUS
------ -------- --------- -------------------------------------------------- ---------
     1 DB12	...       ...
     1 DB12	WARNING   CDB parameter compatible mismatch: Previous '12.2. PENDING
			  0' Current '19.0.0'

It is good to get this WARNING as it tells me that my COMPATIBLE setting will be lifted to 19.0.0. Doesn’t it?

Well, you need to be aware, whenever you plugin, that the COMPATIBLE setting of the receiving CDB matters. And PDBs you plug in, automatically get COMPATIBLE adjusted once the CDB has a higher level. Of course, you can’t plugin a PDB which has a higher COMPATIBLE level than the receiving CDB.

But here we deal with a non-CDB. Is this an issue? No. But the warning should tell you correctly “Be aware, your COMPATIBLE setting for the non-CDB will be lifted to 19.0.0 - and this change is irreversible.“.

Let me do a quick experiment with my non-CDB. I upgraded it to Oracle 19c already.

alter system set compatible='19.1.0.0.0' scope=spfile;
startup force

You may remember my blog post where I clearly recommended to let COMPATIBLE always on the default for 18c and 19c – and with 3 digits only. I will redo the DESCRIBE and plugin compatibility check after I increased the COMPATIBLE setting for my non-CDB.

Now I receive a clear ALERT (or ERROR):

CON_ID NAME	TYPE	  MESSAGE					     STATUS
------ -------- --------- -------------------------------------------------- ---------
     1 DB12	ERROR	  PDB's compatible version is not allowed in the CDB PENDING
			  : PDB's compatible parameter 19.1.0.0.0. CDB's com
			  patible parameter 19.0.0.0.0, plug in is not allow
			  ed

     1 DB12	WARNING   CDB parameter compatible mismatch: Previous '19.1. PENDING
			  0.0.0' Current '19.0.0'

You can’t plugin. Nothing to discuss here.

Summary and Recommendation

It is very simple but still you need to pay attention, especially in regards to the application you run in the non-CDB. Be aware that COMPATIBLE gets always lifted to the value of the CDB you plug into. And be VERY aware that this is a silent change, especially if you don’t do the plug compatibility check upfront. This applies to plugging in non-CDBs as well as to PDBs.

And obviously, you can’t plug in a non-CDB or PDB with a higher COMPATIBLE setting than the receiving CDB. As a general rule, I would keep the COMPATIBLE setting across all my CDBs the same until you have all your environments on a higher level completely. This means, once you have a mix of 12.2.0.1, 18c and 19c CDBs, you either should pay close attention to COMPATIBLE or you better keep it everywhere at “12.2.0” unless all your PDBs are on a higher release. For non-CDB migration, this has no impact as you can’t revert to non-CDB anyway after you plugged in.

Just a final recommendation: Don’t set COMPATIBLE to values such as “12.2.0.1.0” or “18.3.0“. This will make your life just harder and more complicated. Keep it with 3 digits only – and don’t adjust if for RU or RUR levels. This has no effect and makes no sense. Even the 12.1.0.2 feature Oracle In-Memory didn’t require to change COMPATIBLE to “12.1.0.2.0” – if you had COMPATIBLE on “12.1.0” you were all set.

And as people have pointed me to this, be also aware that especially some ASM features such as FLEX and EXTENDED disk groups and Fast Mirror Resync require COMPATIBLE.RDBMS = 12.2.0.1.. In this case you need to advance the compatibility when you migrate from releases older than 12.2..

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

Related Posts

• Upgrade, plug in, convert (noncdb_to_pdb.sql) – 11.2.0.4 and higher
• Plugin, upgrade, convert (noncdb_to_pdb.sql) – 12.2.0.1 and higher
• Clone via NON$CDB, upgrade, convert – 12.1.0.2 and higher

–Mike