Oracle 19c RAC集群挂起主因是磁盘空间耗尽引发ASM写入失败、CRS状态更新中断及OCR/Voting Disk访问异常，需用du定位真实瓶颈目录（如$GRID_HOME/log、+ASM/trace等），再分用户（oracle/grid）、分节点、分组件执行adrci purge（-age单位为分钟），最后验证OCR与Voting Disk空间是否恢复。
oracle 19c rac集群挂起，大概率不是因为“日志满”直接导致进程崩溃，而是磁盘空间耗尽后引发连锁反应：asm磁盘组无法写入、crs资源无法更新状态、数据库实例无法生成trace或incident文件，最终表现为节点驱逐、ocr/voting disk访问失败、crsctl check crs 返回 crs-4638: oracle high availability services is online 但后续命令卡死。此时清理adrci日志只是止血，必须同步处理空间瓶颈本身。
确认真实瓶颈位置：别只盯着 /diag
很多DBA一看到磁盘告警就直奔 $ORACLE_BASE/diag，但RAC中真正压垮系统的往往是其他目录：
-
$GRID_HOME/log（尤其是grid/log/hostname/agent下的大量oraagent_oracle.trc）—— Grid Infrastructure代理日志暴涨很常见 -
$ORACLE_BASE/diag/asm/+asm/下的alert_+ASM*.log和 trace 文件 —— ASM实例异常时会高频写入 -
$ORACLE_BASE/diag/crs/hostname/crs/trace—— CRS守护进程自身日志，一旦出现资源争用或网络抖动，体积激增 -
$ORACLE_BASE/fast_recovery_area—— 若归档未及时备份或删除，可能占满整个挂载点
执行前先跑这行命令定位最大目录：du -sh $ORACLE_BASE/* $GRID_HOME/log 2>/dev/null | sort -hr | head -5
adrci清理必须分用户、分组件、分节点执行
RAC中没有“统一清理”这回事。用错用户或漏掉节点，等于白干：
- 清理
diag/rdbms/xxx/xxx（数据库实例日志）→ 必须用oracle用户，在每个数据库节点分别执行 - 清理
diag/asm/+asm/或diag/crs/hostname/crs→ 必须用grid用户，在每个集群节点分别执行 - 清理
diag/tnslsnr/hostname/listener（监听日志）→ 视监听归属：数据库监听用oracle，SCAN/SCAN Listener 通常属 Grid 层，用grid
典型操作示例（在 node1 上清理数据库实例日志，保留 7 天）：su - oracle -c "adrci exec 'set homepath diag/rdbms/orcl19c/orcl19c; purge -age 168 -type trace; purge -age 168 -type incident; purge -age 168 -type cdump'"
purge 命令的 -age 单位是分钟，不是小时
这是最常踩的坑。文档里写“720小时 = 30天”，但 adrci purge -age 的单位是**分钟**，不是小时。输错会导致误删或完全不生效：
- 保留 7 天 →
-age 10080（7 × 24 × 60） - 保留 30 天 →
-age 43200（30 × 24 × 60） - 保留 90 天 →
-age 129600
验证是否生效：清理后立即执行 adrci exec 'show homes; set homepath ...; show incident'，看输出的 create_time 是否都在你设定的时间阈值之后。
清理后必须检查 OCR 和 Voting Disk 空间是否恢复
即使 adrci purge 成功释放了几十GB，若 OCR 或 Voting Disk 所在的ASM磁盘组仍处于 DISKGROUP_FULL 状态，CRS不会自动恢复。需立刻检查：
-
ocrcheck—— 确认 OCR 状态为PROTECTED且无错误 -
crsctl query css votedisk—— 查看 voting disk 路径 -
asmcmd lsdg—— 检查对应磁盘组USABLE_FILE_MB是否 > 0
如果仍是负值，说明底层存储已满，仅清理诊断日志不够，得立刻归档压缩旧归档、迁移非关键数据，或扩容磁盘组。
