ORA-00119是Oracle因LOCAL_LISTENER值无法解析或指向无效监听器而拒绝启动或重载参数的错误；常见于TNS未定义、监听未启、IP/端口错误等场景，需用tnsping和lsnrctl status双重验证。
ORA-00119 是什么，为什么改 LOCAL_LISTENER 会触发它
ora-00119 本质是 oracle 拒绝启动或重载参数，因为 local_listener 的值无法被解析或指向了无效地址。不是语法错，而是 oracle 尝试连接该监听器时失败了——比如 tns 名称没定义、tnsnames.ora 路径不对、监听器根本没起来，或者 ip/端口写错。
常见现象：执行 ALTER SYSTEM SET LOCAL_LISTENER='...' SCOPE=BOTH 后立刻报错；或数据库重启后卡在 MOUNT 状态，alert.log 里反复出现 ORA-00119 + “TNS-12541: TNS:no listener”。
-
LOCAL_LISTENER必须指向一个真实运行的监听器，且该监听器要能接受本地连接（通常用localhost或本机实际 IP，不能用127.0.0.1如果监听器绑定了具体网卡） - 值可以是 TNS 别名（如
'LISTENER_ORCL'），也可以是完整地址描述（如'(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))'），但后者绕过tnsnames.ora查找，更可控 - 如果数据库启用了 RAC 或 Data Guard，
LOCAL_LISTENER必须和REMOTE_LISTENER分开配置，混用会直接导致实例注册失败
怎么验证 LOCAL_LISTENER 值是否真能连上
别只看参数值对不对，关键看 Oracle 实际能不能“握手”。最直接的办法是模拟数据库行为，用 tnsping 和 lsnrctl status 双重确认。
- 先查当前值：
SHOW PARAMETER LOCAL_LISTENER，注意输出中VALUE列是否为空或明显异常（如'(ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=1521))'） - 如果值是 TNS 别名（如
'LISTENER_ORCL'），运行tnsping LISTENER_ORCL—— 必须返回 OK，且显示的 HOST 和 PORT 和监听器实际一致 - 运行
lsnrctl status，确认监听器已启动，且输出里有对应服务名（如orcl）和状态为READY；如果提示Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))却没下文，说明监听器根本没跑 - 特别注意：Oracle 启动时读的是
$ORACLE_HOME/network/admin/tnsnames.ora，不是$TNS_ADMIN下的文件，除非显式设置了环境变量
修改 LOCAL_LISTENER 的安全操作顺序
直接 ALTER SYSTEM 改生产库风险高，尤其当监听器不稳时可能让实例无法注册，影响连接路由。必须按依赖顺序操作。
- 先确保监听器已启动：
lsnrctl start，再lsnrctl status确认 OK - 用静态注册方式临时绕过动态注册问题：在
listener.ora里加SID_LIST_LISTENER段，明确声明实例，避免依赖LOCAL_LISTENER动态注册 - 修改参数前，先用
ALTER SYSTEM SET LOCAL_LISTENER='...' SCOPE=MEMORY测试——只改内存，重启后失效，出问题可快速回退 - 测试无误后，再执行
SCOPE=BOTH写入 spfile；若用 pfile 启动，则必须手动编辑 pfile 并重启 - 改完立刻查
V$INSTANCE和V$LISTENER_NETWORK，确认INSTANCE_NAME已出现在监听器服务列表里
LOCAL_LISTENER 配置里的三个典型坑
很多故障不是参数写错，而是环境细节没对齐。这三个点最容易漏检：
- HOST 值写成
localhost，但/etc/hosts里localhost解析到了::1（IPv6），而监听器只监听 IPv4 —— 解决办法：显式写127.0.0.1或在listener.ora加INBOUND_CONNECT_TIMEOUT_LISTENER=0 - 数据库用 ASM 存储，但
LOCAL_LISTENER指向了非 ASM 实例的监听器端口（比如用了默认 1521，但实际监听器配在 1522）—— 查lsnrctl status输出第一行的端口号，严格匹配 - 在容器或云环境里，HOST 写成容器名或内网 DNS 名，但数据库进程无法解析（
nslookup失败）—— 此时必须用容器网络能通的 IP，或确保/etc/resolv.conf和 DNS 配置生效
复杂点在于：这个参数本身不报语法错，错误全在运行时暴露；而且 alert.log 里日志分散，可能夹在几百行其他信息里。盯住 “TNS-” 开头的错误和监听器状态，比反复改参数更省时间。
