突发！凌晨1点服务器主板烧毁致命生产故障，RAC集群修复

作者：IT邦德
中国DBA联盟(ACDU)成员，10余年DBA工作经验
擅长主流数据Oracle、MySQL、PG、openGauss运维
备份恢复，安装迁移，性能优化、故障应急处理等

可提供技术业务：
1.DB故障处理/疑难杂症远程支援
2.Mysql/PG/Oracle/openGauss
数据库部署及数仓搭建

公众号：IT邦德
•••

@TOC

前言

今天凌晨1点32分，一套Oracle 19C RAC节点1发生服务器主板烧毁导致业务中断，故障修复分享给大家

---

1.故障现象

凌晨1点32分，接到项目组的电话，生产环境的一套Oracle 19C RAC节点1发生服务器主板烧毁导致业务中断，因为应用没有配置FAILOVER_MODE
集群及数据库安装列表：
[root@racdb2 ~]# cat /etc/oraInst.loc
inventory_loc=/u01/app/oraInventory
inst_group=oinstall
[root@racdb2 ~]# cd /u01/app/oraInventory
[root@racdb2 oraInventory]# ll
total 20
drwxrwx--- 3 grid oinstall 4096 Jan 19 21:43 backup
drwxrwx--- 2 grid oinstall 4096 Jan 19 21:28 ContentsXML
drwxrwx--- 2 grid oinstall 4096 Jan 19 21:55 logs
-rw-rw---- 1 grid oinstall   56 Jan 19 21:28 oraInst.loc
-rwxrwx--- 1 grid oinstall 1617 Jan 19 21:28 orainstRoot.sh
[root@racdb2 oraInventory]# cd ContentsXML
[root@racdb2 ContentsXML]# ls -l
total 12
-rw-rw---- 1 grid oinstall 300 Jan 19 21:55 comps.xml
-rw-rw---- 1 grid oinstall 561 Jan 19 21:55 inventory.xml
-rw-rw---- 1 grid oinstall 292 Jan 19 21:55 libs.xml
此时查看正常节点2集群状态如下，可以看出损坏节点1的数据库实例和 VIP 处于 offline 状态
紧急处理方式为让业务连接2节点，接下来需要进行节点1系统的安装，并恢复RAC集群

2.相关备份

--备份 OCR
在正常节点，以 root 用户执行：
[root@racdb2 ~]# ocrconfig -export /tmp/ocr.20240128
PROT-58: successfully exported the Oracle Cluster Registry contents to file '/tmp/ocr.20240128'

--备份安装列表
cp /u01/app/oraInventory/ContentsXML/inventory.xml /tmp/inventory.xml.bak

此时立马对数据库进行一次全备份

3.节点清理

1.在正常节点执行 deletenode.sh
su - grid
/u01/app/19.0.0/grid/crs/utl/rootdeletenode.sh racdb1


2.在正常节点更新安装列表
su - oracle
cd $ORACLE_HOME/oui/bin
./runInstaller -updateNodeList ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 "CLUSTER_NODES={racdb2}"

su - grid
cd $ORACLE_HOME/oui/bin
./runInstaller -updateNodeList ORACLE_HOME=/u01/app/19.0.0/grid "CLUSTER_NODES={racdb2}" CRS=TRUE

3.在正常节点清理异常节点 CRS 资源
crsctl status res -t
srvctl stop vip -i racdb1
srvctl remove vip -i racdb1 -f

4.修复前检查

原则上应按照系统安装前检查配置项目逐一进行检查，并与现存正常节点比较。
如果新安装操作系统，尤其需要注意以下几个方面
1 相关目录宿主及权限
2 相关包安装完整
3.检查两台服务器的网络名及联通性

--创建目录语句
mkdir -p /u01/app/oraInventory
chown -R grid:oinstall /u01/app/oraInventory
chmod -R 775 /u01/app/oraInventory

mkdir -p /u01/app/oracle/admin/PROD/adump
chown -R oracle:oinstall /u01/app/oracle/admin/PROD/adump

mkdir -p /u01/app/oracle/admin/PROD/dpdump
chown -R oracle:oinstall /u01/app/oracle/admin/PROD/dpdump

chown -R oracle:oinstall /u01/app/oracle

5.GRID修复

cd $ORACLE_HOME
export IGNORE_PREADDNODE_CHECKS=Y
[grid@racdb2 addnode]$ ./addnode.sh -silent \
-ignorePrereq "CLUSTER_NEW_NODES={racdb1}" \
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={racdb1-vip}" \
"CLUSTER_NEW_PRIVATE_NODE_NAMES={racdb1-priv}" \
"CLUSTER_NEW_NODE_ROLES={hub}"

As a root user, execute the following script(s):
1. /u01/app/19.0.0/grid/root.sh

6.ORACLE软件修复

为新节点添加Database软件 (在现有集群节点以oracle用户执行)
[oracle@racdb2 ~]$ cd /u01/app/oracle/product/19.0.0/dbhome_1/addnode/
[oracle@racdb2 addnode]$ ./addnode.sh \
-silent -ignorePrereq \
"CLUSTER_NEW_NODES={racdb1}"

7.修复db实例

使用dbca工具执行以下命令，以静默模式添加新节点数据库实例（在现有集群节点以oracle用户执行）

[oracle@rac2 ~]$ dbca -silent \
-addInstance -gdbName "PROD" \
-nodeName "racdb1" \
-instanceName "PROD1" \
-sysDBAUserName "sys" \
-sysDBAPassword "oracle"

8.开库相关设置

1.添加undo及redo
alter database add logfile thread 1 group 10 size 50M;
alter database add logfile thread 1 group 11 size 50M;
ALTER DATABASE enable THREAD 1;
create undo tablespace UNDOTBS1 datafile size 10G autoextend on;

2.修改pfile
SQL> create pfile='/home/oracle/pfile20240128' from spfile;
主要是把节点1信息做一次修改
PROD1.thread=1
PROD2.thread=2
PROD1.undo_tablespace='UNDOTBS1'
PROD2.undo_tablespace='UNDOTBS2'
PROD1.instance_number=1
PROD2.instance_number=2


startup nomount pfile='/home/oracle/pfile20240128'
create spfile='+DATA' from pfile='/home/oracle/pfile20240128';

9.总结

以往经验
1 现存正常节点如果有过多的小文件，可以事先删除
例如 aud,trc ，在执行 addnode.sh 的时候，
会严重影响执行时间。
2 执行 adnode.sh 通常执行时间在 15-30 分钟，
如果执行时间过长就要检查原因。判断是文件拷贝太慢，还是进程已经 hang .
3 开始前，应仔细检查对比两端的目录结构及其权限；
4 执行过程中如果出现意外，有可能造成现有正常节点的重启，
影响现有业务。因此此操作存在风险，
最好在在变更窗口内，业务停止状态下实施。