先说一个在 Oracle 19c 安装过程中容易被忽略的关键点：当出现 INS-30014 或 PRVF-0002 错误时，绝大多数情况都是因为 /etc/hosts 文件配置有误。不是没有配置，而是写了一个“看似正确、实际错误”的版本。
/etc/hosts 必须同时映射短主机名和完整域名，且严禁使用 127.0.0.1
Oracle 19c 的安装程序并没有那么智能，它会严格调用 hostname -f 来获取完整主机名，例如 rac1.example.com。接着，安装程序会拿这个字符串去查询 /etc/hosts，且不会采用任何降级策略——既不会回退到 127.0.0.1，也不会转而询问 DNS。因此，配置文件必须一步到位。
常见的错误写法有以下两种：
127.0.0.1 rac1—— 即使hostname输出为rac1，也会失败，因为hostname -f返回的是rac1.example.com，而该完整域名在 hosts 中根本不存在。127.0.0.1 rac1.example.com rac1—— IP 使用的是本地回环地址，但 Oracle 要求必须指定本机真实网卡 IP，例如192.168.10.10。
正确的配置其实非常简洁：
192.168.10.10 rac1.example.com rac1为了验证配置是否生效，可以执行下面三条命令：
hostname→ 应输出rac1hostname -f→ 应输出rac1.example.comgrep rac1 /etc/hosts→ 应返回包含192.168.10.10的那一行，且两个主机名均在其中
runcluvfy 报 PRVF-4657 或 PRVF-4664 的真实检查逻辑
这个错误的根源并非 DNS 问题，而是一套严格的本地闭环验证机制。Oracle 会调用系统的 getaddrinfo() 和 gethostbyaddr() 进行正向与反向解析，并要求两者返回的结果完全一致。
- 正向解析：用
rac1.example.com查询 IP → 必须得到192.168.10.10 - 反向解析：用
192.168.10.10查询主机名 → 必须返回rac1.example.com（不能是rac1或其他别名）
以下几个常见陷阱容易被忽略：
/etc/hosts中该 IP 行后面多了一个空格或制表符，导致第二个字段被截断- 虚拟机克隆后未修改 IP，虽然
hostname -f已更新，但 hosts 文件仍是旧配置 - 容器环境中的
hostname是随机生成的（例如8a3f2b1e4c7d），而/etc/hosts没有同步更新，也未挂载外部 hosts 文件
快速验证可以使用 nslookup 命令：
nslookup rac1.example.com→ 检查是否返回192.168.10.10nslookup 192.168.10.10→ 检查是否返回rac1.example.com
需要注意的是，第二步依赖于 DNS 的 PTR 记录；如果不走 DNS，仅靠 /etc/hosts 自身无法完成反向解析。因此，必须确保 hosts 配置已覆盖所有需求。
SCAN 域名也遵循同一套解析逻辑，但要求更为严格
在 RAC 集群场景下，scan.example.com 并非可选项，它与节点主机名一样，受同一套解析校验的约束，并且存在额外的条件：
- 解析结果必须返回 2–3 个不同的 IPv4 地址（即
getaddrinfo()返回 ≥2 个AF_INET结构体） /etc/hosts中不能写成单行多个 IP，例如192.168.10.10 192.168.10.11 192.168.10.12 scan.example.com这种写法无效- 必须分成三行写入，每行一个 IP 后跟相同的域名：
192.168.10.10 scan.example.com
192.168.10.11 scan.example.com
192.168.10.12 scan.example.com
否则 srvctl start scan 会静默失败，或者 srvctl status scan_listener 会显示监听器只绑定了部分 VIP。这种情况典型地体现了“约定大于配置”的原则——少写一行都不行。
最后提醒一点：修改完 /etc/hosts 后，hostname -f 的输出可能仍缓存了旧值，尤其是在 systemd 系统上。不要仅凭命令输出判断，而应以 getaddrinfo("rac1.example.com", ...) 实际调用的结果为准——这意味着最好重新运行安装程序，或者至少重启 systemd-hostnamed 服务，迫不得已时直接重启系统。毕竟，与其花费半小时逐项排查，不如先花两分钟重启一下，很多问题往往就此迎刃而解。
