Database Migration from non-CDB to PDB – Typical Plugin Issues and Workarounds

In the previous blog posts I showed different approaches on how to migrate your database on a same Endianness platform into Multitenant. Whether you prefer to upgrade first or plugin first is up to you. I recommend upgrading first as this allows you a seamless fallback. But regardless of which approach you prefer, you may take care on potential pitfalls. Hence, this blog post is about Database Migration from non-CDB to PDB – Typical Plugin Issues and Workarounds. It may not be complete when I publish it and I may extend it later on. Let me know if you have recommendations what I need to add.

Photo by Cindy Tang on Unsplash

Database Migration from non-CDB to PDB – Typical Plugin Issues and Workarounds

The idea is here to highlight potential pitfalls and show you workarounds or checks you may use upfront. I assume that your goal is to move an existing non-CDB of version 11.2.0.4 or newer into an existing Oracle 19c CDB. The most important step you need to do before you plugin is the Plugin Compatibility Check. It populates the view PDB_PLUG_IN_VIOLATIONS with a lot of useless warnings. But a few may be very important. And may require an action by you.

Describe your non-CDB

In order to do the plug compatibility check, you need to create the XML manifest file.

exec DBMS_PDB.DESCRIBE('/home/oracle/DB12.xml');

Once you created it, you need to execute the recommended plugin-compatibility check from your CDB.

I am the Spirit that denies!

The plugin compatibility check way to often says “No“. This is based on its design. It can either give TRUE or FALSE instead of a list of things you need to do.

set serveroutput on

DECLARE
compatible CONSTANT VARCHAR2(3) := CASE DBMS_PDB.CHECK_PLUG_COMPATIBILITY( pdb_descr_file => '/home/oracle/DB12.xml', pdb_name => 'DB12') WHEN TRUE THEN 'YES' ELSE 'NO'
END;
BEGIN
DBMS_OUTPUT.PUT_LINE('Is the future PDB compatible?  ==>  ' || compatible);
END;
/

When you get the typical result “No“, you need to drill further down into the details. And sometimes follow pure logic.

Is the future PDB compatible?  ==>  NO
PL/SQL procedure successfully completed.

Why is it not compatible?

The view with the special name

You need to check the view with the special name, PDB_PLUG_IN_VIOLATIONS for potential reasons why the non-CDB is not compatible to be plugged into the CDB. I use this query to check what I need to fix:

set pages 2000
set line 200

column message format a50
column status format a9
column type format a9
column con_id format 9
column name format a8

select con_id, name, type, message, status
  from PDB_PLUG_IN_VIOLATIONS
 where status<>'RESOLVED'
 order by name,time;

Often you will find a lot of not so useful warnings such as: “CDB parameter sga_target mismatch: Previous 1200M Current 1504M“.

What does this tell you?

Well, your source non-CDB has a smaller SGA than your future CDB. As we regulate some of the ASMM parameters by ourselves anyways, no issue here. It should be better labeled as “Information“.

Typical Plugin Issues and Workarounds

Initially I planned to release only one long blog post. But the more I tried out, the longer it became. I had to split it up into several pieces which I release all day by day:

• 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

Let me know if you think something important is missing and I’ll happily add it.

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