三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
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实例来确保冗余度。

编程学习 学习日记 实战经验
← 返回列表