记一次ora-00600 [2256] [4193]的处理

今天是周一，难得在单位，开会过程中，出来喝口茶，问题就出来了。接到客户一电话，其数据库环境为Oracle 9.2.0.5的rac，运行在aix平台上。由于未知原因，数据库宕掉。重启之后，首先发现的是3个控制文件不一致，客户就选择其中一个控制文件进行mount，mount成功之后，在open数据库时，提示需要介质恢复。客户又用以下命令recover database using backup controlfile;进行自行恢复。结果恢复的时候提示找不到归档日志。这时客户的电话找到了我，接到电话了解情况之后，为简单起见首先提示客户把database的online redolog挨个输入进行recover，当recover至最后一个日志时，出现ORA-03113: end-of-file on communication channel.见到此错误，就意识到事情不妙，赶紧叫客户打开alert日志查看，出现了redolog corruption，也就意味着数据库宕机时出现redolog损坏！意识到远程电话沟通，难以解决此类问题。恰巧，有同事在客户现场附近，赶紧叫同事去客户现场，自己再做远程支持。
如果出现current online redolog corruption，最常规的解决办法就是置隐含参数_ALLOW_RESETLOGS_CORRUPTION，将隐含参数设置之后，再用recover database using backup controlfile until cancel进行不完全恢复，最后用alter database open resetlogs打开。但是在打开数据库过程中，出现了2256错误，ora-600  2256 6 1073741824 2811 2669208191 [] [] [] ，该错误以为着数据库需要的scn和current scn处于不一致状态。利用ora-00600 [2262]类似的算法：

引用

ORA-600 [2662] [a] [b] [c] [d] [e]
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [c] dependent SCN WRAP
(注：为了存储更大的SCN值，当SCN BASE到足够大并开始重置的时候，SCN WRAP将加1)
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from
也就是Arg[d]的值是从哪个block中找到的，通常是一个data block address。
通过这几个参数根据一定的规则可以计算出我们需要的level。计算规则如下：
Arg [c]*4得出一个数值，假设为V_Wrap
如果Arg [d]=0，则V_Wrap值为需要的level
Arg [d] < 1073741824，V_Wrap+1为需要的level
Arg [d] < 2147483648，V_Wrap+2为需要的level
Arg [d] < 3221225472，V_Wrap+3为需要的level

将level设置为11247=2811*4+3，使用如下事件进行scn递增，（注意数据库处于mount状态）
alter session set events '10015 trace name adjust_scn level 11247’，再次尝试进行open，alert日志继续报ora-600 4193 42665 42729 【】 【】 【】 【】 【】，其后台跟踪文件显示

引用

ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [4193], [42665], [42729], [], [], [], [], []
Current SQL statement for this session:
update lob$ set retention = :1 where retention >= 0

根据mtalink doc 39282.1解释，出现4193主要是因为undo和redo的seq号出现不匹配。

引用

PURPOSE:           
  This article discusses the internal error "ORA-600 [4193]", what
  it means and possible actions. The information here is only applicable
  to the versions listed and is provided only for guidance.

ERROR:             
  ORA-600 [4193] [a] [b]

VERSIONS:          
  versions 6.0 to 10.1

DESCRIPTION:       

  A mismatch has been detected between Redo records and Rollback (Undo)
  records.

  We are validating the Undo block sequence number in the undo block against
  the Redo block sequence number relating to the change being applied.

  This error is reported when this validation fails.

ARGUMENTS:
  Arg [a] Undo record seq number
  Arg [b] Redo record seq number

一般来讲4193在数据库已经处于open状态时，处理比较简单。详见metalink doc 281429.1，但目前是mount状态，并不能用metalink介绍的方法进行解决。事情到这里似乎没有眉目了，再次尝试用隐含参数_CORRUPTED_ROLLBACK_SEGMENTS进行处理，但前提是需要知道损坏的undo segment，进一步查看相关跟踪文件并没有相关undo segment信息，直觉告诉我处理4193，4194并不需要设置_CORRUPTED_ROLLBACK_SEGMENTS参数，考虑到目前undo为auto，尝试将undo_management设置为manual，再次尝试将数据open，可喜的是open成功！接下来就是一些收尾工作，具体不表。事后查询Oracle metalink文档 doc 452662.1比较详细的说明了怎么解决了4193错误，其中一种方法就是将undo_management设置为manual。