查询了一下Oracle的metalink，发现这个600错误是个内部错误，有可能是恢复的时候数据块出现corrupt造成的。
另外一种可能性是由于Oracle的bug，比如10.2版本中，使用分布式事务就可以碰到这个问题，详细描述可以参考：Doc ID: Note:551993.1。
而这个问题影响10.2.0.1到10.2.0.3，Oracle在10.2.0.4解决了这个问题，不过10.2.0.4补丁集的推出时间要比11.1.0.6要晚很多，因此这个问题很可能也影响了11.1版本。
后台告警alert日志的信息如下：
Errors in file /data/oracle/diag/rdbms/rac11g/rac11g1/trace/rac11g1_pr03_4932.trc (incident=19625):
ORA-00600: internal error code, arguments: [2037], [8448906], [113377280], [151], [221], [221], [8448906], [0]
查询对应的trace文件：
bash-3.00$ more /data/oracle/diag/rdbms/rac11g/rac11g1/trace/rac11g1_pr03_4932.trc
Trace file /data/oracle/diag/rdbms/rac11g/rac11g1/trace/rac11g1_pr03_4932.trc
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORACLE_HOME = /data/oracle/product/11.1/database
System name: SunOS
Node name: ser1
Release: 5.10
Version: Generic_127111-11
Machine: sun4u
Instance name: rac11g1
Redo thread mounted by this instance: 1
Oracle process number: 53
Unix process pid: 4932, image: oracle@ser1 (PR03)

*** 2008-09-04 16:14:50.437
*** SESSION ID:(665.40) 2008-09-04 16:14:50.437
*** CLIENT ID:() 2008-09-04 16:14:50.437
*** SERVICE NAME:() 2008-09-04 16:14:50.437
*** MODULE NAME:() 2008-09-04 16:14:50.437
*** ACTION NAME:() 2008-09-04 16:14:50.437

TYP:2 CLS: 1 AFN:2 DBA:0x0080eb8a OBJ:64686 SCN:0x0000.0191ddcd SEQ: 1 OP:10.2
Encrypted block <2147483647, 8448906> content will not be dumped. Dumping header _disibledevent= CORRUPT
Dump of memory from 0x000000060FCAC000 to 0x000000060FCAC014
60FCAC000 DD970601 06C20000 0080EB8A 0191DD97 [................]
60FCAC010 00000100 [....]
Incident 19625 created, dump file: /data/oracle/diag/rdbms/rac11g/rac11g1/incident/incdir_19625/rac11g1_pr03_4932_i19625.trc
ORA-00600: internal error code, arguments: [2037], [8448906], [113377280], [151], [221], [221], [8448906], [0]
Incident 19626 created, dump file: /data/oracle/diag/rdbms/rac11g/rac11g1/incident/incdir_19626/rac11g1_pr03_4932_i19626.trc
ORA-07445: exception encountered: core dump [kcbs_dump_adv_state()+608] [SIGSEGV] [ADDR:0xA7A800000007BBD7] [PC:0x1018E7B40] [Addres
s not mapped to object] []
ORA-00600: internal error code, arguments: [2037], [8448906], [113377280], [151], [221], [221], [
根据错误现象和错误日志分析，感觉问题更像是redo文件中的数据库出现了corrupt造成的问题。
很可能是第一次恢复过程中，将日志文件从裸设备dd到文件系统的时候，没有关闭源数据库，导致了日志文件出现了不一致的情况。
而第二次恢复过程则注意到了这个问题，因此恢复过程没有碰到任何的问题，后台也没有出现异常。
因此基本可以确定，这个错误是人为失误造成的。