srvctl status scan_listener显示unknown表示crs资源注册正常但oraagent_grid无法确认监听进程存活，主因是ipc卡死或scan vip未真实绑定至网卡，需查oraagent_grid.log、验证vip唯一性、检查listener.ora绑定及remote_listener配置。
srvctl status scan_listener 显示 UNKNOWN 是什么信号
这表示 CRS 资源注册正常，但 oraagent_grid 无法确认监听进程真实存活——不是“没启动”，而是 IPC 通信卡死或共享内存异常。查 $GRID_HOME/log/<node>/agent/oraagent_grid.log</node>，重点搜 Failed to bind address 或 TNS-12560。若日志里反复出现绑定失败，说明 SCAN VIP 没真正落到网卡上，漂移流程在 OS 层就中断了。
SCAN VIP 没出现在网卡上，但 crsctl stat res -t 显示 ONLINE
这是最典型的“假在线”：资源状态是 OK 的，但 IP 根本没绑定到物理接口。用 ip addr show（别信 ifconfig）逐节点检查，确认 SCAN VIP 是否作为 secondary 地址出现在 public 网卡（如 ens33）上；若缺失，或被标记为 DUP，说明底层网络层拒绝接纳该地址。
- 用
arping -D -I ens33 <scan_vip></scan_vip>验证地址唯一性，返回 “Received reply” 就是冲突 - 检查交换机 MAC 表，确认 SCAN VIP 对应的 MAC 只在一个端口出现
- 云环境（如阿里云/VMware）可能禁止非主网卡绑定辅助 IP，需查厂商文档是否支持“多 IP 绑定”
SCAN 监听器没注册到漂移后的 VIP 地址
SCAN VIP 漂移成功 ≠ LISTENER_SCAN1 就能响应请求。监听器必须明确绑定到该 VIP，否则 lsnrctl status LISTENER_SCAN1 的 Listening Endpoints Summary 里会缺 HOST= 值，只显示 (PORT=1521)。
- 检查
/u01/app/grid/network/admin/listener.ora：漂移后该文件是否已自动更新？19c RAC 要求它包含(ADDRESS=(PROTOCOL=TCP)(HOST=<scan_vip>)(PORT=1521))</scan_vip> - 若文件没变，手动补上并执行
srvctl stop scan_listener -i 1 && srvctl start scan_listener -i 1 - 注意：
lsnrctl start LISTENER_SCAN1无效，必须走srvctl，否则不进 CRS 生命周期管理
remote_listener 指向错误导致实例不向 SCAN 注册服务
即使 SCAN 监听器跑起来了，客户端连上去仍报 ORA-12514，大概率是数据库实例压根没把服务名推过去。关键看每个实例的 remote_listener 参数：
- 必须是
<scan_name>:1521</scan_name>（例如rac-scan.example.com:1521），不能写成 IP、不能漏端口、不能指向节点 VIP - 同时确认
local_listener已设为本节点 VIP + 端口，否则实例连本地监听都注册不了，更不会转发到 SCAN - 执行
alter system register强制触发一次服务注册，10 秒后查lsnrctl status LISTENER_SCAN1的Services Summary，看对应 service name 下是否有 instance
SCAN VIP 漂移失败往往不是单点问题，而是 VIP 绑定、监听器配置、实例注册、DNS 解析四者中任意一环断裂。最容易被跳过的是 arping 冲突检测和 listener.ora 文件是否真被 Grid 自动更新——这两步不做，其他操作基本白忙。
