记一次redo损坏导致ora-600[4000]的恢复

据说今天是光棍节,逢年过节,必有大事。快下班的时候,一位朋友碰到了一个大问题,数据库服务器异常断电重启以后,数据库无法启动,报ora-600[4000]错误,尝试了使用隐藏参数,还是无法打开。

ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []

ora-600内部错误的类型可以看到,4000是trasaction undo相关的内部错误。搜索一下可以发现,logzgh同学已经两次碰到过该问题了(第一次第二次)。看来在异常宕机的情况下,这个问题出现的机率还是比较高的。既然是有先例的,恢复起来应该是没有问题的,这个案例和logzgh的第一个案例基本一样,trace文件里显示也是obj$上有异常事务:

ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []
Current SQL statement for this session:
select ctime, mtime, stime from obj$ where obj# = :1

将trace文件往下翻,可以看到出现问题的block的dump信息,在block的itl中果然有一条活动事务存在。用bbed找到对应块,设置offset到61,将itl的flag从20改为80,重新计算block的checksum并apply。然后尝试重新启动数据库,这次ora-600[4000]错误没有了,报的是ora-600[2662]错误,数据库无法open。2662就比较容易了,网上相关的处理案例已经一大堆了,将数据库启动到mount状态,设置10015事件来调整scn即可

alter session set events '10015 trace name adjust_scn level 1';

如果数据库已经处于open状态,则可以使用如下语句来调整SCN:

alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';

再次重新打开库,报ora-600[2256],继续使用10015事件,这次level设置为(ora-600错误的第三个参数+1)*4

alter session set event '10015 trace name adjust_scn level 20';

重启,报ora-600[4097]错误,好了,现在基本上恢复已经接近尾声了,使用下面几个隐藏参数,可以正常将数据库打开了。接下来就是告诉朋友做全库export/重建库/import了。

_allow_resetlogs_corruption=true
_allow_terminal_recovery_corruption=true
_corrupted_rollback_segments=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$, _SYSSMU5$, _SYSSMU6$,
 _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$)

年关将近,事故高发时期,阿弥陀佛,多求个平安吧。话说这个案例还没来得及些写呢,晚上回家的路上又接到说有人truncate了一张表。。。

ora-600内部错误的类型

ora-600是Oracle对于一些内部错误的一个统一的错误号(类似的还有ora-7445)。要判断ora-600错误具体的类型,一般要根据其第一个参数来区分。一个ora-600的例子如下:

ORA-00600: internal error code, arguments: [15700], [3], [0x1DDE1AAB0], [], [], [], [], []

其中15700代表这个错误的具体类型,这是和并行查询相关的一个内部错误,后面的几个参数则是该错误的一些具体参数,不同类型的错误,参数的意义也不尽相同。

ora-600一共有两大类,一类的错误类型以数字标识,另外一类则以字符串标识。数字表示不同的内核层,而字符串则是具体的函数或者模块名。在Metalink的Doc ID: 175982.1 中,oracle列举了这两类错误的详细信息,转录在这里以供需要是查询:
Read more of this post

In Memory Undo与logical standby database

最近碰到了一个bug,导致逻辑备库重建,相当的郁闷。我们一个系统,包含一个主库,一个物理备库,一个逻辑备库。系统不久前刚从9i升级到10.2.0.4。5.30号因为系统维护,将原主库和物理备库做了一次switchover,切换没有什么问题,做了很多次了。这是逻辑备库突然报出了ora-600错误:

ORA-00600: internal error code, arguments: [2730], [331], [1], [13], [293130], [293130], [], []

ok,不用紧张,这个错误没啥问题。因为主库从9i升级到10g之后,为了保留降级的可能,compatible参数还是保留设置为9.2.0.0.0了,而这次切换,顺便把compatible改成了10.2.0.0.0,所以出现主备库的参数不一致了,就会报该错误。修改该参数即可。

但是,问题出来了:

ORA-00600: internal error code, arguments: [krvxbpx20], [1], [293141], [91], [96], [], [], []

Metalink上一查(Doc ID:761661.1),麻烦来了:

The ORA-00600: [KRVXBPX20] indicates that logical standby builder detects IMU (In Memory Undo) in the redo streams. Logical standby does not support IMU and enabling supplemental logging disables the IMU.

In customer’s case, supplemental logging is enabled in the original primary database, but it is not enabled in the original physical standby database. Prior to 11.2 (which has not been released yet at the time of writing), supplemental logging DDLs are not propagated to the physical standby database. Thus they had a situation where the primary has supplemental logging set, but the physical standby did not.

晕死,逻辑备库不支持IMU(In Memory Undo,10g新特性),所以要使用逻辑备库,必须在主库禁用IMU,否则将导致逻辑备库损坏,并只能重建。那为什么原来主库升级到10g之后,逻辑备库是正常的,而执行switchover切换到物理备库,才碰到问题呢?

我们的升级,是在主库执行升级脚,然后备库使用新版本的oracle软件直接应用主库传过来的日志的方式来完成整个系统的升级的。因为逻辑备库是在主库升级到10g后配置的,在执行exec dbms_logstdby.build生产数据字典信息的时候自动配置了supplement logging,而开启supplement logging将自动禁用IMU,所以未切换前逻辑备库是正常的。而问题在于,主库设置supplement logging的语句,并不会在物理备库上自动应用,这样实际上物理备库还是原来9i默认的未开启supplement logging的状态,这样一切换过来,问题就发生了。

如果你也在使用10g的逻辑保备库,要避免该问题,则可以:
1.直接在主库和物理备库都设置_in_memory_undo=false
2.在主库和物理备库检查supplement logging的状态

select supplemental_log_data_min as supp_log, 
supplemental_log_data_pk as supp_pk,
supplemental_log_data_ui as supp_ui 
from v$database;

SUPP_LOG   SUPP_PK    SUPP_UI
---------- ---------- ----------
NO         NO         NO

只要上述结果中,任意一列值为NO,则需要执行(物理备库可以mount状态或者open readonly状态执行):

alter database add supplemental log data (primary key, unique index) columns;

无觅相关文章插件,快速提升流量