ORA-47921报错加域名字符串失败，ORACLE远程修复故障经验分享

前段时间,我们团队遇到了一个比较棘手的数据库问题，客户反馈他们的一个核心应用突然无法连接到数据库，检查日志后发现了一个之前没怎么见过的错误：ORA-47921，这个错误的信息大概是“在添加域名字符串时失败”，听起来有点让人摸不着头脑。

根据甲骨文官方文档的简单说明（来源：Oracle Database Error Messages, 19c Version），ORA-47921通常与Oracle的高级安全功能相关，特别是当数据库服务器尝试对客户端连接进行一种叫做“Kerberos”或“基于PKI的认证”时，在处理包含域名的主体名称（一串用来标识用户或服务的唯一名称）时发生了问题，但客户非常确定他们并没有启用这些复杂的安全认证，用的就是最普通的用户名密码验证，这就让问题变得奇怪了。

我们首先通过远程桌面连接到了出现问题的数据库服务器,第一步当然是检查数据库的警报日志，希望能找到更详细的线索，果然，在ORA-47921错误出现的时间点附近，警报日志里还记录了其他一些信息，提示说有一个后台进程在尝试解析某个网络服务名时遇到了困难，这让我们把注意力转向了网络配置。

我们检查了数据库的核心配置文件,也就是sqlnet.ora和listener.ora，这两个文件就像是数据库网络的交通规则说明书，在sqlnet.ora文件中，我们发现了一行配置：SQLNET.AUTHENTICATION_SERVICES = (NTS)，NTS是允许使用操作系统身份验证的一种设置，在Windows环境下，它常常会和Windows自身的域认证有所交互，虽然客户用的是用户名密码连接，但这个设置的存在可能触发了数据库去尝试进行一些与域名相关的后台查询。

我们注意到listener.ora文件中监听器的配置，其HOST项直接写的是服务器的计算机名，而不是完整的域名，写的是DBSERVER，而不是DBSERVER.COMPANY.COM，这是一个非常常见的配置习惯，但在某些特定的网络环境下，尤其是DNS解析设置不那么完善或者有多个网络接口卡时，就可能出问题。

为了验证DNS解析是否正常,我们在数据库服务器上打开命令提示符，尝试用ping DBSERVER和ping DBSERVER.COMPANY.COM两种方式去ping自己，结果发现，只使用计算机名DBSERVER时，解析出来的IP地址是一个内部的、非业务网络的IP（比如192.168.1.x），而使用完整域名DBSERVER.COMPANY.COM时，解析出来的才是业务网络正确的IP地址（比如10.10.10.x），问题似乎找到了根源！

我们的分析是：尽管应用连接看起来是简单的，但数据库内部的某些进程（可能是监听器本身，或者是与认证服务相关的后台进程）在运行时，会尝试获取服务器的完整规范域名，由于listener.ora中只配置了短主机名，而操作系统或网络配置又导致通过短主机名解析到了错误的IP地址，这个进程在构建那个“域名字符串”时就混乱了，最终抛出了ORA-47921错误，简单说，就是数据库“不知道自己完整的网络身份该怎么写”了。

找到了可能的原因,修复就相对直接了，我们的修复步骤如下：

1. 修改listener.ora文件：我们将监听器配置中的HOST项，从原来的短主机名DBSERVER，修改为完整的域名DBSERVER.COMPANY.COM，这样可以强制监听器在启动和运行时，明确地使用这个完整的网络标识。
2. 谨慎评估sqlnet.ora文件：鉴于客户并未使用操作系统认证，我们建议他们将SQLNET.AUTHENTICATION_SERVICES这一行注释掉（在前面加），或者将其值设置为NONE，这样可以避免任何不必要的与操作系统域认证的交互，减少潜在的干扰，客户同意了这一修改。
3. 重启监听器服务：保存配置文件后，我们通过命令行停止了监听器服务，然后再重新启动它，确保新的配置生效。
4. 全面测试：重启后，我们让客户从应用端重新发起连接，这次，连接非常顺利地建立了，之前的ORA-47921错误再也没有出现，为了确保万无一失，我们还测试了不同用户从不同网络节点的连接，均告正常。

这次远程修复给我们的经验是,有些数据库错误代码看起来非常高深，指向了某个具体的高级功能，但它的根本原因可能却隐藏在基础的网络配置之中，当遇到这类问题时，不能只看错误代码的表面意思，而是要系统地检查数据库的警报日志和网络配置文件，特别是主机名的解析是否准确、一致，对于监听器的HOST配置，在生产环境中，使用完整的域名通常比使用短主机名更可靠，可以有效避免因DNS解析歧义带来的各种诡异问题，这次经历再次证明了，越是基础的地方，越容易引发意想不到的故障。