When I changed our Hands-On Lab to Oracle 18c, I encountered one strange issue in case I upgraded the UPGR database to 18.3.0 and wanted to plug it in afterwards. Before plugin I usually do a compatibility check. But this seems to fail. I checked my file, my paths, everything. But I couldn’t find the root cause. And yesterday I received an email from a customer who has a case open for over a week encountering a similar problem. And we both came to the conclusion for Oracle 18.3.0 Multitenant: Compatibility Check does not work under certain circumstances.
Interestingly this applies to Oracle 18c sources only. In lower versions and with sources lower than Oracle 18.3.0 the
DBMS_PDB.CHECK_PLUG_COMPATIBILITY runs fine.
First of all, the idea of the compatibility check is to alert you about potential issues before you plugin. Still the procedure does not tell you anything about the issues but populates my favorite view PDB_PLUG_IN_VIOLATIONS with more or less useful information.
You should then fix
ERRORs either before or after the plugin. In the view you’ll find things such as “run noncdb_to_pdb.sql” after plugin.
This is how a compatibility check looks like:
SET SERVEROUTPUT ON DECLARE compatible CONSTANT VARCHAR2(3) := CASE DBMS_PDB.CHECK_PLUG_COMPATIBILITY( pdb_descr_file => '/home/oracle/PDB12201.xml', pdb_name => 'PDB12201') WHEN TRUE THEN 'YES' ELSE 'NO' END; BEGIN DBMS_OUTPUT.PUT_LINE(compatible); END; /
It tells you “
YES” or “
NO” – but in case the procedure tells you “
NO” which happens in >90% of all cases, you will have to find out the reason in
Oracle 18.3.0 Multitenant: Compatibility Check does not work
Unfortunately this fails as soon as the source is an Oracle 18.x.y database or PDB.
This is a very simple test case – my
compatibility_check.sql contains exactly the check from above with adjusted paths:
SQL> create pluggable database pdb2 admin user pdb2 identified by pdb2 file_name_convert=('/u02/oradata/CDB2/pdbseed','/u02/oradata/CDB2/pdb2'); Pluggable database created. SQL> alter pluggable database pdb2 open; Pluggable database altered. SQL> alter pluggable database pdb2 close; Pluggable database altered. SQL> alter pluggable database PDB2 unplug into '/home/oracle/pdb2.xml'; Pluggable database altered. SQL> drop pluggable database pdb2 keep datafiles; Pluggable database dropped. SQL> start compatibility_check.sql ERROR: ORA-03114: not connected to ORACLE DECLARE * ERROR at line 1: ORA-03113: end-of-file on communication channel Process ID: 32550 Session ID: 33 Serial number: 50352
Unfortunately the client disconnect usually means that there is a core dump happening. And that’s the case:
ORA-07445: exception encountered: core dump [__intel_ssse3_rep_memcpy()+6710] [SIGSEGV] [ADDR:0xFFFFFFFFFFFFFFEF] [PC:0x6E46FE6] [Address not mapped to object] 
The customer who encountered the issue as well sent me an example with an 18.3.0 non-CDB which he wanted to clone directly as PDB into an 18.3.0 CDB. It fails with the same error.
In most cases you can safely live without the compatibility check with
DBMS_PDB.CHECK_PLUG_COMPATIBILITY. You’ll have to justify and fix the issues anyways. But in the case where you’d like to clone a non-CDB into a PDB the check is actually important to avoid multiple failing attempts.
As far as I see, the issue applies to Oracle 18c sources at least up to Oracle 18.3.0, regardless if you plan to plugin a non-CDB, clone a non-CDB or unplug and plug a PDB. As soon as you have a non-18c source such as an 22.214.171.124 PDB it works flawless.
Issue is under investigation. I will update the blog post once I find out about a patch number and potentially a MOS note.
Please find further information here:
- Purging of PDB_PLUG_IN_VIOLATIONS in Oracle 18c
- MOS Note: 2288129.1 (Known Issues With PDB_PLUG_IN_VIOLATIONS)
- noncdb_to_pdb.sql – Why does it take so long?
Important Update as of Sep 3, 2018
First of all the issue is tracked under BUG 28502403 – ORACLE 18.3.0 MULTITENANT: COMPATIBILITY CHECK DOES NOT WORK. The issue got introduced due to a malformed string. And the fix is included in Oracle 19c but is also available as single patch on Linux for 18.3.0 and 18.2.0. Glad that my Multitenant colleagues did provide a fix so quickly.
And a day after, the customer who alerted me about this issue, confirmed that the patch works fine – and the compatibility check with the patch is working.