Oracle RAC中SCAN VIP由Clusterware自动管理，不可手动添加；srvctl add scan需满足DNS解析正常、网络配置同步、OCR资源完整三个硬条件，否则报错。
SCAN VIP 不存在时 srvctl add scan 会直接报错
oracle rac 中 scan vip 是由 clusterware 自动管理的，不能手动添加。执行 srvctl add scan 前必须确保底层 dns 或 gns 已正确解析 scan 名称，且至少一个 scan vip 尚未被完全清除（否则命令会提示 “prcr-1076: failed to start resource ora.scan1.vip” 或类似）。真实场景中，多数“丢失”其实是 vip 资源状态为 offline 或被 crsctl delete resource 误删——此时加不回，得先恢复底层依赖。
- 检查当前 SCAN 状态：
srvctl config scan；若输出为空，说明 SCAN 资源元数据已丢失 - 确认 DNS 解析是否正常：
nslookup your-scan-name，必须返回 3 个 A 记录（对应 3 个 SCAN VIP） - 如果 SCAN VIP 对应的网络（如
net1）已被禁用或子网变更，srvctl add scan必定失败，需先用srvctl modify network同步
srvctl add scan 执行前必须满足的三个硬条件
这不是一个独立命令，它依赖 OCR 中已有 SCAN listener、网络配置、以及未被破坏的 GI 安装结构。跳过任一条件都会导致资源注册失败或后续启动异常。
- GI 版本 ≥ 11.2.0.2：低于此版本不支持 SCAN 动态添加，只能重装或打补丁
- OCR 中仍存在
ora.scan1.net1.network类型资源（可用crsctl stat res -t | grep scan.*network验证），否则需先运行srvctl add network - SCAN 名称在
/etc/hosts中不能有静态条目——若有，必须删除，否则 DNS 解析被绕过，VIP 绑定到错误网卡
重建 SCAN listener 时 srvctl add scan_listener 的参数陷阱
SCAN listener 不是绑定到单个 VIP，而是监听所有 SCAN VIP 所在网络的端口（默认 1521）。如果漏掉 -l 指定监听器名，或用了错误的 -s（SCAN 名称），会导致 listener 启动后无法接受连接。
- 标准写法：
srvctl add scan_listener -l LISTENER_SCAN1 -s your-scan-name，其中your-scan-name必须与srvctl config scan期望的一致 - 不要指定端口（
-p）：SCAN listener 端口由 Oracle 固定为 1521，显式指定反而触发校验失败 - 如果集群已有旧 listener 名（如
LISTENER_SCAN2），新加的必须用新编号，否则srvctl add报 “PRCN-1044” 冲突 - 添加后立即启动：
srvctl start scan_listener，否则lsnrctl status LISTENER_SCAN1查不到监听实例
OCR 中 SCAN 相关资源恢复后仍连不上？重点查这三处
即使 srvctl config scan 和 crsctl stat res -t | grep scan 显示全部 ONLINE，客户端仍可能 TNS-12545 或超时——问题往往不在 SCAN 本身，而在下游联动环节。
- 检查 SCAN listener 是否真在监听所有 SCAN VIP：
netstat -tlnp | grep :1521，应看到多个*:1521条目，而非仅127.0.0.1:1521 - 验证数据库实例是否注册进 SCAN listener：
lsnrctl services LISTENER_SCAN1，输出里必须包含service_name对应的数据库服务，否则需检查数据库参数remote_listener是否设为your-scan-name:1521 - 防火墙常被忽略：SCAN VIP 所在网卡的入向 1521 端口必须放行，且不能只开物理网卡——虚拟 SCAN VIP 绑定的是 cluster_interconnect 网络别名，需确认对应接口名（如
eth1:1）的 iptables 规则
crsctl stat res -p ora.scan1.vip 里的 USR_ORA_IF 和 USR_ORA_SUBNET 就很关键。
