This was first published on https://blog.dbi-services.com/12cr2-upgrade-by-remote-clone-workaround-ora-17630-in-dbaas (2016-11-20)
Republishing here for new followers. The content is related to the the versions available at the publication date
Easier than unplug/plug, you can move pluggable databases with remote cloning. It’s the same idea but you don’t have to manage the files yourself: the are shipped through database link. However, this uses the ‘remote file protocol’ and it fails with version mismatch:
ORA-17628: Oracle error 17630 returned by remote Oracle server ORA-17630: Mismatch in the remote file protocol version client server
I’ll describe the full operation of remote cloning in a future post. This is the error I got when I tried to remote clone from 12.1 to 12.2:
13:43:55 HP122A SQL> create pluggable database PDB1 from PDB1@HP121A@HP121A keystore identified by "Ach1z0#d" relocate; create pluggable database PDB1 from PDB1@HP121A@HP121A keystore identified by "Ach1z0#d" * ERROR at line 1: ORA-17628: Oracle error 17630 returned by remote Oracle server ORA-17630: Mismatch in the remote file protocol version client server
The error is received from the remote side. There is not a lot in local alert.log
create pluggable database PDB1 from PDB1@HP121A@HP121A keystore identified by * relocate Errors in file /u01/app/oracle/diag/rdbms/hp122a/HP122A/trace/HP122A_ora_29385.trc: ORA-17628: Oracle error 17630 returned by remote Oracle server ORA-17630: Mismatch in the remote file protocol version client server
More information about versions in the remote alert.log:
Errors in file /u01/app/oracle/diag/rdbms/hp121a/HP121A/trace/HP121A_ora_21344.trc: ORA-17630: Mismatch in the remote file protocol version client 3 server 2
Fortunately, version mismatch of remote file protocol has already been a problem in previous versions with other features that have to transport files, and a patch exists to bypass this version checking:
Patch 18633374: COPYING ACROSS REMOTE SERVERS: ASMCMD-8016, ORA-17628, ORA-17630, ORA-06512
And you can download it at https://updates.oracle.com/download/18633374.html
My 12.1.0.2 DBaaS has the July 2016 PSU applied, as well as a merge of patches specific for the cloud:
[oracle@HP121 ~]$ $ORACLE_HOME/OPatch/opatch lspatches 19469538; 24310028; 22366322; 20475845; 18043064; 21132297; 23177536;Database PSU 12.1.0.2.160719, Oracle JavaVM Component (JUL2016) 23054246;Database Patch Set Update : 12.1.0.2.160719 (23054246)
Today, there is no patch to download for this configuration. There is one for April 2016 PSU but there is still a conflict with patch 24310028
To be able to continue, I’ve removed following patches from the 12.1 source:
[oracle@HP121 ~]$ $ORACLE_HOME/OPatch/opatch rollback -id 23177536 [oracle@HP121 ~]$ $ORACLE_HOME/OPatch/opatch rollback -id 24310028
But then, the parameter “encrypt_new_tablespaces” that has been introduced by 24310028 is unknown:
SQL> startup ORA-01078: failure in processing system parameters LRM-00101: unknown parameter name 'encrypt_new_tablespaces'
You have to remove this one from the SPFILE. Basically it forces TDE when in the cloud, even when not specified in the DDL.
I hope this patch will be included in future DBaaS versions. Currently, the Oracle Public Cloud has no simple button to upgrade a service from 12.1 to 12.2 and the easiest way to do it should be remote cloning of PDB. But with those version mismatch and patch to apply, unplug/plug is probably easier.
Hi Frank,
I found an article on the web about cloning a PDB from 12.1 to 12.2 and thought – what a great idea. So I tried it out.
https://mikedietrichde.com/2017/11/29/cloning-a-pdb-from-oracle-12-1-to-oracle-12-2
Of course, it didn’t work. I ran into the exact same problem you have outlined in this article. You wrote it in late 2016, but I was just wondering if you’ve made any progress since or found any viable workarounds – besides reverting to unplug/plug? Even the latter approach has its fair share of complications and hoops to jump through.
SQL> create pluggable database NEW_EGDB105 from EGDB105@sourcedblink file_name_convert=(‘C:\Oracle12102\CDB\ORADATA\CDB\EGDB105′, ‘D:\Shawn\CDB\ORADATA\CDB\EGDB105′); * ERROR at line 1: ORA-17628: Oracle error 17630 returned by remote Oracle server ORA-17630: Mismatch in the remote file protocol version client server
Thanks,
-Shawn
Hi Shwan. The patch on the source is the solution. Regards, Franck.