一套Linux上的10.2.0.4系统，日志中频繁出现ORA-00600[6711]内部错误:
?
1
2
3
4
5
Wed Sep  1 21:24:30 2010
Errors  in  file /s01/10gdb/admin/YOUYUS/bdump/youyus_smon_5622.trc:
ORA-00600: internal error code, arguments: [6711], [4256248], [1], [4256242], [0], [], [], []
Wed Sep  1 21:24:31 2010
Non-fatal internal error happenned while SMON was doing logging scn-> time  mapping.
MOS上有一个关于6711内部错误十分简单的Note,该文档声称出现6711错误极有可能是部分类型为簇(cluster)的数据字典表存在潜在的讹误，这个Note甚至没有告诉我们该错误argument参数的意义。 不过其实我们可以猜出来,因为是和corruption相关的错误，那么实际上可能关联的几个因素无非是obj#,file#,block#；4256248和4256242 两个数字像极了Data Block Address，把他们当做dba来看待，也就指向了1号数据文件的61938块和61944数据块，我们来看看这些块属于哪个对象：
?
1
2
3
4
5
6
7
8
9
10
SQL>  set  linesize 200;
SQL>  select  segment_name, segment_type
   2     from  dba_extents
   3    where  relative_fno = 1
   4      and  (61938  between  block_id  and  block_id + blocks  or
   5         61944  between  block_id  and  block_id + blocks);
 
SEGMENT_NAME                                                                      SEGMENT_TYPE
--------------------------------------------------------------------------------- ------------------
SMON_SCN_TO_TIME                                                                  CLUSTER
不出意料是一个cluster，SMON_SCN_TO_TIME是SMON_SCN_TIME表的基簇，SMON_SCN_TIME表用以记录数据库中scn对应的时间戳。我们直接查看用以创建数据字典的sql.bsq文件，可以进一步了解他们的结构:
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
cat $ORACLE_HOME/rdbms/admin/sql.bsq|grep -A 24  "create cluster smon_scn_to_time"
create  cluster smon_scn_to_time (
   thread number                         /* thread, compatibility */
)
/
create  index  smon_scn_to_time_idx  on  cluster smon_scn_to_time
/
create  table  smon_scn_time (
   thread number,                         /* thread, compatibility */
   time_mp number,                        /*  time  this recent scn represents */
   time_dp  date ,                          /*  time  as  date , compatibility */
   scn_wrp number,                        /* scn.wrp, compatibility */
   scn_bas number,                        /* scn.bas, compatibility */
   num_mappings number,
   tim_scn_map raw(1200),
   scn number  default  0,                  /* scn */
   orig_thread number  default  0           /*  for  downgrade */
) cluster smon_scn_to_time (thread)
/
 
create  unique  index  smon_scn_time_tim_idx  on  smon_scn_time(time_mp)
/
 
create  unique  index  smon_scn_time_scn_idx  on  smon_scn_time(scn)
/
从以上脚本可以看到这个簇上存在多个索引，我们需要进一步validate验证所有这些对象:
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
SQL> analyze  table  SMON_SCN_TIME validate structure;
Table  analyzed.
 
SQL>analyze  table  SMON_SCN_TIME validate structure  cascade ;
Table  analyzed.
 
SQL> analyze cluster SMON_SCN_TO_TIME validate structure;
Cluster analyzed.
 
SQL> analyze cluster SMON_SCN_TO_TIME validate structure  cascade ;
analyze cluster SMON_SCN_TO_TIME validate structure  cascade
*
ERROR  at  line 1:
ORA-01499:  table / index  cross  reference failure - see trace file
到这里问题已经很清晰了，问题出在SMON_SCN_TO_TIME的索引smon_scn_to_time_idx身上，极有可能是该索引上出现了逻辑讹误。所幸有问题的仅仅是索引，找出问题所在后要解决就显得容易得多了:
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SQL>  alter  index  smon_scn_to_time_idx rebuild ;
 
Index  altered.
 
/* 在索引出现讹误的情况下仅仅rebuild往往是无效的，在我们rebuild的同时告警日志中再次出现了ORA-00600[6711]错误 !!! */
 
/* 我们需要的彻底把有问题的索引 drop 掉，并再次创建!!! */
 
SQL>  drop  index  smon_scn_to_time_idx ;
 
Index  dropped.
 
SQL>  create  index  smon_scn_to_time_idx  on  cluster smon_scn_to_time;
 
Index  created.
 
/* 至此问题解决，告警日志中不再出现错误! * /
 
/* That's great! * /