ORA-65028 when plugging in a PDB from a PDB archive into a RAC database
I’m currently testing all the different PDB features like local and remote cloning or plugging in a PDB on a 19.6 Container-Database in a Maximum Availability Architecture (MAA), i.e. a setup with RAC, ASM and DataGuard in place. Everything went fine, except for the attempt to plugin a PDB from a PDB archive, which always resulted in an ORA-65028.
All attempts failed with the following error stack:
ORA-65028: Unable to open plugin data file at path +DATA ORA-17503: ksfdopn:2 Failed to open file +DATA ORA-15045: ASM file name '+DATA' is not in reference form
When checking the files in ASM, I found out that all tablespaces except SYSTEM had been copied to the diskgroup, occupying disk space and leaving an unusable PDB. As the PDB is unusable, it’s a good idea to drop it and to release the diskspace in the diskgroup.
My servers are running Grid Instrastructure and RDBMS 19.6:
oracle@geri:~/ [CDB1] $ORACLE_HOME/OPatch/opatch lspatches 30484981;OJVM RELEASE UPDATE: 126.96.36.199.200114 (30484981) 30557433;Database Release Update : 188.8.131.52.200114 (30557433) 29585399;OCW RELEASE UPDATE 184.108.40.206.0 (29585399) OPatch succeeded. oracle@geri:~/ [CDB1] +ASM1 oracle@geri:~/ [+ASM1] $ORACLE_HOME/OPatch/opatch lspatches 30655595;TOMCAT RELEASE UPDATE 220.127.116.11.0 (30655595) 30557433;Database Release Update : 18.104.22.168.200114 (30557433) 30489632;ACFS RELEASE UPDATE 22.214.171.124.0 (30489632) 30489227;OCW RELEASE UPDATE 126.96.36.199.0 (30489227) OPatch succeeded.
I did some other tests which worked fine, like
- plugging in the same PDB in a CDB running on ASM in a Oracle Restart environment (Oracle 19.6)
- plugging in the same PDB in my RAC database with one instance running
So I could rule out that the PDB archive file was somehow corrupt.
And a colleague told me that he could not reproduce the problem in his 19c environment.
So another aspect came into my mind: RDBMS compatibility on diskgroup level:
I’ve got a 188.8.131.52 database running on the same cluster, which is using the same diskgroups (“DATA” and “FRA”) like the 19c database.
In consequence, the RDBMS compatiblity level was set to “184.108.40.206” for “DATA” and “10.1.0.0.0” for “FRA”, because the compatibility level determines the lowest database version which can use the diskgroup.
So I moved the 220.127.116.11 database to another diskgroup and changed the RDBMS compatibility level of my diskgroups “DATA” and “FRA” to “18.104.22.168.0”.
SQL> column name format a10 SQL> column DATABASE_COMPATIBILITY format a30 SQL> select name,DATABASE_COMPATIBILITY from v$asm_diskgroup; NAME DATABASE_COMPATIBILITY ---------- ------------------------------ DATA 22.214.171.124.0 FRA 126.96.36.199.0
And – voilà – I could plug in the PDB without any issues:
SQL> create pluggable database pdb2 2 using '/mnt/data/pdb1.pdb' 3 create_file_dest='+DATA' standbys=none; Pluggable database created.
Perhaps setting the compatibility to “188.8.131.52.0” would have been sufficient, but I chose “184.108.40.206.0” because PDB archives were introduced with Oracle Database 12.2
A former colleague told me that he had the same problem, but changing the RDBMS compatibility did not solve the issue. So there must be another root cause for this issue.
References & more information
- Oracle Database 19c documentation: Features Enabled By Disk Group Compatibility Attribute Settings
- Oracle Database 19c documentation: Setting Disk Group Compatibility Attributes
- Oracle Database 12.2 Documentation: New Feature “PDB archive”
(Amazon Partner Link))