ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Oracle Flex ASM环境下crsd启动失败故障排查与修复

2026/8/6 11:34:32 拓冰建站 浏览量
Oracle Flex ASM环境下crsd启动失败故障排查与修复

1. 问题现象与背景分析

上周在客户现场遇到一个典型的Flex ASM环境故障:Grid Infrastructure(GI)启动失败,检查发现crsd进程无法正常启动。这个案例很有代表性,今天把完整的排查过程和解决方案整理出来。

Flex ASM是Oracle 12c引入的新特性,它解除了ASM实例与数据库实例之间的一对一绑定关系。在这种架构下,ASM实例可以独立运行,数据库实例可以动态注册到任意ASM实例上。这种灵活性带来了管理便利,但也增加了故障排查的复杂度。

具体到这次故障,当尝试启动GI时,crsd.log中反复出现以下关键报错:

CRS-4124: Oracle High Availability Services startup failed. CRS-4000: Command Start failed, or completed with errors.

2. 关键进程与依赖关系

2.1 GI启动流程解析

理解GI启动流程对排查问题至关重要。标准启动顺序如下:

  1. ohasd(Oracle High Availability Services Daemon)最先启动
  2. ohasd派生agent进程(oraagent、orarootagent等)
  3. agent进程启动crsd(Cluster Ready Services Daemon)
  4. crsd协调其他集群资源(包括ASM实例)的启动

2.2 Flex ASM的特殊性

与传统ASM相比,Flex ASM有三点关键差异:

  1. ASM实例可以少于数据库实例数量
  2. ASM客户端会自动故障转移
  3. ASM磁盘组挂载策略更动态

这些特性导致crsd在Flex ASM环境中需要处理更多状态同步工作,这也是为什么crsd启动失败在Flex ASM环境中影响更大。

3. 问题排查全记录

3.1 日志收集与分析

首先收集关键日志(时间点很重要,建议保留故障时间前后各30分钟日志):

cd $GRID_HOME/log/$HOSTNAME grep -i "error\|fail\|critical" crsd/crsd.log > /tmp/crsd_errors.log

典型错误模式分析:

2023-08-15 14:23:01.543 [CRSD(11012)]CRS-2765: Resource 'ora.asm' has failed on server 'node1'. 2023-08-15 14:23:01.678 [CRSD(11012)]CRS-5017: The resource action "ora.asm start" encountered the following error: ORA-03113: end-of-file on communication channel

3.2 关键检查点

按照以下顺序进行系统检查:

  1. 网络连通性验证
# 检查私网通信 cluvfy comp nodecon -n all -verbose
  1. ASM磁盘组状态检查
-- 通过剩余的ASM实例查询 SELECT name, state, total_mb, free_mb FROM v$asm_diskgroup;
  1. OCR和Voting Disk健康状态
ocrcheck -local crsctl query css votedisk

3.3 根因定位

通过交叉分析日志和检查结果,发现根本原因是:

  • 一个ASM实例异常终止导致磁盘组头信息不一致
  • crsd尝试挂载磁盘组时遇到元数据冲突
  • 重试机制耗尽后进程自行终止

4. 解决方案与实施步骤

4.1 应急恢复方案

对于生产环境,建议按以下顺序操作:

  1. 停止所有依赖资源
crsctl stop res -all
  1. 手动清理ASM实例状态
-- 在存活的ASM实例上执行 ALTER DISKGROUP DATA MOUNT FORCE;
  1. 重置集群状态
crsctl stop crs crsctl start crs

4.2 彻底修复方案

  1. 重建ASM实例的spfile
CREATE PFILE='/tmp/asm_pfile.ora' FROM SPFILE; -- 手动编辑后重建 CREATE SPFILE FROM PFILE='/tmp/asm_pfile.ora';
  1. 修复磁盘组元数据
asmcmd afd_edit --metadata=DATA --repair
  1. 验证集群完整性
cluvfy stage -post crsinst -n all

5. 预防措施与最佳实践

5.1 监控策略优化

建议在Flex ASM环境中增加以下监控项:

  1. ASM实例负载均衡检查
SELECT instance_name, db_name, status FROM v$asm_client;
  1. 磁盘组冗余状态监控
asmcmd lsdg --suppressheader DATA | awk '{print $8}'

5.2 配置调优建议

在Flex ASM环境中,这些参数需要特别注意:

-- 增加客户端重试次数 ALTER SYSTEM SET "_asm_client_connect_retry"=20 SCOPE=SPFILE; -- 调整心跳超时时间 ALTER SYSTEM SET "_asm_hbeatiowait"=200 SCOPE=SPFILE;

5.3 备份策略调整

针对OCR和ASM元数据:

  1. 增加OCR自动备份保留天数
ocrconfig -autobackup_retention_days 15
  1. 定期导出ASM元数据
asmcmd md_backup /backup/asm_metadata_$(date +%Y%m%d).xml

6. 深度技术解析

6.1 crsd启动机制详解

crsd进程启动时会执行以下关键操作:

  1. 加载OCR(Oracle Cluster Registry)内容
  2. 验证Voting Disk可用性
  3. 建立与其他节点的通信通道
  4. 初始化资源管理子系统

在Flex ASM环境中,额外增加了:

  1. ASM实例健康状态检查
  2. 客户端注册表同步
  3. 动态负载均衡评估

6.2 Getis-Ord GI*统计量的应用

Getis-Ord GI*是一种空间统计方法,在集群故障分析中可以:

  1. 识别异常节点(热点分析)
  2. 评估故障传播模式
  3. 预测潜在风险点

具体实现方法:

# 示例伪代码 def calculate_gi_star(nodes): # 计算每个节点的权重矩阵 weights = build_spatial_weights(nodes) # 计算GI*统计量 for node in nodes: gi = (sum(weights[node] * node.metrics) - mean(node.metrics)) / std(node.metrics) # 显著性检验 if abs(gi) > 2.58: # 99%置信度 mark_as_hotspot(node)

7. 典型错误场景汇编

7.1 权限类问题

  1. 症状:
CRS-2674: Start of 'ora.asm' on 'node1' failed ORA-01031: insufficient privileges

解决方案:

chown grid:oinstall /dev/asm* chmod 660 /dev/asm*

7.2 网络类问题

  1. 症状:
CRS-4000: Command Start failed, or completed with errors. Network communication error

诊断命令:

oifcfg getif -global ping -c 3 -s 8972 $NODE2_VIP # 测试MTU问题

7.3 存储类问题

  1. 症状:
ORA-15032: not all alterations performed ORA-15017: diskgroup "DATA" cannot be mounted

修复步骤:

dd if=/dev/zero of=/dev/asm_disk1 bs=1M count=100 asmcmd afd_scrub DATA

8. 高级调试技巧

8.1 诊断模式启动

当常规方法无法定位问题时:

crsctl start crs -excl -nocrs -debug

关键调试参数:

CRS_DEBUG=1 CRS_TRACE=1

8.2 核心转储分析

获取crsd进程的core dump:

gdb $GRID_HOME/bin/crsd core.12345 bt full info threads

8.3 跟踪文件解析

生成详细跟踪信息:

ALTER SYSTEM SET "_trace_events"='ksfd:1024' SCOPE=MEMORY;

分析工具:

tkprof crsd_ora_12345.trc output.txt sys=no sort=prsela

9. 性能优化建议

9.1 内存参数调整

对于大型Flex ASM集群:

-- 增加ASM实例内存 ALTER SYSTEM SET memory_target=4G SCOPE=SPFILE; -- 调整共享池大小 ALTER SYSTEM SET shared_pool_size=1G SCOPE=SPFILE;

9.2 I/O调度优化

修改磁盘调度算法:

echo deadline > /sys/block/sdb/queue/scheduler

9.3 网络缓冲区调整

优化集群通信:

sysctl -w net.core.rmem_max=4194304 sysctl -w net.core.wmem_max=4194304

10. 恢复演练方案

建议每季度执行以下演练:

  1. 模拟ASM实例崩溃
kill -9 $(pgrep -u grid asm_pmon)
  1. 验证自动恢复流程
crsctl check cluster -all
  1. 测量恢复时间指标
start_time=$(date +%s) crsctl start res ora.asm -n node1 end_time=$(date +%s) echo "Recovery time: $((end_time-start_time)) seconds"

在Flex ASM环境中,crsd进程的健康状态直接影响整个集群的可用性。通过这次故障排查,我总结了三点重要经验:第一,必须建立ASM元数据的定期备份机制;第二,Flex ASM环境需要更精细化的监控策略;第三,对于关键业务集群,建议配置至少3个ASM实例来确保冗余度。