遭遇ORA-00600: internal error code, arguments: [kcrrrfswda.11], [4], [368], [], [], [], [], []

因为清理历史数据需要，所以对一列老的RANGE分区直接做DROP操作，因为这些分区表上还有GLOBAL索引，而业务又不能停，所以DROP的时候使用了UPDATE GLOBAL INDEX参数，使得DROP分区的时候索引不会失效。在处理最大的一个1.7亿的表（每个分区大概有4千万数据）的时候，DROP第一个分区，没问题，清除第二个分区过程中，收到系统监控的报警：
Errors in file /u01/app/oracle/admin/billdb/bdump/billdb1_lns1_28689.trc:
ORA-00272: error writing archive log
Thu May 8 22:23:26 2008
LGWR: I/O error 272 archiving log 2 to 'dgp'
DGP是PHYSICAL DATAGUARD，看来是往物理DATAGUARD上写日志的时候出现问题，于是登陆物理DATAGUARD机器检查，却发现DATAGUARD机器出现如标题所示的600错误，查看TRACE文件，一堆二进制的天书。咋办呢？[@more@]

看来这个问题不解决，生产上日志是应用不过来了，所以在生产上先把往这里写的日志关闭，然后继续DROP分区，经过漫长的等待，终于删除完了。想想难道是因为删除分区的时候UPDATE GLOBAL INDEX使得生成的日志过多，或者是DATAGUARD机器磁盘空间不够了？磁盘空间足够，归档缺失有点快，1G一个的日志，7分钟归档一次，可是相应的逻辑的DATAGUARD却没有这样的问题啊，归档被成功的写过去了。看来跟归档频率也没关系。

METALINK了一把，碰见这样问题的人很少，而且碰见的问题很多都是SUSPEND中，只有几个是Vendor OS Problem，难道是操作系统问题？检查/VAR/LOG/MESSAGE，没有任何异常。过了两个小时，更狠的来了，凌晨2点有物理DATAGUARD上的数据备份，备到一半，机器直接挂了，PING不通，SSH连不上，彻底歇菜了。

第二天，直接冲到机房，接上显示器，屏幕上一堆天书样的字母，没有什么有价值的信息，而且键盘也没有任何反应，死机？只能重新启动，启动后，机器恢复正常。于是开始生产往这边的归档日志写，一会功夫，开始报错：
Errors in file /u01/app/oracle/admin/billdb/bdump/billdb_mrp0_6966.trc:
ORA-00399: corrupt change description in redo log
ORA-00353: log corruption near block 1015371 change 4810221960 time 05/08/2008 22:22:46
ORA-00312: online log 9 thread 1: '/u02/stdlog/stdlog01.log'
最后直接导致:
MRP0: Background Media Recovery process shutdown (billdb)
而且，接着就又来了ORA 600了。

再接下来就是：
Errors in file /u01/app/oracle/admin/billdb/bdump/billdb_arc2_6961.trc:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 238564 change 4812352033 time 05/09/2008 03:41:51
ORA-00312: online log 11 thread 2: '/u02/stdlog/stdlog03.log'
ARC2: All Archive destinations made inactive due to error 354
直接关闭了归档路径了，然后就不能归档了：
ORACLE Instance billdb - Archival Error
Fri May 9 13:30:09 2008
ORA-16014: log 10 sequence# 3535 not archived, no available destinations
ORA-00312: online log 10 thread 1: '/u02/stdlog/stdlog02.log'

看来是日志坏了，而且是STANDBY REDO LOG，于是直接把STANDBY REDO LOG删除，重新建了日志上去。但是新的错误又来了：
ORA-27052: unable to flush file data
Linux-x86_64 Error: 30: Read-only file system
Additional information: 1
啊？？文件系统出问题了？上去看了看权限没问题啊，正在这时，更糟糕的事情来了，机器又PING不通了，晕死！冲到机器前面一看，亮黄灯了都，ECC ERROR，十之八九是内存错误了。联系了厂商工程师，确认是内存错误，建议先把插槽中的内存位置对调下，重新开机，居然就可以了。然后立马使用硬件检查的工具检查了一遍，居然内存检查是OK的。

看来这一系列的问题估计都跟内存错误有关的，不过最初发现错误的时候服务器居然显示正常的绿灯，不可理解。重新进行数据库操作，才发现存放数据文件的磁盘都没了，这下搞大了，FDISK看了下，分区还在，那就使用FSCK检查下吧，发现一堆错误，到现在也只能乱投医了，不管FSCK出现啥提示，一路YES下去。神奇的发现检测完后，居然能mount上去了。

磁盘是认出来了，但是上面的未应用的归档日志却被损坏了：
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 579728 change 4811213035 time 05/09/2008 02:59:53
ORA-00334: archived log: '/u02/arch/Arc_2_2575_592235202.arc'

经过漫长的RFS自动GAP这些归档日志，总算应用成功了。看了看日志应用正常，可是，故事却没有结束。。。

凌晨2点，数据库备份开始，却发现了新的错误：
Corrupt block relative dba: 0x01cac6ec (file 7, block 706284)
Fractured block found during backing up datafile
Data in bad block:
type: 6 format: 2 rdba: 0x01cac6ec
last change scn: 0x0001.033ab516 seq: 0x4 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00130012
check value in block header: 0xd55f
computed block checksum: 0x11b1

坏块？？看来这些文件还是有问题啊，不管了，干脆重建这个DATAGUARD吧，几百G的库啊，经过漫长的等待，终于搞定了，世界终于平静了！

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25016/viewspace-1003990/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25016/viewspace-1003990/