{ "date": "2016-11-20T19:42:32", "slug": "12cr2-upgrade-by-remote-clone-workaround-ora-17630-in-dbaas", "link": "https://www.dbi-services.com/blog/12cr2-upgrade-by-remote-clone-workaround-ora-17630-in-dbaas/", "title": { "rendered": "12cR2: Upgrade by remote clone – workaround ORA-17630 in DBaaS" }, "content": { "rendered": "

By Franck Pachot

\n

.
\nEasier 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:

\n
ORA-17628: Oracle error 17630 returned by remote Oracle server\nORA-17630: Mismatch in the remote file protocol version client  server
\n

\n

Remote cloning

\n

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:

\n
13:43:55 HP122A SQL> create pluggable database PDB1 from PDB1@HP121A@HP121A keystore identified by \"Ach1z0#d\" relocate;\ncreate pluggable database PDB1 from PDB1@HP121A@HP121A keystore identified by \"Ach1z0#d\"\n*\nERROR at line 1:\nORA-17628: Oracle error 17630 returned by remote Oracle server\nORA-17630: Mismatch in the remote file protocol version client  server
\n

Alert.log in target

\n

The error is received from the remote side. There is not a lot in local alert.log

\n
create pluggable database PDB1 from PDB1@HP121A@HP121A keystore identified by * relocate\nErrors in file /u01/app/oracle/diag/rdbms/hp122a/HP122A/trace/HP122A_ora_29385.trc:\nORA-17628: Oracle error 17630 returned by remote Oracle server\nORA-17630: Mismatch in the remote file protocol version client  server
\n

Alert.log in source

\n

More information about versions in the remote alert.log:

\n
Errors in file /u01/app/oracle/diag/rdbms/hp121a/HP121A/trace/HP121A_ora_21344.trc:\nORA-17630: Mismatch in the remote file protocol version client 3 server 2
\n

Patch

\n

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:

\n

Patch 18633374: COPYING ACROSS REMOTE SERVERS: ASMCMD-8016, ORA-17628, ORA-17630, ORA-06512

\n

And you can download it at https://updates.oracle.com/download/18633374.html

\n

My 12.1.0.2 DBaaS has the July 2016 PSU applied, as well as a merge of patches specific for the cloud:

\n
[oracle@HP121 ~]$ $ORACLE_HOME/OPatch/opatch lspatches\n19469538;\n24310028;\n22366322;\n20475845;\n18043064;\n21132297;\n23177536;Database PSU 12.1.0.2.160719, Oracle JavaVM Component (JUL2016)\n23054246;Database Patch Set Update : 12.1.0.2.160719 (23054246)
\n

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

\n

To be able to continue, I’ve removed following patches from the 12.1 source:

\n
[oracle@HP121 ~]$ $ORACLE_HOME/OPatch/opatch rollback -id 23177536\n[oracle@HP121 ~]$ $ORACLE_HOME/OPatch/opatch rollback -id 24310028
\n

But then, the parameter “encrypt_new_tablespaces” that has been introduced by 24310028 is unknown:

\n
\nSQL> startup\nORA-01078: failure in processing system parameters\nLRM-00101: unknown parameter name 'encrypt_new_tablespaces'
\n

You have to remove this one from the SPFILE. Basically it forces TDE when in the cloud, even when not specified in the DDL.

\n

So what?

\n

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.

\n", "protected": false } }