OSB 12c数据库轮询器突发停止轮询记录求助

我之前也碰到过类似的OSB数据库轮询异常问题，结合你描述的场景——4个受管节点里2个内存耗尽，另外2个看似正常但轮询全停了，咱们一步步拆解可能的原因和解决方向：

一、核心原因：集群轮询的锁协同机制出问题了 #

OSB的数据库轮询器在集群环境下是靠数据库锁来实现节点间协同的：同一时间只会有一个节点执行轮询任务，避免多个节点重复处理同一份数据。如果那两个内存耗尽的节点挂掉时，没有正确释放手里的轮询锁，剩下的正常节点就会一直等着拿锁，自然就停了轮询——这就是为啥你看到“一半节点爆内存，另一半也躺平”的关键。

二、具体排查步骤 #

1. 先查数据库里的残留锁 #

OSB默认用WLS_REMOTE_COORDINATION表存轮询锁（如果没自定义锁表的话），跑个SQL看看有没有僵死的锁：

SELECT * FROM WLS_REMOTE_COORDINATION WHERE LOCK_NAME LIKE '%SpinWinDBUpdate%';

要是看到锁记录的LOCK_OWNER是那两个爆内存的节点名，而且LOCK_EXPIRATION时间早就过了，那基本实锤是锁残留搞的鬼。

2. 检查正常节点的轮询器状态 #

登录OSB控制台，找到正常节点的JCA适配器模块，定位到你的SpinWinDBUpdate.SpinnwinPoll轮询器：

• 查看有没有“无法获取分布式锁”这类报错日志
• 确认PollingInterval（轮询间隔）有没有被意外改大或者设为0
• 顺便检查正常节点的JVM内存参数（-Xmx/-Xms）是不是足够，会不会因为隐性内存压力影响锁获取逻辑

3. 搞清楚那两个节点为啥爆内存 #

拉取这两个节点崩溃前的GC日志和线程dump：

• 是不是轮询查询没加行数限制，一次性拉了几万条数据堆在内存里导致溢出？
• 检查JCA属性里的MaxTransactionSize（每次事务处理记录数）是不是设得太大，加上业务处理慢，内存越积越多？

三、临时恢复+长期优化方案 #

临时恢复：手动清锁重启 #

如果确认是锁残留，先手动删除无效的锁记录：

DELETE FROM WLS_REMOTE_COORDINATION WHERE LOCK_NAME LIKE '%SpinWinDBUpdate%' AND LOCK_OWNER IN ('节点1名称', '节点2名称');

然后重启正常节点上的轮询适配器，或者直接重启这两个节点，轮询应该就能恢复了。

长期优化：从根源避免问题 #

1. 给轮询锁加超时机制：
   在JCA属性里添加锁超时配置，比如：

   <property name="LockTimeout" value="30000"/> <!-- 30秒超时，单位毫秒 -->
   <property name="LockType" value="oracle"/> <!-- 如果用Oracle数据库，指定锁类型提升可靠性 -->
   

   这样就算节点挂了，锁到时间会自动释放，不会卡住其他节点。

2. 控制轮询数据量，避免内存爆仓：

   • 给你的SpinWinDBUpdateSelect查询加行数限制，比如Oracle用FETCH FIRST 50 ROWS ONLY，MySQL用LIMIT 50，每次只拉少量数据处理
   • 调整MaxTransactionSize属性，确保每次事务处理的记录数在节点内存承受范围内

3. 加监控防患于未然：

   • 在OSB控制台给轮询器配置告警：如果连续几个轮询周期都没处理新记录，就触发告警
   • 给节点加内存监控，当内存使用率超过80%时自动重启节点，避免节点挂死导致锁残留

内容的提问来源于stack exchange，提问作者alok