ORA-00119 错误由 LOCAL_LISTENER 参数配置不当导致，与 listener_networks 无关；该参数值必须能被实际解析并成功建立 TCP 连接，否则启动失败。
ora-00119 错误和 listener_networks 无关，别被误导 —— 这个参数根本不会触发该错误
如果你在 Oracle 安装或启动过程中看到 ORA-00119，并怀疑是 listener_networks 配置导致的，那大概率走偏了。这个参数自 12c 引入，用于 RAC 或多网卡环境下的监听器网络绑定控制，而 ORA-00119 的报错源头几乎 100% 是 LOCAL_LISTENER 参数值“看着合法、实则连不上”。
ORA-00119 真正盯的是 LOCAL_LISTENER，不是 listener_networks
Oracle 启动时会尝试用 LOCAL_LISTENER 的值去连接本地监听器——不是检查语法，而是真建 TCP 连接。失败就报 ORA-00119（常伴 ORA-00132）。listener_networks 不参与这个校验流程，它只影响监听器自身启动后往哪些网卡 bind，不决定数据库能否注册。
常见混淆点：
- 安装界面提示 ORA-00119，同时日志里出现
listener_networks相关行 → 实际是安装程序读取了旧配置或模板文件，但真正出错的仍是LOCAL_LISTENER - 手动在
init.ora或 SPFILE 里加了listener_networks→ 该参数若写错，Oracle 通常直接忽略或报 LRM-00109（参数未识别），而非 ORA-00119 - 查
SHOW PARAMETER listener_networks发现为空或异常 → 这本身不导致启动失败，不用优先排查
LOCAL_LISTENER 值必须能被 Oracle 实际解析并连通
重点不是“有没有”，而是“能不能通”。验证步骤要闭环：
- 运行
SHOW PARAMETER LOCAL_LISTENER，看 VALUE 列输出；如果是空、'LISTENER_ORCL'或'(ADDRESS=(PROTOCOL=TCP)(HOST=...)(PORT=...))'，都需进一步验证 - 若值为 TNS 别名（如
'LISTENER_ORCL'）：执行tnsping LISTENER_ORCL，必须返回 OK，且显示的 HOST 和 PORT 与监听器实际一致 - 若值为地址字符串：确认 HOST 填的是监听器实际绑定的 IP（比如
lsnrctl status输出中 Listening Endpoints Summary 里的地址），避免填127.0.0.1而监听器绑在192.168.1.100 - 无论哪种形式，先确保
lsnrctl start已执行，且lsnrctl status显示状态为 READY
绕过 tnsnames.ora 解析最稳妥：硬编码地址
生产环境强烈推荐把 LOCAL_LISTENER 设为完整地址描述，跳过 TNS 名称解析环节。这能砍掉一个关键故障点：
- 正确格式：
'(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))'（注意不是ADDRESS_LIST，那是 10g 旧写法） - HOST 推荐用
localhost（非127.0.0.1），除非监听器明确绑定了 loopback 外的网卡 - 修改必须通过 PFILE 中转：先
CREATE PFILE FROM SPFILE，编辑 init.ora 文件中的 *.local_listener=行，再CREATE SPFILE FROM PFILE - 切勿在已挂起的实例上直接
ALTER SYSTEM SET LOCAL_LISTENER=...，可能卡死在 MOUNT 状态
最容易被忽略的一点：Oracle 启动时默认只读 $ORACLE_HOME/network/admin/tnsnames.ora，完全不认 $TNS_ADMIN 下的文件——除非你显式设置了环境变量。很多“tnsnames.ora 已改却无效”的问题，根源就在这儿。
