SCAN监听器显示“not running”但srvctl status scan显示running，说明SCAN VIP资源已上线，但LISTENER_SCAN1/2/3进程未启动，导致客户端报ORA-12541；常见原因是进程僵死或被误杀后CRS未自动拉起，需清理残余进程后逐个启动并验证监听端口。
SCAN监听器显示“not running”但srvctl status scan显示running
这说明scan vip资源已上线，但对应的scan监听器进程（listener_scan1/2/3）实际未启动。grid infrastructure认为“scan存在”，但底层监听器没绑端口，客户端必然报ora-12541。
常见诱因是监听器进程僵死或被误杀后未自动拉起，而CRS只检查资源注册状态，不校验进程真实存活。此时srvctl status scan_listener -i 1会明确返回is not running，但ps -ef | grep tnslsnr可能还残留旧进程残留。
- 先清理残余进程：
ps -ef | grep LISTENER_SCAN1 | grep -v grep | awk '{print $2}' | xargs kill -9 - 再手动启动指定实例：
srvctl start scan_listener -i 1（把1换成2或3，逐个启动） - 验证是否真在监听：
lsnrctl status LISTENER_SCAN1，必须看到Listening Endpoints Summary段落里包含(PROTOCOL=tcp)(HOST=...)(PORT=1521)
srvctl status scan_listener报PRCR-1001: Resource does not exist
这不是监听器挂了，而是SCAN监听器资源根本没注册进CRS——通常发生在手动执行过srvctl remove scan_listener，或Grid安装异常、补丁失败后资源元数据损坏。
不能直接srvctl add scan_listener，因为SCAN VIP资源依赖顺序：必须先确保srvctl status scan返回正常，且crsctl stat res -t | grep scan能看到ora.scan1.vip等资源处于ONLINE状态。
- 确认SCAN VIP在线：
srvctl config scan输出应含3个IP；若无，先srvctl start scan - 重建监听器资源：
srvctl add scan_listener（无需参数，默认按SCAN数量创建LISTENER_SCAN1/2/3） - 启动并验证：
srvctl start scan_listener→srvctl status scan_listener
lsnrctl status LISTENER_SCAN1卡在“Connecting to…”
这个现象本质是IPC连接失败，不是网络问题。监听器进程虽注册，但IPC key（如LISTENER_SCAN1）对应的共享内存段或信号量损坏，lsnrctl无法通过本地socket连上它。
典型伴随日志在$GRID_HOME/log/中出现Failed to bind address或TNS-12560，说明监听器尝试绑定SCAN VIP时被内核拒绝——大概率是IP冲突或HAIP通信异常。
- 立即检查IP唯一性：
arping -D -I，若返回Received reply，立刻停用冲突设备 - 查HAIP是否干扰：
oifcfg getif确认HAIP网段（如169.254.x.x）未与SCAN子网重叠 - 强制重启整个SCAN栈：
srvctl stop scan; srvctl stop scan_listener; srvctl start scan; srvctl start scan_listener
重启Grid Infrastructure前必须确认的三件事
盲目crsctl stop crs && crsctl start crs风险极高：SCAN VIP漂移、OCR丢失、节点驱逐都可能发生。真正需要的是精准组件重启。
复杂点在于SCAN监听器强依赖于ora.dns（如果用了GNS）、ora.scan1.vip和ora.LISTENER_SCAN1.lsnr三个资源的启动顺序与健康状态。任何一个环节卡住，整个SCAN链就断。
- 先看DNS是否拖慢CRS：
cat /etc/resolv.conf，禁用所有不可达的nameserver（lsnrctl status卡顿常源于此） - 确认VIP没被标记DUP：
ip addr show里SCAN IP不能带duplicate字样 - 别跳过日志验证：
tail -20 $GRID_HOME/log/里是否有/client/tnscmd.log TNS-12545或TNS-12560，它们比“not running”更早暴露根因
