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.
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 184.108.40.206 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.
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
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 “
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.
- Upgrade, plug in, convert (noncdb_to_pdb.sql) – 220.127.116.11 and higher
- Plugin, upgrade, convert (noncdb_to_pdb.sql) – 18.104.22.168 and higher
- Clone via NON$CDB, upgrade, convert – 22.214.171.124 and higher