12cR2: Upgrade by remote clone – workaround ORA-17630 in DBaaS

By Franck Pachot

.
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

Remote cloning

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

Alert.log in target

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

Alert.log in source

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

Patch

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.

So what?

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.