风影子
作者风影子·2011-05-25 11:12
数据库管理员·深圳

遇到灾备数据库发生ORA-16146与ORA-00600而宕机

字数 7598阅读 22121评论 2赞 2
      今天某项目业主打电话告诉我说我去年实施的DATAGUARD灾备数据库停掉了,要我查原因,于是叫用户发来alertSID.log日志。从日志上看在22日下午2点多灾备数据库就停止服务了,日志中只有ORA-16146与ORA-00600的错误,截取的日志如下
 
      Sun May 22 14:11:51 2011
Errors in file /oracle/admin/standby/bdump/standby_arc1_684124.trc:
ORA-16146: standby destination control file enqueue unavailable
Sun May 22 14:11:56 2011
Errors in file /oracle/admin/standby/bdump/standby_pmon_749700.trc:
ORA-00600: internal error code, arguments: [kfioUnidentify01], [], [], [], [], [], [], []
Sun May 22 14:12:02 2011
Errors in file /oracle/admin/standby/bdump/standby_pmon_749700.trc:
ORA-00600: internal error code, arguments: [kfioUnidentify01], [], [], [], [], [], [], []
Sun May 22 14:12:02 2011
PMON: terminating instance due to error 472
Termination issued to instance processes. Waiting for the processes to exit
Instance terminated by PMON, pid = 749700
Wed May 25 09:01:08 2011
Starting ORACLE instance (normal)
sskgpgetexecname failed to get name
    从日志中看到在22日下午2点多时,数据库实际上已停止服务了,而在25日9时数据库重新启动了,再看后面的日志,看到日志已经开始同步了,说明数据库重启并开启同步服务后一切正常。
 
    于是从网上查了ORA-16146与ORA-00600的相关信息
 
    关于ORA-16146是这么说的

简单检查了一下metalink,感觉这个错误可能与操作系统有关。由于出现错误的时刻,两个RAC节点都在进行LOG日志的切换,而且都设置了LOG传输,将LOG归档到对方节点。因此很可能是由于两个节点同时更新控制文件,导致了其中一个无法获取到控制文件的锁,导致了上面的错误。

根据随后的alert日志,出错的ARCHIVELOG在本地重新归档。从RMAN的备份中也可以看到,无论是本地的归档,还是远端归档,这个日志都是成功的。

但是远端节点的alert文件中,找不到出错ARCHIVELOG归档的描述,而且在视图V$ARCHIVED_LOG中,也缺少远端归档的信息,而只有本地归档的信息。

根据上面的现象,应该远端归档成功,但是将远端归档信息添加到控制文件的时候出现了错误。

如果没有对应其他的ORA-600错误,这个错误并没有太大的问题。如果远端控制文件确实需要这个信息,可以通过ALTER DATABASE REGISTER LOGFILE的方式手工添加ARCHIVELOG信息。

 

关于ORA-00600是这么说的

产生原因:这种错误通常为ORACLE的内部错误,只对OSS和ORACLE开发有用。ORA-600的错误经常伴随跟踪文件的状态转储(系统状态和进程状态),系统状态存储将包括ORACLE RDBMS持有的当前对象的信息,进程状态转储则将显示特殊进程持有的对象,当进程符合了某错误条件时,经常是由于一些信息取自它持有的一个块,如果我们知道这些错误进程持有的块,就容易跟踪问题的来源。

解决方法:一般来说出现这个错误我们本身是无法解决的,只有从提高系统本身各方面来解决这个内部问题,如增加硬件设备,调整系统性能,使用OPS(当然OPS从某种意义上说并不是一种好的解决方式等。ORA-600错误的第一个变量用于标记代码中错误的位置(代码中的每个部分的第一变量都不一样),从第二个到第五个变量显示附加信息,告诉OSS代码在哪里出现了错误。

    由于是外省的项目也不方便收集信息,而且重启数据库后问题解决了,也就没有深入研究了。下面是我找的两篇文章地址:

关于ORA-16146

http://yangtingkun.itpub.net/post/468/480935

关于ORA-00600

http://apps.hi.baidu.com/share/detail/824201

 

ORA-16146错误
===========================================================

在后台alert文件中看到了这个错误。


详细错误信息为:

Fri Mar 20 04:07:56 2009
Errors in file /data/oracle/admin/newtrade/bdump/newtrade2_arc0_17206.trc:
ORA-16146: standby destination control file enqueue unavailable
Fri Mar 20 04:07:56 2009
ARC0: I/O error 16146 archiving log 6 to 'newtrade1'
Fri Mar 20 04:07:57 2009
ARC0: Closing remote archive destination LOG_ARCHIVE_DEST_2: 'newtrade1' (error 16146)
(newtrade2)

查询了对应的trace文件:

bash-3.00$ more /data/oracle/admin/newtrade/bdump/newtrade2_arc0_17206.trc
/data/oracle/admin/newtrade/bdump/newtrade2_arc0_17206.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
ORACLE_HOME = /data/oracle/product/10.2/database
System name: SunOS
Node name: newtrade2
Release: 5.10
Version: Generic_118833-36
Machine: sun4u
Instance name: newtrade2
Redo thread mounted by this instance: 2
Oracle process number: 38
Unix process pid: 17206, image: oracle@newtrade2 (ARC0)

*** 2008-09-30 15:17:40.573
*** SERVICE NAME:(SYS$BACKGROUND) 2008-09-30 15:17:40.573
*** SESSION ID:(259.1) 2008-09-30 15:17:40.572
kccsga_update_ckpt: num_1 = 32, num_2 = 0, num_3 = 0, lbn_2 = 0, lbn_3 = 0
*** 2008-10-04 01:21:46.853
Control file resized from 950 to 972 blocks
kccrsd_append: rectype = 11, lbn = 475, recs = 285
*** 2008-10-06 04:06:00.011
*** 2008-10-06 04:06:00.011 20257 kcrr.c
*** 2008-10-06 04:07:06.608
*** 2008-10-06 04:07:06.608 20257 kcrr.c
*** 2008-10-06 04:07:42.477
*** 2008-10-06 04:07:42.477 20257 kcrr.c
*** 2008-10-06 04:07:44.492 20257 kcrr.c
*** 2008-10-06 04:07:45.818 20257 kcrr.c
*** 2008-10-06 04:07:47.152 20257 kcrr.c
*** 2008-10-06 04:07:48.822 20257 kcrr.c
*** 2008-10-06 04:07:50.841 20257 kcrr.c
.
.
.
*** 2008-10-06 04:10:10.297
*** 2008-10-06 04:10:10.297 20257 kcrr.c
*** 2008-10-06 04:10:11.441 20257 kcrr.c
*** 2008-10-06 04:10:13.461 20257 kcrr.c
*** 2008-10-06 04:10:15.474 20257 kcrr.c
*** 2008-10-06 04:10:36.965
*** 2008-10-06 04:10:36.965 61287 kcrr.c
ARC0: Encountered disk I/O error 19502

简单检查了一下metalink,感觉这个错误可能与操作系统有关。由于出现错误的时刻,两个RAC节点都在进行LOG日志的切换,而且都设置了LOG传输,将LOG归档到对方节点。因此很可能是由于两个节点同时更新控制文件,导致了其中一个无法获取到控制文件的锁,导致了上面的错误。

根据随后的alert日志,出错的ARCHIVELOG在本地重新归档。从RMAN的备份中也可以看到,无论是本地的归档,还是远端归档,这个日志都是成功的。

但是远端节点的alert文件中,找不到出错ARCHIVELOG归档的描述,而且在视图V$ARCHIVED_LOG中,也缺少远端归档的信息,而只有本地归档的信息。

根据上面的现象,应该远端归档成功,但是将远端归档信息添加到控制文件的时候出现了错误。

如果没有对应其他的ORA-600错误,这个错误并没有太大的问题。如果远端控制文件确实需要这个信息,可以通过ALTER DATABASE REGISTER LOGFILE的方式手工添加ARCHIVELOG信息。

 
 
ORA-00600 internal error code,arguments: 问题
原因:   This is the generic internal error number for Oracle program exceptions. It indicates that a process has encountered a low-level, unexpected condition. Causes of this message include: 
1.timeouts(超时) 2.file corruption(文件太老) 3.failed data checks in memory 内存检索失败)4.hardware, memory, or I/O errors(硬件、内存或者磁盘错误) 5.incorrectly restored files(错误的重建文件)The first argument is the internal message number. Other arguments are various numbers, names, and character strings. The numbers may change meanings between different versions of Oracle.     

采取措施: Report this error to Oracle Customer Support after gathering the following information: 1.events that led up to the error 2.the operations that were attempted that led to the error 3.the conditions of the operating system and databases at the time of the error 4.any unusual circumstances that occurred before receiving the ORA-00600 message 5.contents of any trace files generated by the error 6.the relevant portions of the Alter files Note: The cause of this message may manifest itself as different errors at different times. Be aware of the history of errors that occurred before this internal error. 
这个问题好难解决哦,最近遇到过好多这样的问题,都没有解决,烦死了,可能oracle真是靠这个问题来赚钱的。
产生原因:这种错误通常为ORACLE的内部错误,只对OSS和ORACLE开发有用。ORA-600的错误经常伴随跟踪文件的状态转储(系统状态和进程状态),系统状态存储将包括ORACLE RDBMS持有的当前对象的信息,进程状态转储则将显示特殊进程持有的对象,当进程符合了某错误条件时,经常是由于一些信息取自它持有的一个块,如果我们知道这些错误进程持有的块,就容易跟踪问题的来源。
解决方法:一般来说出现这个错误我们本身是无法解决的,只有从提高系统本身各方面来解决这个内部问题,如增加硬件设备,调整系统性能,使用OPS(当然OPS从某种意义上说并不是一种好的解决方式等。ORA-600错误的第一个变量用于标记代码中错误的位置(代码中的每个部分的第一变量都不一样),从第二个到第五个变量显示附加信息,告诉OSS代码在哪里出现了错误。
按eygle的建议:
1.询问你的用户
在出错时,前台是否得到错误提示?
如果有,这个是很重要的辅助诊断信息
2.最好更换网卡,排除这个嫌疑
3.察看后台进程跟踪文件,看是否记录了异常
4.数据库版本?
今天又遇到的这个问题,查看trc文件,提示以下信息:
ORA-00600: internal error code, arguments: [12333], [187], [186], [232], [], [], [], []
Current SQL statement for this session:
Insert Into doc_researchreport (sys_id,sys_control5,reportTypeName,investSuggest)values(:1,:2,:3,:4)
可能是插入记录有问题或是事务等待的时间太长超时了,真的不知道怎么解决了。。。
在网上查到有好多网友遇到这个问题(ora-00600错误真是无处不在):
他在升级一个测试库的过程中碰到了这个问题,由于通过hostname命令修改了主机名称,导致Oracle 10201 for Linux X86-64环境出现实例崩溃,在alert文件中出现了ORA-600(keltnfy-ldmInit)错误。
ORA-00600: internal error code, arguments: [keltnfy-ldmInit], [46], [1], [], [], [], [], []
Oracle的meatlink上文档Doc ID: Note:5486074.8的描述:当Oracle无法确定主机名或者网络地址的时候,会出现这个错误信息。
Oracle在10.2.0.4和11.1.0.6中解决了这个bug。Oracle的metalink上指出在10.2.0.4以前的都可能导致这个错误的产生。
不过测试发现Oracle9i并不会由于修改hostname而导致错误的产生。

来自: http://hi.baidu.com/lichangzai/blog/item/91209711a4a60ac3a6ef3f28.html
  

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

2

添加新评论2 条评论

qy02101qy02101工程师物探中心
2011-06-30 16:12
很不错得解决案例
lzguo568lzguo568软件开发工程师哈尔滨供水集团
2011-05-30 14:52
ora-600 oracle系统严重错误
Ctrl+Enter 发表

作者其他文章

X社区推广