跳转到主内容
websoft网络软件专家 - 深耕网络技术,打造实用软件!

如何修复Oracle 19c RAC中SCAN监听器状态异常_重启Grid Infrastructure组件

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连上它。 oracle知识库 oracle知识库下载 下载 典型伴随日志在
$GRID_HOME/log//agent/oraagent_grid.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”更早暴露根因

相关文章