love wife love life —Roger的Oracle/MySQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

mapid溢出导致Oracle RAC 节点重启

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL数据恢复博客

本文链接地址: mapid溢出导致Oracle RAC 节点重启

某客户的CRM数据库在2015年9月17号11:38分左出现其中一个节点宕机的情况。其中节点1报错信息如下:

从节点1数据库db alert log日志来看,在11:38:10出现ASM故障,最后在11:38:26时间,节点1的ASM实例被Oracle ASM实例的ASMB进程强行终止,因此导致数据库实例也crash掉。如下是相关日志信息:

而此时在节点2的数据库alert log日志中,没有发现其他信息,仅仅只有节点1实例被重启的信息。因此,不难看出,节点ASM实例被强行终止,是此次问题的关键所在。我们进一步分析节点1 ASM实例的日志,发现如下信息:

我们可以看到,在11:38:06时间点,ASM实例抛出ORA-00600 [kffilCreate01] 错误后,接着将实例终止,同时将日志信息写入到+ASM1_ora_8716976_i179751.trc文件中,该trace 文件的内容如下:

我们可以看出,Oracle 在调用kffcicreate函数时出现了异常,进而导致asm实例被强行终止。经过分析我们发现该问题跟Oracle Bug 16357438  (ORA-600 [KFFILCREATE01] IN ASM TRIGGERS DB CRASH WHEN MAPID REACHES MAX VALUE )比较符合。如下是Oracle metalink文档针对该bug的call stack函数描述:

对于Oracle数据库bug的判断,通常的做法是比较报错日志文件中的call stack函数调用是否与Oracle bug的call stack函数描述一致,一般来讲,相似度超多90%,则意味是符合bug的可能性就极大。基于这样的分析,我对比发现call stack与Oracle bug 的call stack描述完全一致。

根据Oracle 文档关于该bug的描述,大致意思是指asm实例的mapid溢出,导出asm实例无法正常运作,进而被asmb进程强行终止;当然,强行终止的目的是为了保持集群节点数据的完整性,如下是从trace文件中提取的mapid信息:

我们可以看到,mapid已经达到最大值4294967296,这是Oracle数据库中数据对象的上限,同时我们从trace文件中的KST trace信息中也能看mapid溢出的类似信息:

我们可以看出,mapid已经出现了负数,这边表明mapid出现了溢出。

基于前面的种种分析,我们认为此次故障完全符合Oracle bug 16357438的描述细节,因此建议客户在下次维护时间窗口中安装相关Patch。

Leave a Reply

You must be logged in to post a comment.