• RAC一节点异常-ORA-01078、ORA-01565、ORA-017503、ORA-01034、ORA-27123


    曲折离奇的故事都是从平淡无奇开始的。

    下班没多久应用统计的指标告警,数量翻倍。

    ……

    最后不知道怎么找到库上,最后又找出,下班后没多久RAC中的一个节点(4节点的RAC,据说是节点3)的防火墙开了(也不知道是怎么开的,经过下面的查看猜测是几个节点都开了)。

    1.开始执行crsctl status res -t显示节点3挂了,我登上去看的时候,节点3和节点1都挂了

    节点3 oracle的alert log

    image

    ORA-29740 实例逐出

    image

    节点1 oracle的alert log

    image

    根据日志看节点1早就挂了,先与节点3

    为啥他们看到只有节点3挂了。

    crsctl status res –t发现3节点db和asm磁盘组都是offline,asm实例也不在;

    crsctl check crs

    image

    root:

    crsctl stop crs报错

    crsctl start crs 报错

    image

    或许有其他方法(待测试),简单粗暴的方法reboot主机

    2.节点1

    image

    直接reboot主机

    3.crsctl status res –t

    image

    %SUQW6N}7UIQJE][28J]}%E

    打完收工(看似完美)。

    4.过来一两个小时,电话响了

    image

    image

    状态好像都没问题啊,可监听有问题

    比较节点2和节点1

    image

    查看节点2的oracle alert log,

    16:10分时是2,3,4三个实例存活

    image

    image

    image

    image

    image

    image

    这是不是就很奇怪了,明明17:53分节点2也挂了,为啥crsctl status resource -t显示正常呢?

    监听也不正常。

    用ezconnect连接节点2的1521端口;其他三个节点用ezconnect连接是正常的

    image

    继续使用重启大法,结果实例2直接offline了,而且oracle 的alert log中竟没一条新的记录,最后的记录还是17:53分

    image

    手动连进去startup,oracle的alert log同样没有新的记录。

    image

    ORA-01078: failure in processing system parameters

    ORA-01565: error in identifying file ‘+DATA/orcl/spfileorcl.ora’

    ORA-17503: ksfdopn:2 Failed to open file +DATA/orcl/spfileorcl.ora

    ORA-01034: ORACLE not available

    ORA-27123: unable to attach to shared memory segment

    Linux-x86_64 Error: 13: Permission denied

    Additional information: 26

    Additional information: 262151

    (为了百度能搜到,我手动敲出来了)

    实在不知道什么原因了,百度了,参考下面文章,

    https://blog.csdn.net/qq_38815172/article/details/74315866

    结果跟文章中一样,权限不对

    image

    image

    image

    image

    image 

    经过上面的处理已经正常了。

    5. 额外看几个节点的/var/log/messages

    节点1:

    16:05和17:42这个是否有异常?

    image

    节点2(上面的截图direct connection failure with ASM,所以怀疑是不是操作系统层面有什么问题):

    16:13 oracle:page allocation failure

    17:46

    image

    image

    节点3:

    16点多没异常日志

    17:47

    image

    节点4:

    17:47

    image

    节点4的alert log

    16:10 把实例1逐出,只剩2,3,4节点

    image

    image

    17:52分 实例4被实例2逐出,然后17:53分实例4正常启动

    image

    image

    17:54分 实例4启动完成

    image

    22:24分 有实例3和实例4

    image

    22:35 有实例1,实例3和实例4

    image

    凌晨2:18 实例1,实例2,实例3和实例4

    image

    从上面的log理出:

    1)16:10分实例1被逐出;

    2)17:52分实例4被实例2逐出,接着实例4重启了;

    3)17:52分实例3也被实例2逐出;

    4)17:52:15秒只有实例2是活着的;

    5)17:53:43秒因ERROR direct connection failure with ASM,实例2挂掉(从操作系统日志看好像也没啥问题);

    节点2的asm的alert log

    image

    节点4的asm alert log里显示实例2和实例3被逐出(应该是asm实例)

    image

    6)17:54分实例4启动完成;

    7)22:00多分别重启节点3和节点1所在主机,实例3和实例1加入集群;

    8)凌晨2:00多实例2加入集群。

    6. 为啥crsctl status resource -t为什么不准?

    这个不知道了。

    只能以后确认的时候,登录到数据库里看看实例状态。

  • 相关阅读:
    maven导入项目时出现“Cannot read lifecycle mapping metadata …… invalid END header (bad central directory offset)pom”错误的解决方法
    Eclipse下使用Git
    Sprint Boot入门(1):创建第一个Spring Boot应用
    Gradle入门(6):创建Web应用项目
    Gradle入门(5):创建二进制发布版本
    maven在windows10系统下安装配置和打包war
    Windows10系统下安装配置Tomcat 9.0.1
    面试题1
    Json序列化帮助类
    NPOI帮助类
  • 原文地址:https://www.cnblogs.com/cnmarkao/p/14207018.html
Copyright © 2020-2023  润新知