ORA-15164报错导致集群降级没完成，远程帮忙修复故障过程分享

ORA-15164报错导致集群降级没完成，远程帮忙修复故障过程分享

那天下午，我正在处理其他工单，突然接到一位前同事的紧急电话，他语气很着急，说他们的一套重要数据库系统出了大问题，原来，他们计划对一套两节点组成的集群数据库进行维护，需要暂时将一个节点从集群中剔除，也就是执行“降级”操作，但操作过程中，命令执行了一半就卡住了，然后报出了一个他们没见过的错误：ORA-15164，更麻烦的是，操作并没有完全回滚，导致整个集群状态异常，一个节点虽然还在运行，但另一个节点处于一种“要离没离”的尴尬境地，业务虽然暂时没断，但高可用性已经丧失，而且无法进行任何后续操作，大家都不敢重启任何机器,情况非常棘手。

由于他们公司有严格的物理安全规定，外部人员无法进入机房，所以只能通过远程方式协助解决，我让他分享了服务器的基础连接信息,并通过安全的远程桌面方式登录到了他们的管理终端。

登录后，我首先让他带我查看当前集群的状态，他打开了命令行工具，输入了查看集群资源的命令，结果显示，目标节点确实显示为“OFFLINE”（离线），但状态后面跟着一个不常见的标志，暗示着资源被锁定了，这印证了降级操作没有完成,在中间某个环节被中断了。

我需要看具体的错误日志，ORA-15164这个错误代码，根据我的经验，通常与集群的底层组件——集群件在管理共享存储时遇到的权限或状态问题有关，我让他找到了集群的日志文件目录，在密密麻麻的日志文件中，我们重点查看了最近时间戳的日志，经过一番搜索，果然发现了关键信息，日志中明确记录了ORA-15164错误，后面的详细描述指出，在尝试对某个表决磁盘文件进行操作时，发生了“权限不足”的问题，表决磁盘是集群的核心组成部分，用来记录集群成员信息和协调故障切换,它必须能被所有节点同时访问。

问题根源似乎找到了，但很奇怪，因为这套系统已经稳定运行了很久，之前从未出现过存储权限问题，我询问他们最近是否对存储阵列或相关配置做过变更，他们团队讨论后反馈，就在计划降级维护前，存储管理员确实对存放表决磁盘的那个存储卷做过一次“快照”操作，目的是为了备份，听到这里，我心里基本有谱了，某些存储设备在执行快照时，可能会短暂地改变底层卷的访问属性或锁状态，如果这个操作恰好与集群的I/O操作重叠，就有可能留下后遗症,导致集群件认为它失去了对表决磁盘的完整控制权。

仅仅知道原因还不够，必须安全地解决问题，直接重试降级命令肯定还会失败，我需要先“解锁”被卡住的集群状态，我指导他使用了一个集群诊断和恢复工具，这个工具可以以非常底层的模式连接集群件，我让他输入了一条强制清除该节点集群成员状态的命令，这个操作有一定风险，需要非常谨慎，因为如果另一个节点也在同时活动，可能会造成“脑裂”（即两个节点都认为自己是主节点），我反复确认了另一个节点是唯一的活动节点，并且业务稳定后，才让他执行，命令执行后，我们立刻看到，之前那个卡在“OFFLINE”状态的节点资源消失了,集群视图变得干净了。

但这只是解除了软件层面的锁定，根本的存储权限问题还没解决，我让他联系存储管理员，确认对表决磁盘所在的存储卷是否有任何激活的快照或锁存在，并要求立即释放所有非必要的锁，存储管理员检查后,确认并清理了相关状态。

在确保存储层面无障碍后，我们开始了修复的最后一步：重新将那个出问题的节点加入到集群中，这次，我们使用了“添加节点”的操作，他输入了命令，我紧盯着屏幕上的输出信息，命令顺利执行，没有再报错，节点开始同步数据，最终状态稳定地变为“ONLINE”（在线），为了确保万无一失，我们还手动进行了几次故障切换测试，模拟一个节点宕机，看另一个节点是否能顺利接管业务，测试全部成功,集群的高可用性完全恢复。

整个远程修复过程持续了大约两个小时，事后总结，这次故障的根本原因在于运维流程的一个小疏忽：在未完全停止集群服务的情况下，对核心共享存储进行了快照操作，我建议他们以后在执行任何可能影响共享存储的操作前，必须要有更严格的审批和操作流程，确保与数据库团队的沟通到位，这次ORA-15164报错虽然看起来陌生吓人，但归根结底还是对集群基础架构的维护规范问题，通过有条理地查看状态、分析日志、定位根源并谨慎操作，最终在没有物理到场的情况下,成功解决了这个导致集群降级失败的故障。