合规性审计只认recovery window，不认redundancy；必须满足rpo天数且确保归档连续、控制文件自动备份路径显式指定并验证、每次delete obsolete前人工核对report obsolete时间戳。
直接说结论：合规性审计不认“保留多少份”，只认“能恢复到哪一天”——必须用 recovery window，且窗口天数要 ≥ 审计要求的最短恢复点目标（rpo）。
为什么不能用 REDUNDANCY 满足合规审计
审计报告要的是可验证的时间点恢复能力，比如“系统必须支持回退至过去 90 天内任意时间点”。REDUNDANCY 3 只保证每个数据文件有 3 份全备，但若这 3 份之间间隔 60 天，中间归档日志又没保留，实际只能恢复到 3 个离散时间点——这不满足“任意时间点”要求，审计会直接否决。
-
RECOVERY WINDOW是唯一能反向推导出完整恢复链的策略：RMAN 会检查全备 + 增量 + 归档日志是否构成连续时间线 - 审计人员会查
REPORT OBSOLETE输出，再比对LIST BACKUP BY TIME中最早可用备份的时间戳，验证是否真能覆盖要求窗口 - 设成
REDUNDANCY后，即使你手动保留了归档，RMAN 也不会把它们纳入恢复链判断，REPORT OBSOLETE结果不可信
RECOVERY WINDOW 配置必须同步校验归档完整性
配了 RECOVERY WINDOW OF 90 DAYS 不等于真能恢复 90 天前。RMAN 静默降级：如果某段归档日志缺失，它就自动缩短实际可恢复窗口，但不报错、不警告。
- 执行前先确认归档模式已开：
SELECT log_mode FROM v$database必须返回ARCHIVELOG - 检查归档日志是否真实连续：
LIST ARCHIVELOG ALL看是否有 GAP（如序列号跳变），再用CROSSCHECK ARCHIVELOG ALL同步控制文件状态 - 禁用任何定时
DELETE ARCHIVELOG脚本——这类脚本常按“7天前”硬删除，直接破坏恢复链 - 若用 FRA，确保
DB_RECOVERY_FILE_DEST_SIZE≥ 数据库日均归档量 × 90 × 1.5（留缓冲）
控制文件自动备份路径必须显式指定，否则审计不认可元数据可信度
19c 默认开启 CONTROLFILE AUTOBACKUP，但若没配 FORMAT，备份会写入 FRA；而新库的 FRA 往往权限不对或未初始化，导致控制文件静默备份失败——审计时拿不出最近 90 天内的控制文件备份，直接判定备份体系失效。
- 必须执行：
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/rman/cf_%F' - 路径需独立于 FRA，且目录存在、Oracle 用户有写权限（
ls -ld /backup/rman确认） - 每次
BACKUP DATABASE后，立刻验证控制文件备份生成：LIST BACKUP OF CONTROLFILE - 审计材料里要提供近 90 天内至少 3 次控制文件备份的
LIST截图，证明元数据持续可追溯
别跳过 CROSSCHECK 和 REPORT OBSOLETE 的人工核对环节
合规审计不是看配置命令，而是看“删了什么”和“为什么能删”。直接跑 DELETE OBSOLETE 属于高风险操作，一旦误删关键备份，恢复链断裂，审计项直接不合格。
- 每次清理前必做：
CROSSCHECK BACKUP（同步磁盘真实状态）→REPORT OBSOLETE（输出待删列表） - 人工核对
REPORT OBSOLETE中最老的全备时间戳，确认它仍在窗口内（例如当前是 2026-06-24，窗口 90 天，则最老全备不能早于 2026-03-26） - 若发现最老全备已超窗，说明备份频率不足，需立即补做全备，而非删旧备
- 所有
REPORT OBSOLETE输出、LIST BACKUP SUMMARY结果、CROSSCHECK日志，都需存档 90 天以上供审计抽查
真正卡住合规落地的，从来不是配置命令本身，而是归档日志的实际连续性、控制文件备份的真实存在性、以及每次 DELETE OBSOLETE 前的人工交叉验证记录——这三处任一缺失，审计报告都会打回来重做。
