Oracle SR无法解释的回滚段无法OFFLINE问题

背景

前期在一套4节点RHEL 6.5 x64 + 11.2.0.4的RAC上发现第2个节点在报ORA-00600 [ktugnb:clschk_kcbnew_14],具体诊断细节可以参考:http://www.oratea.com/2017/02/22/ora-00600-ktugnbclschk_kcbnew_14诊断/,在文章最后提到:”从每次ORA-00600 [ktugnb:clschk_kcbnew_14]涉及的数据块来看,基本都是UNDO数据块,新建UNDO表空间切换,再看情况”。但这个UNDO切换过程不是很顺利,其中有一些问题Oracle SR也无法解释。

开SR之前的诊断

节点2切换UNDO表空间的日志如下:

其中[46330],指的就是SMON进程

通过以下SQL检查4个节点,在UNDOTBS2表空间上均无活跃事务

通过以下SQL查询,在4个节点上均无挂起的分布式事务

通过以下SQL查询UNDOTBS2表空间里无法OFFLINE的回滚段

通过以下SQL查询回滚段头上是否还有死事务等信息

由于篇幅问题,没有截完整,但所有的KTUXESTA为INACTIVE,并且KTUXECFL为NONE状态。可能怀疑查询的x$ktuxe有问题,使用转储回滚段头进行确认,命令如下:

从trc文件中看,所有回滚段头中,无死事务也无活跃事务。以1个回滚段为例,其它基本一致,state全部为9。

检查v$rollstat视图,发现在v$rollstat上确是有活跃事务

官方文档对v$rollstat.XACTS字段的解释是:Number of active transactions。这就有点困惑了,回滚段头上没有活跃事务(或死事务),但是v$rollstat却显示有。观察v$rollstat视图的定义(可以通过查询v$fixed_view_definition得到v$rollstat的定义),该视图是基于x$kturd,不是x$ktuxe,猜测可能x$视图信息存在问题导致SMON无法OFFLINE回滚段。x$视图内的数据很多是基于Oracle运行内存里的数据,所以猜测需要重启节点2才能解决问题。

把以上诊断的信息与客户解释,并且为了验证以上诊断,开了SR。

开SR过程

开SR是个比较艰苦的过程,需要将问题描述,前期操作的步骤,相关trc等等上传。由于问题未影响到业务,开的是2级SR。

星期一开SR,期间与SR反复交流,基本是把前面诊断的内容递交给SR,期间SR多要求了一次,对drop旧的undo回滚段进行10046跟踪。

跟踪到的错误是ORA-30013,又是陷入死胡同。

SR对这个问题的理解如下:

SR对SMON OFFLINE回滚段的说明。

在周四,SR给出了如下解决方案:


问题解决

周四晚上,对节点2实例进行重启后,UNDOTBS2就可以正常drop了。当然事情是解决了,但实际上这个问题没有得到一个合理的解释。从这里也可以看出,Oracle是个非常复杂的系统,里面有一些问题,原厂的售后也不一定能够解释清楚。在诊断了非常多的信息后,没有获得最终结果,重启也许就可以解决问题。(声明重启数据库需要慎重)

未经允许不得转载:Oracle一体机用户组 » Oracle SR无法解释的回滚段无法OFFLINE问题

相关推荐