Database Migration from non-CDB to PDB – The Component 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 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):

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 installed JAVAVM, XML, ORDIM and JAVA into the CDB$ROOT only.
    
    From the alert.log I see that the PDB$SEED gets restarted for whatever reason – but the components get added to the CDB$ROOT only as desired. The option the DBCA does not offer here is to install it into the CDB$ROOT and the PDB$SEED but not into any existing PDB. Hence, if you add it to PDB$SEED as well, it will be added to all existing PDBs as far as I can see.
• 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 and JAVAVM 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