ALERT.LOG for ASM Shows "WARNING: failed to online diskgroup resource ora.GI.dg (unable to communica

APPLIES TO:

OracleDatabase - Enterprise Edition - Version 11.2.0.1 to 12.1.0.1 [Release 11.2 to12.1]

Informationin this document applies to any platform.

***Checked for relevance on 03-Jul-2013***

SYMPTOMS

If OCR is located on ASM diskgroup, following shows inASM alert log ($ORACLE_BASE/diag/asm/+asm/+ASMn/trace/alert_+ASMn.log)
after ASM mounted all diskgroup successfully whilestarting up Grid Infrastructure(CRS):

SQL>ALTER DISKGROUP ALL MOUNT /* asm agent */

..

SUCCESS:diskgroup GI was mounted

SUCCESS:ALTER DISKGROUP ALL MOUNT /* asm agent */

..

WARNING:failed to online diskgroup resource ora.GI.dg (unable to communicate withCRSD/OHASD)

Or after ASM dismounted all diskgroup successfullywhile shutting down clusterware:

..

SUCCESS:ALTER DISKGROUP ALL DISMOUNT /* asm agent */

Sun Feb07 11:11:13 2010

WARNING:failed to offline diskgroup resource ora.GI.dg (unable to communicate withCRSD/OHASD)

..

freeingrdom 0

CAUSE

In contrast to previous version of CRS, 11gR2 ASM doesnot depend on CRSD anymore; rather if OCR is located on ASM, ASM will startbefore CRSD while clusterware is coming up, and stops
after CRSD whileclusterware is going down. Due to the new startup sequence, ASM can not updatediskgroup resource status in CRSD either during clusterware startup orshutdown, thus above message is logged.

SOLUTION

The message can be ignored, the status of diskgroupand diskgroup resource will be synchronize by oraagent once clusterware isfully up.

To find out diskgroup resource status:

$GRID_HOME/bin/srvctl status diskgroup -gdiskgroupname -a

To start or sync diskgroup resource:

$GRID_HOME/bin/srvctl start diskgroup -g diskgroupname

时间: 2024-10-26 08:54:05

ALERT.LOG for ASM Shows "WARNING: failed to online diskgroup resource ora.GI.dg (unable to communica的相关文章

alert日志报错:ERROR: failed to establish dependency between database RACDB and diskgroup resource ora.DATA.dg

一.打开数据库alert日志,发现有报错 ERROR: failed to establish dependency between database RACDB and diskgroup resource ora.DATA.dg 二.上mos查看(是一个BUG,无害) This error is harmless. It is documented in the  internal Bug 8304720 "ERROR: FAILED TO ESTABLISH DEPENDENCY BETW

RMAN-06820: WARNING: failed to archive current log at primary database

12C dataguard备库备份archivelog出现报错   Problem Description --------------------------------------------------- SQL> select * from product_component_version ;   PRODUCT                                  VERSION    STATUS ------------------------------------

【MongoDB】2014-07-25T11:00:48.634+0800 warning: Failed to connect to 127.0.0.1:27017, reason: errno:10061 由于目标计算机积极拒绝,无法连接。

1:启动MongoDB 2014-07-25T11:00:48.634+0800 warning: Failed to connect to 127.0.0.1:27017, reason: errno:10061 由于目标计算机积极拒绝,无法连接. 2:添加一配置文件 ##数据文件 dbpath=E:\ruanjian\MongoDB\data ##日志文件 logpath=E:\ruanjian\MongoDB\log\mongo.log 添加相应目录和文件,如下图所示 3: C:\User

Active Session History (ASH) Performed An Emergency Flush Messages In The Alert Log

Active Session History (ASH) Performed An Emergency Flush Messages In The Alert Log (文档 ID 1385872.1)   In this Document   Symptoms   Cause   Solution This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and the

6_Oracle_Admin_Oracle的诊断文件(根据alert.log创建pfile、调整sql_trace)

后台的server(数据库,tomcat等server),通常通过文本来记录日志,对于Oracle这样重量级的数据库,日志文件非常详细,当出现了故障需要排查时,就可以分析查看日志文件.Diagnosticfiles的作用就在于此. 日志文件分为两类: 1. Alter file 和Trace File (每个进程一个,在该进程生命周期内创建)不同,AlertFile 只有一个,它随着时间的推移体积逐渐增大,它存放的地址可以通过BACKGROUND_DUMP_DEST或USER_DUMP_DEST

查看alert.log

一.通过OEM 来查看. 二.使用文本编辑器来查看. 1.使用查询工具登录到数据库,比如sql*plus. 2.查询v$diag_info 视图定位 alert log的位置. SQL> select name,value from V$diag_info 2  where name in('Diag Trace','Diag Alert'); NAME ---------------------------------------------------------------- VALUE

Oracle - 截取指定日期的alert log

工作中DBA经常会查看alert log来检查数据库后台都记录了些什么日志,如果只想看某一天或者某段时间范围的日志,能够把这些日志从大的alert log中截取下来放到一个单独的文件中,对于查看和下载都是很有意义的事,接下来附上脚本 script.sh #!/bin/bash ################################################################################ # this script is to get the sp

AndroidStudio报错:Emulator: I/O warning : failed to load external entity "file:/C:/Users/Administrator/.AndroidStudio3

场景 在进行Android Studio的.Android Studio目录从C盘修改为其他目录后,新建App启动提示: Emulator: I/O warning : failed to load external entity "file:/C:/Users/Administrator/.AndroidStudio3 注: 博客: https://blog.csdn.net/badao_liumang_qizhi 关注公众号 霸道的程序猿 获取编程相关电子书.教程推送与免费下载. 实现 这是

Android文件操作报open failed: EBUSY (Device or resource busy)

Android删除文件后重新创建时偶尔出现 open failed: EBUSY (Device or resource busy)错误,该错误是Android系统的一个bug,大概的意思类似于windows的"改文件正在被使用".产生这个错误的原因是Android在删除文件后没有及时释放文件锁,导致文件在重新创建时仍然处于被某一进程占用的状态.解决的方法是:在删除文件之前对该文件进行重命名,这样可以保证在删除文件时系统持有的文件锁是重命名之后的文件锁.代码可以这样写: final F