不能用rm删除backup00.ocr等ocr自动备份文件，因其文件名和时间戳被硬编码进ocr元数据，crs启动时校验完整性与序列一致性；手动删除会导致ocrconfig -restore失败、报prot-16错误或crs启动异常。
oracle rac 不允许手动删除或清理 ocr 自动备份文件 —— 直接 rm 会导致后续 ocrconfig -restore 失败，甚至引发 crs 启动异常。
为什么不能用 rm 删除 backup00.ocr 等文件
OCR 物理备份由 Master Node 上的 crsd 进程自动管理，其文件名（如 backup00.ocr、day.ocr）和时间戳被硬编码进 OCR 内部元数据。CRS 启动时会校验这些文件的完整性与序列一致性。一旦你手动删掉某个中间备份（比如 backup01.ocr），ocrconfig -showbackup 可能仍显示它，但执行 ocrconfig -restore 时会报 PROT-16: Internal Error 或直接拒绝恢复。
- 备份列表不是“快照目录”，而是带版本链的恢复点索引
-
backup00.ocr永远指向最新有效备份，重命名或移动它会使整个链断裂 - 即使磁盘空间告急，也绝不能绕过
ocrconfig工具操作备份文件
ocrconfig -showbackup 显示的路径不等于可写位置
运行 ocrconfig -showbackup 返回的路径（例如 /u01/grid/crs/cdata/mycluster）只是当前 Master Node 的本地路径。该目录下所有备份文件仅存在于 Master Node，其他节点默认不可见 —— 这意味着：
- 你在 Node2 上执行
ls /u01/grid/crs/cdata/mycluster很可能看到空目录或旧内容 - 备份文件不会自动同步到共享存储，除非你显式用
ocrconfig -backuploc指向共享路径（如+DG_BACKUP或/shared/ocrbackups） - 若 Master Node 切换，新 Master 会继续往自己的本地路径写新备份，旧备份留在原节点 —— 这就是磁盘空间“悄悄涨满”的常见原因
真正安全的清理方式只有两种
Oracle 官方不提供“删除某几个备份”的接口，但可通过以下两个受控操作释放空间：
- 用
ocrconfig -backuploc <new_path></new_path>将后续备份重定向到有足够空间的位置（支持 ASM 磁盘组或 NFS 共享路径），例如：ocrconfig -backuploc +DG_BACKUP
执行后，新备份将写入 ASM，旧本地备份仍保留，但不再增长 - 触发一次人工逻辑导出并归档旧备份：
ocrconfig -export /shared/ocr_export_$(date +%Y%m%d).xml
然后手动rm本地backup*.ocr—— 注意：这仅在你已确认逻辑备份可用、且 CRS 正常运行时才可操作；删除后需立刻验证ocrconfig -showbackup是否刷新为新路径
最易被忽略的磁盘空间隐患点
很多人盯着 $GRID_HOME/crs/cdata/<cluster_name></cluster_name> 看剩余空间，却忘了 OCR 镜像盘（Mirror OCR）本身也占用同等容量，且 voting disk 和 OCR 若共存于同一 ASM 磁盘组（如 +DG_SYS），其冗余策略（NORMAL vs EXTERNAL）会显著影响实际占用。查清真实压力源，比盲目删文件重要得多：
- 运行
ocrcheck确认 Device/File Name 是否指向 ASM，再用asmcmd lsdg查该 DG 的USABLE_FILE_MB - 执行
crsctl query css votedisk看 voting disk 是否和 OCR 在同一磁盘组 - 若使用外部冗余 ASM，OCR 占用就是单份大小；若为正常冗余，则自动镜像两份 —— 这个差异常被误判为“备份占满磁盘”
