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 Brett Jordan on Unsplash
The Component Pitfall
With component we mean the database component which you can find in DBA_REGISTRY
– or CDB_REGISTRY
. When Multitenant became available over 5 years ago, a decision had been made to make all options/components mandatory in a container database. This decision had to be reverted a while after Oracle 12.1.0.2 became available for many reasons. To create a CDB with less options than the standard, you could do this in Oracle 12c by editing the database creation scripts – and since Oracle 12.2.0.1 you can do this in the DBCA as part of the Advance Configuration ==> Custom Database
.I know a lot of customers who have done this, either for license reasons or because of potential security fixes being necessary more likely when you have all options, or simply because an upgrade runs faster the less options you have.
Now when you plugin a non-CDB, it is crucial that the options or components being present in the non-CDB exist in the CDB$ROOT
of the receiving container database as well. If that isn’t the case, you can plugin. But you can open your PDB only RESTRICTED
until you solve the situation.
My Example
I’m comparing the installed components between my non-CDB (left side) and my receiving CDB (right side):
non-CDB | CDB |
select COMP_ID from DBA_REGISTRY where STATUS='VALID' order by 1; COMP_ID -------------- CATALOG CATJAVA CATPROC JAVAVM OLS ORDIM OWM RAC XDB XML |
select COMP_ID from CDB_REGISTRY where CON_ID=1 and STATUS='VALID' order by 1; COMP_ID ---------------- CATALOG CATPROC OLS OWM RAC XDB |
In my example my source non-CDB has more components than my future CDB. This is a problem I need to solve.
Of course, when it is the other way round – the non-CDB having less options than the CDB – this is not an issue at all as long as all existing options in the non-CDB are all present in the CDB$ROOT
.
When I run the plug compatibility check, I find these entries in PDB_PLUG_IN_VIOLATIONS
afterwards:
CON_ID NAME TYPE MESSAGE STATUS
------ -------- --------- -------------------------------------------------- ---------
1 DB12 ... ...
1 DB12 ERROR Database option CATJAVA mismatch: PDB installed ve PENDING
rsion 19.0.0.0.0. CDB installed version NULL.
1 DB12 ERROR Database option JAVAVM mismatch: PDB installed ver PENDING
sion 19.0.0.0.0. CDB installed version NULL.
1 DB12 ERROR Database option ORDIM mismatch: PDB installed vers PENDING
ion 19.0.0.0.0. CDB installed version NULL.
1 DB12 ERROR Database option XML mismatch: PDB installed versio PENDING
n 19.0.0.0.0. CDB installed version NULL.
Of course, I still can plugin my non-CDB. And I can run noncdb_to_pdb.sql
without taking care. But what happens afterwards?
The new PDB will not open unrestricted. This means, you need to solve this problem as otherwise you can’t work with this PDB.
Possible Solutions
What are your options:
- Create a new CDB with the required options and unplug/plug the now-PDB
- I would do this in cases where you the components are in use or where you are at least unsure if somebody uses them
- Install the missing options into the CDB$ROOT
- This is a solution I’d recommend when you need to plugin the PDB exactly into this CDB. The DBCA offers you to install components afterwards.
Just test this upfront to be sure that everything works online without interruption. In my example I installedJAVAVM
,XML
,ORDIM
andJAVA
into theCDB$ROOT
only.
From thealert.log
I see that thePDB$SEED
gets restarted for whatever reason – but the components get added to theCDB$ROOT
only as desired. The option the DBCA does not offer here is to install it into theCDB$ROOT
and thePDB$SEED
but not into any existing PDB. Hence, if you add it toPDB$SEED
as well, it will be added to all existing PDBs as far as I can see.
- This is a solution I’d recommend when you need to plugin the PDB exactly into this CDB. The DBCA offers you to install components afterwards.
- Remove the components from the PDB
- This is a solution I see a bit problematic, too, for the same reasons as the solution above. You won’t find much instructions except the ones here on the blog. But I haven’t tested them for the removal from a single PDB. If you still try to do it, you will have to use always the catcon.pl calls to be on the right side. Never use the removal scripts directly in SQL*Plus. If you do this, the risk is high that certain calls will fail.
- Just out of curiosity, this is a quick exercise to see if it works:
ORDIM
removal:$ORACLE_HOME/perl/bin/perl $OH19/rdbms/admin/catcon.pl -n 1 -c 'DB12' -e -b imremdo_db12 -d $ORACLE_HOME/ord/im/admin imremdo.sql $ORACLE_HOME/perl/bin/perl $OH19/rdbms/admin/catcon.pl -n 1 -c 'DB12' -e -b utlrp -d '''.''' utlrp.sql
JAVA
,XML
andJAVAVM
removal:$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -c 'DB12' -b catnojav -d /u01/app/oracle/product/12.2.0.1/rdbms/admin catnojav.sql $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -c 'DB12' -b rmxml -d /u01/app/oracle/product/12.2.0.1/xdk/admin rmxml.sql $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -c 'DB12' -b rmjvm -d /u01/app/oracle/product/12.2.0.1/javavm/install rmjvm.sql $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -c 'DB12' -e -b utlrp -d '''.''' utlrp.sql
- And yes, once I removed all the mismatching components, I could open my
DB12
PDB flawless and unrestricted.
- Restore your non-CDB and remove the components before plugin
- This is the solution I would recommend in the case you are sure or can verify that nobody is using these components. It is the most clean approach. And doesn’t interrupt the operation of your CDB. See this blog post series about removing components.
Summary and Recommendation
Be careful with different components when you plugin. There are so many situations where you may have databases with the standard set of components. And a lot of customers I know customize their database creation carefully these days. Hence, pay attention upfront. Especially in larger database estates, run a script and consolidate the information together upfront. Add this information to your consolidation plan in case you plan to put PDBs together in Multitenant. It’s no rocket science – but it may require some extra work.
Further Information and Links
- Remove and Clean-Up Components – July 26, 2017
- Create Container Databases with less options – it’s now supported – April 23, 2015
- Creating CDBs with less options – August 8, 2018
- Be aware of database selection options for PDBs in DBCA – May 15, 2018
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
Mike,
Excellent post !! This issue of components is very confusing. I still have questions. I am going to be upgrading/converting a bunch of 11g databases to single tenant 19c (hopefully). Once upgraded and converted, it would be really hard to make any changes to these database, so I get only chance to do it right.
a) When creating the CDB to receive the non-CDB as PDB, should I only include those components in the CDB which are present in the non-CDB database? Should I check the “Include in PDBs” box?
b) If a component is not present in non-CDB today, but I am planning on installing it later (Database Vault), should I install it in the CDB? Should I check the “Include in PDBs” box?
c) In the past you said that never include APEX in CDB. If my non-CDB has APEX (we use it in some databases), then should I include it in CDB? Again, what about “Include in PDBs” check box?
d) If I do not include APEX in CDB, can still plug-in a non-CDB with APEX installed in it and get a working database?
Thanks,
Arun
Hi Arun,
APEX ==> PDB only!
When you migrate a non-CDB to a PDB, APEX stays in the PDB. Never have it in CDB$ROOT. If you click “inlcude in PDB” it will be in PDB$SEED and future PDBs. But I think, DBCA does not allow you to click PDB only but have CDB unselected. Hence, you have no chance to have it provisioned automatically unless you use _ORACLE_SCRIPT and install APEX in the PDB$SEED. But you don’t have to.
Regarding all the other components, as soon as you’d like to plugin with more components in the non-CDB, your receiving CDB needs these components. But having it in the CDB does usually not harm. You should only include the “PDB” switch if you’d like to have it in all your future PDBs as well.
Cheers,
Mike
Mike,
Just wanted to share something. If the CDB has Database Vault and Oracle Label Security options checked during creation (not even configured) and I plug-in a PDB which does not have these components, the full export of PDB will fail.
12.2 DataPump Export (EXPDP) Fails Exporting Full PDB Due To ORA-39126 On KUPW$WORKER.FETCH_XML_OBJECTS (Doc ID 2361799.1)
As per the MOS note, there are three workarounds. I used the third one and it seemed to work. I think it is the only good solution if I need to plug-in some PDBs which use Database Vault and some don’t.
Thanks,
Arun
Thanks for sharing, Arun!
Cheers,
Mike
Hi Mike,
Preparing 11.2.0.4 to 19.10 PDB test migrations for a real migration next weekend. Autoupgrade 22.4.220712 prechecks are flagging REMOVED components in the 11g database that do not exist in the target CDB. Have you seen this issue before. An SR has been raised.
CheckName: PLUGIN_COMP_COMPATIBILITY FixUp Available: NO Severity: ERROR Stage: PRECHECKS
Install the missing components in the CDB$ROOT of DMVCA11 before proceeding with the conversion.
The destination CDB DMVCA11 must have installed the components of the non-CDB DMVA1 database that will be plugged in as a PDB.
The destination CDB DMVCA11 does not have these components [CATJAVA,JAVAVM,XML] installed, but they are present in the non-CDB DMVA1.
Regards,
Doug
Hi DougK,
my reply is too late – but I have not see this yet.
Ideally you’d open an SR, upload the AU logs and the full spool of REGISTRY$ to have Support check it.
Cheers
Mike