昨天，客户的一套Oracle 10.2.0.3 RAC环境遇到了一个严重故障，数据库最后以ORA-600 [2103]错误中止了一个实例。
日志信息大致如下：
Tue Dec 2 17:21:06 2008
Errors in file /u01/admin/erpdb/bdump/erpdb2_lgwr_127968.trc:
ORA-00600: internal error code, arguments: [2103], [0], [0], [1], [900], [], [], []
Tue Dec 2 17:21:08 2008
Trace dumping is performing id=[cdmp_20081202172108]
Tue Dec 2 17:21:11 2008
Errors in file /u01/admin/erpdb/bdump/erpdb2_lgwr_127968.trc:
ORA-00600: internal error code, arguments: [2103], [0], [0], [1], [900], [], [], []
这里显示LGWR进程中止，出现故障，错误就是ORA-00600 [2103]号错误。
进一步的跟踪文件里的信息如下：
*** 2008-12-02 17:21:06.631
TIMEOUT ON CONTROL FILE ENQUEUE
mode=X, type=0, wait=1, eqt=900
*** 2008-12-02 17:21:06.631
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [2103], [0], [0], [1], [900], [], [], []
这个错误是说，CONTROL FILE ENQUEUE等待超时，超时时间是900秒，也就是错误信息后面的参数，900秒杀15分钟，也就是说，在数据库解决这个队列冲突之前，RAC hang住?5分钟，这15分钟是一个要命的时间。
一个内部参数可以控制这个超时时间，这个参数是：_controlfile_enqueue_timeout，其缺省值是900秒：
SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ
2 FROM SYS.x$ksppi x, SYS.x$ksppcv y
3 WHERE x.indx = y.indx
4 AND x.ksppinm LIKE ’%&par%’
5 /
Enter value for par: controlfile_enqueue
old 4: AND x.ksppinm LIKE ’%&par%’
new 4: AND x.ksppinm LIKE ’%controlfile_enqueue%’
NAME VALUE DESCRIB
_controlfile_enqueue_timeout 900 control file enqueue timeout in seconds
_controlfile_enqueue_holding_time 120 control file enqueue max holding time in seconds
_controlfile_enqueue_dump FALSE dump the system states after controlfile enqueue timeout
_kill_controlfile_enqueue_blocker TRUE enable killing controlfile enqueue blocker on timeout
但是调整这个参数需要验证和慎重。
ORA-600 [2103]相关的Bug有很多，只能提醒大家的是，遇到这个错误就要注意了！
责任编辑：小草
您现在的位置： 