阅读更多
昨天,客户的一套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住了15分钟,这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有很多,只能提醒大家的是,遇到这个错误就要注意了!