ORA-17629
ORA-17629 means that it cannot connect to the remote database because of some underlying errors occurred, most likely, there're some error returned. In the error stack, ORA-17627 tells us the true error.
In this post, there're 2 underlying errors that throw ORA-17629 and ORA-17627.
ORA-12514
When we tried to clone a remote PDB via a DB link, we got ORA-17629 ORA-17627 and ORA-12514 in error stack like this:
SQL> create pluggable database ORCLPDB1 from ORCLPDB@ORCLPDB_LK file_name_convert=('ORCLPDB','ORCLPDB1') parallel 20;
create pluggable database ORCLPDB1 from ORCLPDB@ORCLPDB_LK file_name_convert=('ORCLPDB','ORCLPDB1') parallel 20
*
ERROR at line 1:
ORA-65169: error encountered while attempting to copy file +DATA/ORCLCDB/ORCLPDB/DATA_3_01.dbf
ORA-17627: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
ORA-17629: Cannot connect to the remote database server
In the error stack, the most important error message we can see is ORA-12514.
Solutions to ORA-12514 for Common Situations
As I said in another post. There're several possibilities to see ORA-12514 when using a db link to connect a remote database.
- The remote database is down. This is the most common cause of ORA-12514.
- The connect descriptor in the local tnsnames.ora file has been changed.
- The service name of the remote database has been changed.
- Another listener is used for servicing the remote database.
So you should test at least two things:
- DB Link.
- Connect Identifier.
You may use the following statement to test it.
SQL> select sysdate from dual@ORCLPDB_LK;
SYSDATE
-------------------
2021-07-31 19:58:39
When you saw a system date time returned, the connectivity of DB link is alright.
You may use tnsping to test the reachability of the database.
[oracle@primary01 ~]$ tnsping BOSTON_ERPPDB
...
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.10.10.1)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ERPPDB)))
OK (20 msec)
When you saw OK message responded, the connectivity of connect identifier is alright.
If you have checked all the above items and nothing found, you should be aware of something else. For example, there could be various scenarios in a RAC database.
RAC System
For a RAC database, it's a little different. Since you have more than one node, you have to test the remote connection not only on the node you operate, but also on ALL nodes.
For instance, it may look fine when you test the connectivity of the connect identifier on node 1, but when you turn to node 2, it tells another story.
[oracle@primary02 ~]$ tnsping BOSTON_ERPPDB
...
TNS-03505: Failed to resolve name
As I said in How to Resolve TNS-03505: Failed to resolve name, it may be because you forgot to add a connect identifier on the second node in the first place. Consequently, when the cloning performed on the node 2 because of working parallelism or something, it cannot find a valid connect identifier to connect to.
Solution to ORA-12514 for RAC DB
So the solution is obvious, just add the same entry of connect identifier on the rest of nodes. Here I copied tnsnames.ora from node 1 to this node to make all nodes equivalent.
[oracle@primary02 ~]$ cd $ORACLE_HOME/network/admin
[oracle@primary02 admin]$ scp -p primary01:$PWD/tnsnames.ora ./
tnsnames.ora 100% 6891 3.4MB/s 00:00
This solves the problem.
ORA-28002
When we tried to clone a remote PDB via a DB link, we got ORA-17629 ORA-17627 and ORA-28002 in error stack like this:
SQL> create pluggable database ORCLPDB1 from ORCLPDB@ORCLPDB_LK file_name_convert=('ORCLPDB','ORCLPDB1') parallel 20;
create pluggable database ORCLPDB1 from ORCLPDB@ORCLPDB_LK file_name_convert=('ORCLPDB','ORCLPDB1') parallel 20
*
ERROR at line 1:
ORA-17627: ORA-28002: the password will expire within 7 days
ORA-17629: Cannot connect to the remote database server
ORA-28002 in this case means that the user of database link is in the grace time of password expiration. You should handle the coming expiration before cloning PDB.
Solution to ORA-28002
Except for the solutions we have talked about in How to Resolve ORA-28002, you can take the following steps to solve ORA-28002.
Expire the User's Password
In the source PDB, we expire the user in all containers. In this case, it's SYSTEM.
SQL> alter user system password expire container=all;
User altered.
Set a New Password for the User
We provide the original password for it.
SQL> alter user system identified by welcome1;
User altered.
Then try again.