今天在做数据迁移测试时遇到一个dblink的问题，有点意思！

为电信号码升级而专门准备一次数据迁移，说点题外话，虽然计划是在浙江省号码升级5月18号之前做DM,但是防止号码升级之后扔需要做增量迁移，所以提前准备一下，预防这种风险，对这种防患于未然的工作方法还是挺赞赏的！

我做迁移用到的一些表和存过，包都在数据库A 上，需要从A上拷贝到新的数据库B上，所以我就在B上建立到A的DB Link。先用下面的语句建的：

create public database link link_mig connect to A.USERNAME
identified by A.PSW using 'A.TNSNAMES'

建立之后发现无法连接到，查询A上的表，报oracle 错误：TNS:could not resolve service name。查看当前DBLINKS select * from user_db_links; ,也没有刚才配置的dblink，检查自己机器上配置的数据库B的 tnsnames配置，没有问题，在pl/sql下可以正常连接。

奇怪了，问题出在哪里呢？

经过查找资料，发现网上类似问题的朋友很多，都是配了dblink后无法访问到。原来，问题就出在tnsnames上，我现在只是在oracle客户端配置了要访问的A库服务实例，而不是在数据库B的serv端，所以用上面语句建立的dblink就访问不到了。

原因找到了，怎么解决呢？自然是去linux服务器上数据库B的tnsnames里添加A的配置了。这样做的前提是要你知道linux服务器口令，否则就只能麻烦DBA了。

还有没别的办法呢？（good question ！）

对了，还有一种配置dblink的方法就是：将A的服务实例配置直接用在建dblink的语句中：

create database link link_mig
connect to A.USERNAME identified by A.PSW
using '(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.142.202.12)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = fjept)
)
)';

这样就应该没问题了把？

还是不行！

原来，上面的这条语句拷到sql window 下后出现了些空格，而oracle的配置文件对格式很敏感，所以导致了上面的失败！赶紧去掉空格，将拷贝过去的tnsname放在一行里，然后再测试！

一切OK!!!

经验总结：

遇到问题，先查资料。细心＋耐心！

有时候还需要站在问题的外面来思考这个问题！

[@more@]

转的文章: