在后台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信息。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
甲骨文自治数据库亮相 带来云计算新希望
早前甲骨文还不在云计算公司之列,而现在该公司正在迅速弥补其失去的时间。甲骨文的云计算核心是甲骨文自治数据库(O […]
-
2017年12月数据库流行度排行榜 定格岁末排名瞬间
数据库知识网站DB-engines最近更新的2017年12月份数据库流行度排名情况是否能提供更多的看点呢?TechTarget数据库网站将与您分享12月份的榜单排名情况,让我们拭目以待。
-
2017年11月数据库流行度排行榜 半数以上数据库积分减少
数据库知识网站DB-engines更新了2016年11月份的数据库流行度排行榜。TechTarget数据库网站将与您一同关注11月份的榜单排名情况。
-
控制合约 不再畏惧Oracle
许多公司都与Oracle有无限制授权协议,他们害怕离开这个协议,所以就证明他们在使用Oracle的软件,即使因为需求单独购买部分授权许可也可能总体是省钱的。