UNKNOWN表示CRS无法确认SCAN监听器真实运行状态，源于进程僵死、IPC通信失败或共享内存损坏，需检查oraagent_grid.log及SCAN VIP绑定情况。
srvctl status scan_listener 显示 UNKNOWN 是什么情况
这通常不是监听器进程挂了，而是 crs 无法确认其真实运行状态——srvctl status scan_listener 返回 unknown，说明资源注册信息存在，但 crs agent 没拿到进程存活反馈或 ipc 通信失败。常见于监听器进程僵死、ipc 共享内存损坏、或 oraagent_grid.log 中出现 failed to bind address 或 tns-12560。
lsnrctl status LISTENER_SCAN1 卡在 “Connecting to…” 怎么办
这不是网络不通，而是本地 IPC 连接失败。监听器进程可能已启动但共享内存段/信号量损坏，lsnrctl 无法通过 socket 连上它。
- 先检查
$GRID_HOME/log/<node>/agent/oraagent_grid.log</node>，搜索Failed to bind address或TNS-12560 - 确认 SCAN VIP 是否真在本节点：用
srvctl config scan查 IP，再用ip addr show看哪个节点当前持有该 VIP - 若确认 VIP 在本节点，且
ps -ef | grep LISTENER_SCAN1有残留进程，用kill -9 <pid></pid>清掉，再srvctl start scan_listener -i 1 - 启动后立刻验证端口绑定：
lsnrctl status LISTENER_SCAN1必须看到(PROTOCOL=tcp)(HOST=)(PORT=1521)出现在Listening Endpoints Summary段
crsctl stat res -t 里 SCAN 相关资源显示 UNKNOWN
这和 srvctl status scan_listener 的 UNKNOWN 不同，是 CRS 资源层彻底失联，往往因 OCR 损坏、GNS 宕机、或 SCAN VIP 资源未注册导致。
- 先跑
srvctl status scan：如果报错或返回不一致（如一节点说 ONLINE，另一节点说 STOPPED），说明 DNS/GNS 解析异常或 SCAN VIP 漂移失败 - 查 GNS 状态：
crsctl stat res -t | grep gns，若非 ONLINE，srvctl start gns再试 - 若
srvctl config scan输出为空或少于 3 个 IP，先srvctl start scan；成功后再srvctl add scan_listener（不带参数）重建监听器资源 - 切勿跳过
srvctl status scan直接加监听器——SCAN VIP 必须先 ONLINE，否则srvctl add scan_listener会静默失败
为什么改完 hosts 或重启监听后还是 UNKNOWN
Windows 下 C:\Windows\System32\drivers\etc\hosts 里错误的 SCAN 名映射会导致监听器启动时绑定失败，现象就是 lsnrctl status 卡住、srvctl 报 UNKNOWN，且换端口也无效。
- 检查 hosts 文件中是否把 SCAN 名硬解析到错误 IP 或 localhost —— RAC 节点间通信绕过 hosts，但监听器启动阶段仍会读取
- Linux 下注意
/etc/hosts中127.0.0.1对应的 hostname 是否与listener.ora里的HOST值完全一致（大小写敏感） - 哪怕只有一行
192.168.10.101 rac-scan.example.com写错，监听器也会在 bind 阶段失败，日志里只报 TNS-12545，不提示 hosts 问题
UNKNOWN 状态背后几乎总是 IPC 层或资源注册层的问题，而不是配置语法错误。盯住 oraagent_grid.log 和 ip addr show 输出，比反复修改 listener.ora 有效得多。
