Oracle监听器绑定多IP必须用ADDRESS显式声明每个实际IP，HOST仅作别名且DNS解析可能出错；LOCAL_LISTENER/REMOTE_LISTENER须设为客户端可达的VIP或业务IP；tnsnames.ora中HOST应直接写VIP而非主机名；RAC/VIP漂移需由CRS托管监听资源确保生命周期一致。
Oracle监听器绑定多个IP地址时，listener.ora里该写HOST还是ADDRESS
必须用address块显式声明每个ip，不能只靠host参数靠dns解析来回绕。oracle监听器启动时只认address列表里的具体ip+端口组合，host只是别名，如果对应多个ip（比如双网卡或vip），它只会取第一个解析结果——大概率绑错网卡。
常见错误现象：lsnrctl status显示监听在127.0.0.1或私网IP上，客户端连VIP超时；或者tnsping通但sqlplus报ORA-12541: TNS:no listener。
-
ADDRESS必须写实际IP（如192.168.10.100），不写主机名 - 每个IP配一个独立
ADDRESS，不要试图用逗号分隔 - 若启用VIP（如RAC或故障转移场景），VIP必须作为独立
ADDRESS加入，且确保该IP已由系统激活（ip addr show能查到） - 监听端口建议统一，避免不同IP走不同端口导致客户端配置混乱
双网卡环境下，LOCAL_LISTENER和REMOTE_LISTENER设成什么才不丢连接
这两个参数决定数据库实例向监听器“自报家门”的地址。设错会导致PMON注册失败，客户端查不到服务名，或者负载均衡器收不到真实节点地址。
关键点：它们的值必须是客户端能直接访问的IP（通常是VIP或业务网IP），不是本地网卡IP，更不能是localhost。
-
LOCAL_LISTENER应指向本机监听的VIP或业务网IP+端口，例如(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.10.100)(PORT=1521))) -
REMOTE_LISTENER在RAC中指向SCAN监听器，在单机双网卡高可用场景可留空或指向同集群其他节点的VIP - 修改后执行
ALTER SYSTEM SET LOCAL_LISTENER=... SCOPE=BOTH;，再手动触发注册：ALTER SYSTEM REGISTER; - 验证是否注册成功：
lsnrctl services <listener_name>里能看到service_name下有INSTANCE_NAME条目
tnsnames.ora里用VIP连接时，为什么有时连的是物理IP
不是VIP没生效，而是客户端解析或路由层面绕过了VIP。典型原因是tnsnames.ora里HOST写的是主机名，而该主机名在客户端/etc/hosts或DNS里被解析成了物理IP（比如db01 → 192.168.20.10），而不是VIP（192.168.10.100）。
- 最稳做法：
tnsnames.ora中HOST直接写VIP的IP，不写主机名 - 如果必须用主机名，确保客户端
/etc/hosts里该主机名只映射VIP，且排在物理IP前面 - 检查客户端是否启用了
USE_SHARED_SOCKET=TRUE（Windows注册表或sqlnet.ora），这会干扰VIP绑定行为，建议关闭 - 用
truss -f -t bind,connect sqlplus /@mydb（Linux）或Process Monitor（Windows）抓底层socket调用，确认connect目标IP是不是VIP
RAC或Data Guard切换后，监听器不自动响应VIP漂移怎么办
监听器本身不会监听“VIP是否飘过来了”，它只认listener.ora里静态写的ADDRESS。如果VIP从节点A飘到节点B，但节点B的listener.ora没配这个VIP，或者监听没重启，就会失联。
根本解法不是让监听器“感知”VIP，而是确保VIP始终在监听配置中，且监听服务随VIP启停。
- 在集群资源管理（如Oracle Grid Infrastructure）中，把监听器定义为VIP的依赖资源，VIP up → 监听器start
- 不要用
lsnrctl start手工启监听，必须通过crsctl start res <listener_resource>交由CRS托管 - 检查监听资源状态：
crsctl stat res -t | grep lsnr，确认其online且绑定正确节点 - 若用脚本管理，监听启动前先用
ip addr show | grep <vip>校验VIP是否存在，不存在则退出，避免监听绑错
真正麻烦的从来不是配置几行ADDRESS，而是VIP、监听器、数据库实例、集群资源这四者的生命周期没对齐——其中一个没按约定启停，整个链路就断在你看不见的地方。
