Oracle ORA-12154,ORA-19527异常故障处理

记一次搭建DG的故障处理：

最初接到电话，需要支持一下驻场人员搭建DG，与驻场人员联系上后，说明了问题

起初问题：

仅仅主库日志无法传输到备库。

dest_2具有如下错误：

ORA-12154 TNS：could not resolve the connect identifier specified
并且sqlplus可以使用tnsname正常连接，监听正常，第一反应一定是dest_2中配置的service不等于tnsname中的连接串名称，已经遇到过很多次了。这里是引用

日志传输参数配置：

tnsname.ora配置：

这里dyhscdbdg是备库的tnsname，这里的service_name我认为应该是db_unique_name,因为在备库配置了db_uniqe_name，所以service_name=db_unqie_name+domin_name,并且domin_name不存在，所以db_unique_name=service_name,此处修改后再次尝试主库日志传输。

alter system set log_archive_dest_state_2='defer' scope=both;
alter system set log_archive_dest_state_2='ENABLE' scope=both;

仍然出现以上问题，并且sqlplus也是可以正常连接，监听重启后也正常，所以tnsname以及监听等网络问题排除

只能跟踪备库警告日志了：
在主库进行日志切换，跟踪主库警告日志

还是ORA-12154 TNS：could not resolve the connect identifier specified的问题

再次查看DG主备库整体配置参数：

跟踪一下备库警告日志：

出现以上错误
我这边怀疑是主备路径不一致的情况，但是数据文件已经成功restore了，并且他说主备数据文件路径是一致的，所以此处也没问题。
但是进入到数据文件存放位置时，发现没有redo以及standby redo都没有被创建出来，那么此处一定有问题，再次仔细查看警告日志。这里是引用

可以看出已经自动执行了clearing操作，正常应该已经创建出来了，但是细心发现，有一个异常报错（ORA-19527）physical standby redo log must be renamed

这应该是redo以及standby redo没有被正常创建的问题所在把。

并且，在排查问题过程中，有一些日志已经被传到备库了，此处认为是备库fal主动去主库中抓取的日志，并且通过如下方式查询备库事件信息。这里是引用

不断进行clearing complete 但是redo却没有重建出来，正常情况下是只clearing一次即可。

抓了两个日志之后又无法FAL抓取了，通过v$managed_standby查看备库等待情况，以及主备进程对应状态。

多次尝试关闭日志传输，再开启日志传输，故障都没有进展
那么现在唯一异常的问题就是备库警告日志中clearing操作出现（ORA-19527）physical standby redo log must be renamed

手动执行一次clearing：

也出现问题

…此时同事远程异常中断，只能第二天处理
第二天上午，询问进展如何，他说日志居然传输过来了，但是在主库有两个异常的点。

该错误消失，并且status变为valid。

但是在主库警告日志中还是具有如下错误：

ORA-12154：TNS：could not resolve the connect identifier specified

解决：
我这边让他重新从主库给备库恢复一个控制文件来解决（ORA-19527）physical standby redo log must be renamed的问题：

重新恢复控制文件后，问题解决，备库可以正常接收已经应用日志。

异常的信息：主库没有正常传输日志的痕迹记录，备库中控制文件记录了standby redo log的信息，当开启日志应用时，会自动执行clearing操作重建standby redo log，但为什么说no standby redo logfiles，并且手动在主库切换日志，在主库alert日志中 仅仅有归档的信息，没有日志传输的信息。

解决办法：
删除控制文件中记录的standby redo信息，我们手动创建standby redo log。

创建好standby redo log后，手动在主库进行日志切换，观察日志传输情况：

备库情况：

整体故障解决。

总结：

备库的控制文件出现问题会导致主库传输日志出现ORA-12154 TNS：could not resolve the connect identifier specified的问题，没有任何道理，但是不得不接受现实。