ORA-600 [2662] ORACLE 11.2.0.4

今天有个项目跟我说他们有个数据库拉不起来了。该库非归档模式，没有任何备份，断电重启之后报sysaux表空间跟某个业务表空间有若干个坏块。版本是11.2.0.4, linux X86-64
没备份，也不用考虑块恢复blockrecover了。
好在数据库不大，将该库先冷拷贝一下
尝试用_allow_open_resetlogs

startup nomount;
alter system set "_allow_resetlogs_corruption"=true scope=spfile;
shutdown immediate;
startup mount;
recover database until cancel
cancel
alter database open resetlogs;
Errors in file /home/db/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_8932_NEW1555.trc  (incident=88163):
ORA-00600: internal error code, arguments: [2662], [0], [17074851], [0], [17144854], [12583040], [], [], [], [], [], []
Incident details in: /home/db/oracle/diag/rdbms/orcl/orcl/incident/incdir_88163/orcl_ora_8932_i88163.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /home/db/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_8932_NEW1555.trc:
ORA-00600: internal error code, arguments: [2662], [0], [17074851], [0], [17144854], [12583040], [], [], [], [], [], []
Errors in file /home/db/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_8932_NEW1555.trc:
ORA-00600: internal error code, arguments: [2662], [0], [17074851], [0], [17144854], [12583040], [], [], [], [], [], []

这个是比较常见的2662错误，eagle大师曾经讲过，通过设events可以跳多少scn号过去
总结一下，通常有如下3种方法
1.alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';
--需要数据库OPEN

2.通过10015事件
alter session set events '10015 trace name adjust_scn level x';
--mount状态

3.设_mini_giga_scn隐藏参数

关于这些的值该设多少，偶总结了一下如下：
SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 12506717382696 (在 12/30/2011 19:22:18 生成) 对于线程 1是必需的
ORA-00289: 建议:/archive/DMA/archivelog/2011_12_31/o1_mf_1_5_%u_.arc
ORA-00280: 更改 12506717382696 (用于线程 1) 在序列 #5 中
 

看到这个12506717382696了吗？

select 12506719109629/1024/1024/1024 giga from dual;
11647.7898

那么上面的那些值就可以设成11679

我用上面的方法尝试，缺发现无论如何都不行，并且发现我在设_mini_giga_scn参数的时候，报该参数不存在。

到网上查了一下，才发现，oracle 11.2.0.4上已经屏蔽了前面说的那些推进scn的方法了。

剩下的就是两种：
1.oradebug 参考http://blog.itpub.net/29154652/viewspace-774532/
2.直接编辑controlfile 没找到可以借鉴的文章。

根据说法

ORA-00600: internal error code, arguments: [2662], [0], [17074851], [0], [17144854], [12583040], [], [], [], [], [], []

主要是第5个参数17144854，这个是目标的scn号

需要将scn改到大于17144854，才能拉起数据库。
select to_char(17144854,'xxxxxxxx') from dual;
  1059c16

好，开始改scn吧。
参考http://blog.itpub.net/29154652/viewspace-774532/
oradebug setmypid
oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [060019360, 060019390) = 00280FFC 00000000 00000000 00000000 00089F7B 00000000 00000000 00000000 00000000 00000000 60019040 00000000

跟V$DATABASE.CURRENT_SCN相近。
此外，我们使用的Linux平台，属于Little Endian，所以其SCN base在前，SCN wrap在后，这点需要注意。

对本例而言：
需要改 oradebug poke 0x060019360 4 0x01159c16

比1059c16大了一些

然后recover database until cancel
再resetlogs
发现仍然报2662错误

这次的2662第5个值变了，变的比我给的0x01159c16还要大一些。

于是，我将数据文件先恢复，然后直接改成了oradebug poke 0x060019360 4 0x40000000

这次可以了，但又报错ora-600 4193错误

这个是常见错误，一般是
alter system set undo_management=manual;
alter system set undo_tablespace=system;
可以解决，实在不行可以需要设_rollback_segments，具体到网上搜吧。

在本例中，设了两个参数之后，重启，侥幸resetlogs了。

然后就开始exp。

按理说，到这里故事就结束了。
实际上，导出的时候发现有5张表报错ORA-600 后面错误号不常见，我忘记了。
后面待续。。。