监听器绑错IP是Oracle连接失败的头号原因，ADDRESS必须显式写死业务网IP（如192.168.10.100），不可写主机名；HOST仅为别名，DNS解析首个IP（常为127.0.0.1或私网）将导致绑定错误；多网卡需为每个业务IP配独立DESCRIPTION块；LOCAL_LISTENER和tnsnames.ora中的HOST也须直填客户端可达的VIP或业务IP，禁用localhost、主机名等不可控值。
监听器绑错IP是Oracle连接失败的头号原因，不是端口没开、不是防火墙、不是数据库没起——而是listener.ora里ADDRESS写的HOST解析出了127.0.0.1或内网地址。
ADDRESS必须写死业务网IP，不能写HOST名
Oracle监听器启动时只认ADDRESS块里显式列出的HOST和PORT组合，HOST字段只是别名，不参与实际绑定。如果HOST=oradb01，而该主机名在/etc/hosts里第一行解析成127.0.0.1或192.168.20.10（私网），监听器就真的只绑到那个地址上。
- 正确做法：直接写业务网卡已激活的IP，例如
(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.10.100)(PORT=1521)) - 双网卡场景要为每个业务IP配独立
DESCRIPTION块，不要用逗号分隔，也不要复用同一块 - 查IP是否生效：运行
ip addr show，确认该IP在UP状态且属于业务网段 - 验证绑定结果：启动后执行
lsnrctl status，看输出里“Listening Endpoints Summary…”是否显示你写的IP，而不是127.0.0.1或意外的内网IP
LOCAL_LISTENER必须设为客户可直达的地址
LOCAL_LISTENER控制PMON进程向监听器注册实例的地址。设错会导致lsnrctl services里看不到服务，客户端查不到实例，报ORA-12514。
- 它不是数据库所在服务器的本地IP，而是客户端能直接访问的地址——通常是VIP或业务网IP
- 绝不能设为
localhost、127.0.0.1、oradb01（除非客户端DNS也解析成业务IP） - 正确示例：
ALTER SYSTEM SET LOCAL_LISTENER='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.10.100)(PORT=1521)))' SCOPE=BOTH; - 改完必须手动触发注册：
ALTER SYSTEM REGISTER;，否则不会立即生效
tnsnames.ora里的HOST别依赖DNS，直接写VIP IP
客户端连不上常不是监听器没起，而是tnsnames.ora里HOST写了主机名，结果被客户端自己的/etc/hosts或DNS解析成了物理IP而非VIP。
- 最稳妥：在客户端
tnsnames.ora中，HOST字段直接填VIP的IP，例如HOST=192.168.10.100 - 如果必须用主机名，确保客户端
/etc/hosts里该主机名对应的是VIP，且排在物理IP之前 - 测试解析是否走对：在客户端执行
tnsping PRODDB，看输出里“Attempting to contact”后面是不是你期望的IP - 避免混用：不要在服务端
listener.ora里写主机名，又在客户端tnsnames.ora里写主机名——两头都不可控
多网卡+高可用场景下别漏掉VIP的ADDRESS块
VIP必须作为单独的ADDRESS加入listener.ora，且前提是该VIP已在系统生效（ip addr show能查到）。否则监听器根本不会监听它。
- VIP和物理IP要分别配置，各占一个
DESCRIPTION块 - 端口建议统一用
1521，避免不同IP走不同端口，增加客户端配置复杂度 - RAC环境还需检查
REMOTE_LISTENER是否指向SCAN监听器；单机双网卡可留空 - 改完配置必须重载：
lsnrctl reload或先stop再start，reload不保证所有变更生效
最容易被忽略的点是：监听器启动日志里不报错，lsnrctl status看起来也正常，但“Listening Endpoints”那一行已经悄悄绑错了IP——它不会警告你绑到了不该绑的地方，只会安静地拒绝所有来自业务网的连接请求。
