ORA-600 [2103]错误及CF enqueue竞争

昨天，客户的一套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有很多，只能提醒大家的是，遇到这个错误就要注意了！

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

转载于:http://blog.itpub.net/111631/viewspace-584875/