1. 理解Oracle19c集群节点故障恢复的核心场景
当Oracle19c RAC集群中的某个节点因硬件故障或系统崩溃导致不可用时，整个集群的高可用性就会受到威胁。我曾经遇到过这样的情况：凌晨三点接到报警，发现生产环境中的orcl01节点突然宕机，经过排查发现是存储控制器故障导致。这种情况下，我们需要快速而安全地将故障节点从集群中移除，并在修复后重新加入集群。
节点故障通常分为两种类型：临时性故障和永久性故障。对于临时性故障（如网络闪断），集群通常能自动恢复；但对于永久性故障（如硬盘损坏、主板故障），就需要我们手动介入。在实际操作中，我发现很多DBA容易忽略一个关键点：故障节点的清理必须彻底，任何残留的配置信息都可能导致后续重新加入集群时出现问题。
2. 故障节点的安全删除操作流程
2.1 环境检查与准备工作
在开始删除故障节点前，必须确保剩余的健康节点（如orcl02）运行正常。我通常会执行以下检查：
# 检查集群状态 crsctl check cluster -all # 查看资源运行情况 crsctl stat res -t # 验证ASM磁盘组状态 asmcmd lsdg重要提示：如果故障节点完全无法访问，我们需要在健康节点上强制删除其信息。但在此之前，建议备份以下关键文件：
- OCR（Oracle Cluster Registry）文件
- Voting Disk文件
- ASM spfile文件
我曾经因为没做备份而吃过亏，后来养成了操作前必备份的习惯。可以使用以下命令备份OCR：
# 以root用户执行 ocrconfig -manualbackup2.2 删除数据库实例信息
当orcl01节点完全宕机无法恢复时，我们需要从数据库层面删除其实例信息。这里有两种方法：
图形界面方式：
- 在健康节点上运行DBCA
- 选择"Instance Management" → "Delete Instance"
- 选择要删除的实例（orcl1）
命令行方式（更适合生产环境）：
dbca -silent -deleteInstance \ -nodeName orcl01 \ -gdbName orcl \ -instanceName orcl1 \ -sysDBAUserName sys \ -sysDBAPassword "your_password"这个操作会：
- 禁用该实例对应的instance_number
- 删除对应的redo log thread
- 移除节点相关的undo表空间
2.3 清理集群注册信息
接下来需要从集群配置中彻底清除故障节点。这一步非常关键，也是容易出错的地方：
# 首先停止并删除VIP资源 srvctl stop vip -i orcl01-vip srvctl remove vip -i orcl01-vip -f # 检查节点状态 olsnodes -s -t # 如果状态为unpinned，需要先执行 crsctl unpin css -n orcl01 # 正式删除节点 crsctl delete node -n orcl01常见问题处理：如果遇到"CRS-2673: Attempting to stop 'ora.asm' on 'orcl01'"这样的错误，说明集群仍在尝试管理故障节点上的资源。这时可以添加-force参数强制删除：
crsctl delete node -n orcl01 -f3. 修复后的节点重新加入集群
3.1 节点重新配置前的准备工作
在重装操作系统后的orcl01节点上，需要确保所有配置与集群中的其他节点一致。根据我的经验，以下检查项必不可少：
网络配置检查：
- /etc/hosts文件必须包含所有VIP和SCAN IP
- 网络接口配置应与原节点一致
- 确保私网和公网的MTU值一致（通常为9000）
存储配置验证：
# 检查多路径配置 multipath -ll # 确认磁盘权限 ls -l /dev/oracleasm/disks/* # 验证AFD状态 afd_state系统参数一致性检查：
- 内核参数（/etc/sysctl.conf）
- 用户限制（/etc/security/limits.conf）
- 透明大页设置
- 时间同步配置
我通常会直接从健康节点复制这些配置文件：
# 从orcl02复制内核参数 scp root@orcl02:/etc/sysctl.conf /etc/ # 应用修改 sysctl -p3.2 使用addnode.sh添加节点
GI软件层添加：
# 在健康节点(orcl02)上执行 su - grid export IGNORE_PREADDNODE_CHECKS=Y cd $ORACLE_HOME/addnode ./addnode.sh -silent -ignorePrereq \ "CLUSTER_NEW_NODES={orcl01}" \ "CLUSTER_NEW_VIRTUAL_HOSTNAMES={orcl01-vip}"执行过程中会提示在两个节点上分别运行root.sh脚本。特别注意：在新节点上运行root.sh时，如果遇到"CLSR-0010"错误，通常是因为之前的清理不彻底，需要检查并清理/var/tmp/.oracle目录。
数据库软件层添加：
su - oracle export IGNORE_PREADDNODE_CHECKS=Y cd $ORACLE_HOME/addnode ./addnode.sh -silent -ignorePrereq \ "CLUSTER_NEW_NODES={orcl01}" \ "CLUSTER_NEW_VIRTUAL_HOSTNAMES={orcl01-vip}"3.3 数据库实例重建
使用DBCA重新创建实例：
dbca -silent -addInstance \ -nodeName orcl01 \ -gdbName orcl \ -instanceName orcl1 \ -sysDBAUserName sys \ -sysDBAPassword "your_password"关键点：确保新实例使用的参数文件(spfile)是从健康节点复制的，以保持参数一致：
# 从orcl02复制spfile scp oracle@orcl02:$ORACLE_HOME/dbs/spfileorcl.ora $ORACLE_HOME/dbs/4. 集群健康检查与验证
4.1 集群组件状态验证
节点重新加入后，必须全面检查集群健康状况：
# 检查集群服务状态 crsctl check crs # 查看所有资源状态 crsctl stat res -t # 验证投票盘状态 crsctl query css votedisk # 检查ASM磁盘组 asmcmd lsdg4.2 数据库实例与性能检查
-- 检查实例状态 SELECT inst_id, instance_name, status, thread# FROM gv$instance; -- 验证redo日志组 SELECT group#, thread#, status FROM v$log; -- 检查undo表空间 SELECT tablespace_name, status FROM dba_tablespaces WHERE contents = 'UNDO';4.3 服务与负载均衡验证
确保服务已正确配置到新加入的节点：
srvctl config service -d orcl -s orclsrv srvctl status service -d orcl -s orclsrv性能监控建议：在节点重新加入后的24小时内，应密切监控以下指标：
- 集群互联网络流量
- 全局缓存等待事件
- 实例资源使用情况
可以通过AWR报告对比节点加入前后的性能变化：
-- 生成AWR报告 @$ORACLE_HOME/rdbms/admin/awrrpt.sql在实际操作中，我发现很多问题都源于配置不一致或清理不彻底。因此，在删除故障节点时一定要耐心细致，确保没有残留信息；在重新加入节点时，则要严格验证每项配置。记住，预防总是比修复更重要——定期检查集群健康状况，建立完善的监控体系，才能最大限度减少这类故障的发生。
