根本原因是VIP漂移后新节点监听器未监听该VIP且实例未向其注册，需用srvctl添加监听资源并更新LOCAL_LISTENER参数执行ALTER SYSTEM REGISTER。
Oracle 19c RAC节点迁移后客户端无法通过VIP接入，根本原因不是VIP没漂过去，而是客户端连上的那个VIP地址，背后没有监听器在监听它——监听器只认自己节点的VIP，不认飘过来的VIP。
tnsnames.ora里写VIP却连不上，其实是监听没注册该地址
迁移后你改了/etc/hosts或DNS，让rac1-vip解析到新节点IP，但新节点上的LISTENER_rac2默认只监听rac2-vip和rac2，对rac1-vip完全无感知。哪怕ping rac1-vip通、ip addr show能看到该地址绑在网卡上，lsnrctl status LISTENER_rac2的输出里也不会出现(HOST=rac1-vip)这一行。
- 不要手动改
listener.ora加(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521))——11.2+ RAC中listener.ora被endpoints_listener.ora接管，直接编辑无效 - 必须用
srvctl添加监听资源：srvctl add listener -l LISTENER_RAC1_VIP -s -p 1521 -o $ORACLE_HOME - 再用
srvctl modify listener -l LISTENER_RAC1_VIP -s -a "(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521))"绑定VIP - 最后
srvctl start listener -l LISTENER_RAC1_VIP启动，且确认crsctl stat res -t | grep LISTENER_RAC1_VIP是ONLINE
LOCAL_LISTENER参数仍指向旧节点IP，导致SCAN跳转失败
即使你用VIP直连成功了，如果客户端实际走的是SCAN（更常见），那ORA-12545仍会复现：SCAN返回的local_listener地址还是旧节点的rac1-vip，而该VIP现在在新节点上，但数据库实例没重启，LOCAL_LISTENER参数没更新，注册信息仍是错的。
- 登录新节点上的实例，执行：
ALTER SYSTEM SET LOCAL_LISTENER='(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521))' SCOPE=BOTH; - 立刻执行：
ALTER SYSTEM REGISTER;（不是ALTER SYSTEM REGISTER FORCE） - 检查是否生效：
lsnrctl status LISTENER_SCAN1→ 输出中Services Summary下对应service应显示Instance "orcl1", status READY，且Listening Endpoints Summary含(HOST=rac1-vip) - 若仍不显示，查
$GRID_HOME/log/<node>/agent/oraagent_grid.log，搜索Failed to register或TNS-12560
DNS或/etc/hosts残留导致VIP解析不一致
迁移过程中最容易被忽略的是客户端和RAC节点自身对VIP的解析不一致。比如你在客户端/etc/hosts写了192.168.10.81 rac1-vip，但RAC节点上DNS返回的是192.168.20.81，结果客户端连过去，TCP握手成功，但监听器拒绝服务（ORA-12514）或根本没响应（ORA-12170）。
- RAC所有节点必须禁用
/etc/hosts中所有VIP和SCAN条目，强制走DNS - 客户端可保留
/etc/hosts，但必须确保所有节点和客户端解析结果完全一致：nslookup rac1-vip三台机器都返回相同IP - 验证命令别用
ping，改用telnet rac1-vip 1521——能通才说明监听真在听 - 如果用DNS，确保
rac1-vip是A记录，不是CNAME；CNAME在19c+会被getaddrinfo()拒绝
真正卡住人的从来不是“VIP能不能漂”，而是“漂过去之后，谁来监听它、谁来注册它、谁来解析它”。三个环节缺一不可，任意一个断在中间，客户端看到的都是“连得上但打不开门”。
