Recently my customer patched its 184.108.40.206 databases with the Bundle Patch 170718 on the new servers (half of the customer’s environment). The old servers are still on 161018 Bundle Patch.
We realized that we could not move anymore the databases from the old servers to the new ones because the duplicate from active database was failing with this error:
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-03002: failure of Duplicate Db command at 09/11/2017 15:59:32
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-03009: failure of backup command on prmy1 channel at 09/11/2017 15:59:32
ORA-17629: Cannot connect to the remote database server
ORA-17630: Mismatch in the remote file protocol version client 2 server 3
The last lines shows the same error that Franck blogged about some months ago.
Oracle 12.2 had introduced incompatibility with previous releases in remote file transfer via SQL*Net. At least this is what it seems. According to Oracle, this is due to a bugfix present in Oracle 12.2
Now, the bundle patch that we installed on BP 170718 contains the same bugfix (Patch for bug 18633374).
So, the incompatibility happens now between databases of the same “Major Release” (220.127.116.11).
There are two possible workarounds:
- Apply the same patch level on both sides (BP170718 in my case)
- Apply just the patch 18633374 on top of your current PSU/DBBP (a merge might be necessary).
We used the second approach and now we can setup Data Guard again to move our databases without downtime:
oracle@oldserver $ opatch lspatches
18633374; <<<<<< FIX!
24340679;DATABASE BUNDLE PATCH: 18.104.22.168.161018 (24340679)
oracle@newserver $ opatch lspatches
25869760;DATABASE BUNDLE PATCH: 22.214.171.124.170718 (25869760)
Latest posts by Ludovico (see all)
- The fear of (availability) loss is a path to the dark side. - October 5, 2020
- Data Guard, Easy Connect and the Observer for multiple configurations - August 14, 2020
- Script to check Data Guard status from SQL - August 12, 2020