我明明 immediate 关库的,怎么就打不开了?!

五一放假期间,某客户的数据库出现故障,据说对方找了一些工程师折腾了一天,都无法将数据库open,其中参考了网络上的很多文章,也使用了一系列隐含参数,均无法将数据库打开。这里我简单的与大家分享一下这个case。

首先我介绍一下整个case的背景,客户在4月30号凌晨通过shutdown immediate停库维护后,启动数据库无法报错,此时发现数据库无法open,期间尝试了各种数据库手段,均失败告终。

我们先来看看相关日志,如下是数据库停库的日志:

我们可以看出,这个数据库确实是以shutdown immediate的方式停止的。客户第一次尝试启动时,发现报错ORA-00600 [2663],如下:

这是一个非常常见的错误,这个错误通常是是跟数据块有关系。我们知道,根据经验,一般来讲,如果current scn (这里是scn base)与dependent scn(scn base)非常接近(且scn wrap都一致或者为0)的情况下,说明scn的差异非常小,通过多次重启数据库的手段,基本上可以绕过这个错误。

果然,通过看客户提供的alert log发现多次重启后,alert log的报错日志变了ORA-00600 [4194]错误,如下:

这是一个看似非常简单的错误,大致意思是说Oracle 在进行事务恢复时发现redo和undo的信息有所出入,因此抛出这个错误。

这里我贴出Oracle MOS的标准解释供大家参考:Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter (文档 ID 281429.1)

上述文档中提到,这个错误其实就是指恢复时发现undo block对应的record 编号与redo block 对应的undo record 编号不一致。通常情况下来讲,都是由于回滚段损坏导致的问题。 这里我们先不去进行alert log的详细分析展开了,以自己的实际操作过程来进行展开分析说明。如下是我的简单恢复过程。

首先我尝试进行正常恢复,并打开数据库:

我们可以看到操作报错,并没有打开数据库。此时查看数据库alert 告警日志,发现正是前面提到的ORA-00600 [4194]错误:

这个ora-00600 错误与前面提到的完全一致。根据我们常规处理这个错误的套路,基本上就是使用undo_management=’manual’ 来尝试绕过,经过测试发现不好使。

进一步查看对应的trace 文件,发现oracle提示说某个块存在异常:

上述的错误其实也很容易解释,简单的讲就是redo应用时出现了异常,而且oracle 明确提升file 1 block 131 这个undo block有问题. 上述的内容是redo block的dump;那么我们来看看对应的undo block 中的前镜像是什么:

我们可以看到完全不匹配,同时我们通过脚本将上述内容进行转换,可以发现是其实是回滚段名称:

其次结合我们前面解释ora-00600 [4194]错误来看,这里undo block 对应的record number是0×20,而redo block中记录的record number是0×2. 这确实是不匹配的。

那么怎么解决这个问题呢? 能不能通过屏蔽回滚段的方式来解决呢?

我尝试在open之前设置10046 trace,来观察了一下得到了如下结果:

可以看到oracle在执行update undo$时报错,其中更新的是_SYSSMU1_3724004606$ 这个回滚段。而且我们也可以看到,wait# 中记录的正好是前面报错的file# 1 block 131. 那么通过_corrupted_rollback_segments=(_SYSSMU1_3724004606$)

这种方式是否可以解决这个问题呢?

很遗憾,这里我测试也不行。甚至通过bbed 修改undo$的kdbr记录,将_SYSSMU1 的状态修改为offline,也无法绕过这个ora-00600 4194错误。简直堪称最顽固的ORA-00600 [4194]。

我又检查了一下前面的trace文件,发现所针对这个回滚段头的dump记录,可以确认其中并没有什么活动事务。然后再仔细看我们所遇到的这个ora-00600 [4194]错误,我感觉有点怪异。为什么说怪异呢?

如果说根据Oracle mos的解释文档来看,这里是是没有[a],[b] 值的,因为均为0.

最后我们想到通过修改system 回滚段头来绕过这个错误,如下是操作过程:

注意,这里我们仅仅需要修改ktuxcnfb和ktuxcfbp[1] 即可。其中将ktuxcnfb修改为0,ktuxcfbp[1]中的uba修改为0.

然后再尝试打开数据库,发现顺利打开了数据库,如下:

接着检查了数据库alert log,也没有发现任何的ora-错误。看到最后,或许大家会觉得很奇怪,为什么会出现这样的故障呢 ? 这里我也跟大家一样困惑。

这库是通过shutdown immediate方式正常停止的。我们都知道,这种方式停库之后,整个Oracle数据库的文件都是处于一致的状态,重新启动数据库实例后按理说是不需要再进行实例恢复的。

那么为什么这里又出现了这种情况呢?

针对这个问题,我认为有2种可能性:

1、shutdown immediate之后,数据库写入到操作系统cache,还未完全写入到disk上时,此时数据库主机被强行重启;由于操作系统cache丢失,导致数据库出现了不一致的情况(本文环境是Linux文件系统)。 2、其他程序或软件破坏了Oracle数据库文件的一致性(实际上,经过了解该环境部署了Rose HA软件;而且客户在操作时,据说并没有停止rose ha软件)。

由于客户操作的时间点是凌晨2点,几乎是0业务场景,因此我认为第一种可能性几乎为0;第2种可能性更大。

当然由于我们不了解Rose HA软件的工作机制,这里不便评论。只能说这是一个非常奇怪的case了。值得欣慰的是,通过我们的努力,很快就帮助客户恢复了系统访问,并且无数据丢失。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-06-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

容灾半自动化的实现思路(一)(r7笔记第91天)

最近也在对容灾的切换做一些改进。 目前碰到的问题有 1.灾难切换后备库的内核参数设置不到位,导致切换后又潜在的性能问题 2.灾难切换后在同机房,网络相关的情况下...

2515

Jelastic专用存储容器指南

在我们以前的文章中,我们已经开始揭示数据存储容器主要的可能性,这有助于改善你的项目文件系统的结构。我们还介绍了Jelastic中存储的5种类型的数据,现在我们将...

1706
来自专栏杨建荣的学习笔记

Oracle数据库端口突然无法访问的分析(r12笔记第46天)

最近碰到一个蛮有启发意义的案例。是数据库监听相关的,但是实际的原因却又出乎意料。 问题的反馈受益于开发同学,一个开发同学在lync上找到我,说现在一个线上业...

3436
来自专栏逸鹏说道

SQL:指定名称查不到数据的衍伸~空格 换行符 回车符的批量处理

异常处理汇总-数据库系列 http://www.cnblogs.com/dunitian/p/4522990.html 先看看啥情况 ? 复制查询到的数据,粘...

33210
来自专栏腾讯移动品质中心TMQ的专栏

Windows开机过程和测试方法探索

用户会经常抱怨自从安装自己的应用后,电脑开机变慢,到底是系统的原因还是应用的原因,为了了解这里的问题,探秘了下windows的开机过程和测试方法。 一、开机过...

18510
来自专栏北京马哥教育

Linux终端下 dstat 监控工具

关于dstat dstat 是一个可以取代vmstat,iostat,netstat和ifstat这些命令的多功能产品。dstat克服了这些命令的局限并增加了...

2656
来自专栏杨建荣的学习笔记

使用pt工具检测MySQL主从延迟(r12笔记第7天)

今天翻看了下《高性能MySQL》,真是让人拍手称绝,里面的很多实战思路非常不错,各种问题分析如数家珍,如果是有一定基础的同学,看起来会非常不错。 当然里...

3316
来自专栏程序人生

数据的存储

这是我今年一月份在 team 内部的一次分享。介绍了主流的数据存储方案,包括:内存,文件,数据库和消息队列,以及数据序列化/反序列化的方法。很多时候,工具就在那...

3406
来自专栏WindCoder

在Python中用Celery安排管理后台工作流

还好这次没来ios的,刚接触了下dubbo的分布实现,没想到就被推了一篇python的分布实现技术,分享给大家吧,顺便自己也了解下。原文如下:

331
来自专栏云计算D1net

x86与x64的区别,云服务器如何选择操作系统?

云服务器中windows系列系统通常都有x86与x64两个版本。x86与x64有什么区别?云服务器用户该如何选择操作系统? ? x86与x64的区别: 1、x...

36310

扫描关注云+社区