立即注册 登录
关注IT社区 返回首页

o0JSP的个人空间 http://u.gzit.org/?27 [收藏] [复制] [分享] [RSS]

日志

11.2.0.4数据库升级以后数据库状态变成UNKNOWN

已有 1018 次阅读2015-9-29 15:21 |个人分类:Oracle| 数据库

        今天上午,同事反应有一套库之前在做升级的时候,升级失败了,结果导致了从集群资源列表上看,数据库的状态是UNKNOWN的状态。重启过集群和服务器,都存在一样的问题,在启动过程中,集群列表中的状态从starting转变成cleaning,然后就变成UNKNOWN了。但是经过测试,通过手工切换到ORACLE用户去startup数据库是可以起得来的,只是状态还是一直是UNKNOWN。
        已经检查过的内容有:存储盘的属性及权限:660 grid asmadmin (无异常);$ORACLE_HOME/bin下的oracle文件属性及属主也是正确的。
       经过查阅一些资料,发现存在异常的节点A和未执行更新操作的节点B相比,ps -ef|grep oraagent结果列表中,有异常的节点缺少了一个由oracle用户运行的oraagent进程。也就是说,现在的问题主要为无法通过集群的代理进程来对数据库进行管理。
      处理过程:
      1、切换到Oracle用户下,到$GRID_HOME/bin目录下执行oraagent.bin,发现报错,提示内容为找不到libeonsserver.so文件。
      2、到$GRID_HOME/lib目录下检查,发现确实存在该文件。
      3、想到由于是ORACLE用户下执行的,所以获取不到GRID_HOME/lib下的文件,所以导致找不到libeonsserver.so文件。
      4、于是将GRID用户下的$ORACLE_HOM $LIBPATH 在oracle用户下export
      5、再次尝试用oracle用户执行oraagent.bin,这次报错的异常为对其他的.so文件没有足够权限(permision denied)
      6、将A,B机器的$GRID_HOME/lib目录下所有.so的权限进行列表、对比(ls -l *.so)
      7、发现确实存在3个不同权限的so文件,正常的权限为755,而异常节点当前的权限为700
      8、将错误文件的权限修正为755(chmod 755 xxx.so)
      9、为了可以彻底释放相关类库文件,决定将整台机器重启
      10、重启机器完成以后,重新启动集群 crsctl start crs
      11、观察启动过程,发现所有资源都可以正常ONLINE、OPEN
      好了,现在可以重新再把打失败的补丁再进行不定升级了。
      PS:据反应,同事重新执行数据库更新操作的过程中,一切顺利,没有再出现失败的情况发生。

路过

鸡蛋

鲜花

握手

雷人

评论 (0 个评论)

facelist

您需要登录后才可以评论 登录 | 立即注册

Archiver|关注IT ( 粤ICP备06100905号 )

GMT+8, 2018-12-13 03:23 , Processed in 0.117230 second(s), 13 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部