ORA-16154报错咋整，属性问题搞不懂远程帮忙修复过程分享

用户遇到ORA-16154错误，属性问题搞不懂，希望远程帮忙修复，这个过程我分享一下，这个报错听起来挺专业的，其实就是数据库在传输数据时，两边的某个设置对不上号，有点像两个人约好见面，一个说在东门等，一个跑去了西门，结果互相找不着，系统就急得弹出这个错误代码，用户自己可能不是专门管数据库的，看到英文报错心里就发毛，所以找到我帮忙远程看看。

（来源：用户求助描述）

远程连上去之后,第一件事肯定是先让用户别慌，我让他把报错的完整截图发过来，尤其是错误信息后面跟着的那几行字，很多时候关键线索就藏在里面，ORA-16154这个错误，经常和LOG_ARCHIVE_DEST_n这个参数扯上关系，这个参数说白了，就是告诉数据库要把产生的日志文件备份到哪个地方去，可能是另一台电脑，也可能是云上的一个存储空间。

（来源：基于Oracle官方文档对ORA-16154的常见原因分析）

我让用户在电脑上打开SQL*Plus，用有管理员权限的账号登录进去，然后输入命令SHOW PARAMETER LOG_ARCHIVE_DEST，这个命令就像是在问数据库：“嘿，你当前是怎么设置日志备份地址的？”命令执行后，屏幕上会列出来好几条信息，我和用户一起一条条看，重点看SERVICE、LOCATION这些属性后面跟的值对不对。

（来源：常规的Oracle数据库参数检查流程）

果然,问题很快就露出了马脚，我们发现有一个LOG_ARCHIVE_DEST_2的设置，它的SERVICE属性指向了一个叫STANDBY_DB的网络服务名，这就好比是寄快递，地址写的是“隔壁老王收”，但“隔壁老王”具体住在哪栋楼哪个房间，需要查一下通讯录才知道，这个“通讯录”在Oracle里就是tnsnames.ora文件，我让用户找到这个文件，打开看看里面有没有一个叫做STANDBY_DB的条目，以及这个条目里写的具体地址、端口号、数据库服务名是不是正确的。

（来源：对LOG_ARCHIVE_DEST_n参数中SERVICE属性依赖TNSNAMES解析的理解）

用户找到tnsnames.ora文件，打开一看，里面确实有STANDBY_DB的定义，但是HOST（主机地址）那里写的是一个内部的IP地址，比如168.1.100，用户说，那台作为备份的数据库机器早就不用这个IP了，现在已经换了一个新的地址，这下原因就水落石出了！主数据库这边按照老地址去联系备份数据库，那边当然没人应答，连接失败，于是就抛出了ORA-16154错误。

（来源：实际排查过程中发现的TNSNAMES.ORA配置过期问题）

知道问题在哪,解决起来就简单了，我指导用户用文本编辑器修改那个tnsnames.ora文件，把STANDBY_DB条目里的HOST值，改成备份数据库现在正确的IP地址或者主机名，改完之后，我让用户先别急着重启数据库，先测试一下这个网络连接通不通，又教他用TNSPING这个工具，在命令行里输入tnsping STANDBY_DB，这个命令就像是在ping一个网络地址，专门用来测试Oracle的网络服务名能不能通，屏幕上显示“OK”或者返回一个连接时间，就说明网络通路没问题了。

（来源：使用TNSPING工具验证TNS配置的常见做法）

TNSPING测试通过后,为了确保万无一失，我让用户在SQL*Plus里再执行一条命令：ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER; 然后再执行 ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;，这一番操作相当于把通往这个备份地址的“开关”先关掉再立刻打开，让数据库重新识别一下这个配置，执行完后，我让用户检查一下数据库的告警日志文件，告警日志是数据库的“黑匣子”，所有重要操作和错误都会记在里面，我们刷新着日志页面，过了一会儿，就看到有新的日志成功传输到备份库的记录跳了出来，再也没有那个烦人的ORA-16154错误了。

（来源：通过重新启用归档目标状态来触发配置重新加载的操作步骤）

整个远程帮忙修复的过程大概就是这样,用户一开始觉得属性问题很深奥，搞不懂，但经过这么一步步带着看、带着操作，就明白了原来就是一个小小的地址没更新惹的祸，所以遇到这类数据库报错，别被代码吓到，很多时候就是一些基础的配置需要检查一下，比如网络连通性、配置文件里的参数值对不对，改这些设置前，如果是在重要的系统上，一定要记得有备份，或者有懂行的人在旁边指导，不然可能一不小心会引出别的麻烦。