--查看主库监听

 

--tnsnames.ora文件内容

 

--主库tnsping测试网络服务名是否正常

 

--查看备库监听

 

--查看备库远程归档路径

--备库tnsping测试网络服务器名是否正常

 

tnsping测试下来也都是通的，这就比较奇怪了，但是ORA-12514错误很明显是指监听方面的问题，导致服务名无法解析，由于主备库采用的是同一个实例名，因此两边的instance_name用的都是prd，乍一看好像很正常，但是解析确实出现了问题，那么怎么办呢？

 

之前仅仅只是给服务器配置了一个动态监听，内容如下：

 

--主库监听listener.ora

 

--主库监听listener.ora

 

可以看到，区别仅仅是主机名不同而已，一个是prd，另一个是std，静态监听并未配置，即SID_LIST_LISTENER这一项里面的栏目，那么现在为主备库都配置一个监听。静态监听可以用netmgr配置，这里为了方便，不再进入图形界面执行该命令，而是直接通过修改listener.ora文件来达到目的，其效果是一样的，在原来的listener.ora文件中的SID_LIST_LISTENER中添加如下内容（红色部分）：

 

 

注意，加上的内容中，SID_NAME，即instance_name，而GLOBAL_DBNAME，即tnsnames.ora中的SERVICE_NAME，由于tnsnames.ora中的SERVICE_NAME都是prd，因此这里的两个名字是一样的，不会有什么影响，把修改好的文件替换掉原文件，再重新加载监听文件

 

 

注意，这个UNKNOW的prd实例对应的服务名prd就是刚才我们通过静态监听发现的服务名，同那样地，备库也重新加载监听：

 

 

可以看到，此时备库也多了一个UNKNOWN的，和实例名prd对应的服务prd

 

--再次查看主库远程归档路径状态

 

原来dest_id=2的那个远程归档路径的ORA-12514的问题解决了，此时归档日志就可以通过网路远程传输到备库相应的归档路径中了，再执行redo apply也不会有任何问题了。

 

总结：

 

这个案例是由于主备库都采用了同一个实例名产生的问题，当我们只配置一个默认的动态监听，会发现主库无法监听到远程备库的相应服务，通过静态监听手动添加上与实例名对应的服务，才能解决这个问题。使用静态监听的另一个好处是，当Oracle数据库实例还没有启动的时候，就会先把对应的服务和实例名，通过静态配置的监听文件给启动起来，而不是等启动实例后由pmon进程再去启动，这样速度更快。不用再等待若干秒，我们的客户端就可以通过静态监听立即脸上数据库服务器了，也就是说，可以不依赖服务器进程，完成监听的工作。

http://m.blog.csdn.net/blog/aaron8219/39892437