CONFIGURE ... CLEAR 仅清除显式配置项，不重置隐式行为或内置默认值；需结合 SHOW ALL 确认带*项后逐个清除，并注意RAC/Data Guard及恢复目录环境下的作用域限制。
CONFIGURE ... CLEAR 为什么有时不生效
执行 configure backup optimization on clear 这类命令后，发现参数没变回默认值，甚至查 show all 还显示旧配置——不是命令写错了，而是 rman 的“clear”只清除**显式配置项**，对 oracle 内置默认行为无影响。比如 configure retention policy to recovery window of 7 days 被 clear 后，rman 不会自动切回 redundancy 1，而是维持当前隐式策略（取决于控制文件中已有的备份记录状态）。
- 必须先确认该参数是否曾被显式设置过：运行
SHOW ALL，只看带*标记的行才是你设过的 -
CLEAR对未手动配置过的参数无效，它不会“重置”，只是“删掉你的那条覆盖规则” - 某些参数（如
DEVICE TYPE DISK PARALLELISM）CLEAR 后仍保留上次手工设置的并行度，需配合CONFIGURE DEVICE TYPE DISK PARALLELISM 1显式还原
哪些参数 CLEAR 后真能回到出厂默认
真正能靠 CLEAR 恢复默认的，仅限 RMAN 自身维护的、有明确内置值的配置项。典型如压缩算法、通道分配、备份优化开关等。但注意：默认值可能因 Oracle 版本而异（例如 12c+ 默认启用 BACKUP OPTIMIZATION，而 11g 默认关）。
-
CONFIGURE COMPRESSION ALGORITHM 'BASIC' CLEAR→ 回到版本默认压缩算法（19c 是LOW） -
CONFIGURE CONTROLFILE AUTOBACKUP OFF CLEAR→ 真实恢复为OFF（这是硬编码默认） -
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE CLEAR→ 清除后策略变为NONE，而非自动继承主库设置 - 别指望
CONFIGURE RETENTION POLICY CLEAR让 RMAN 忽略所有保留规则——它只会删掉你设的那条，但已有备份集仍受控于实际归档/备份状态
RESET DATABASE 和 CLEAR 的关键区别
有人误以为 RESET DATABASE 能清空所有 RMAN 配置，其实它只重置数据库在 RMAN 目录中的 **DB_KEY / DBINC_KEY**，和配置无关。真正要批量还原默认，得靠组合操作：
- 逐个 CLEAR 所有带
*的配置项（用SHOW ALL列出来再处理） - 对无法 CLEAR 的隐式行为（如 retention），用
CONFIGURE RETENTION POLICY TO REDUNDANCY 1显式覆盖 - 如果连控制文件里的历史配置都想清，只能重建控制文件或使用
DUPLICATE TARGET DATABASE TO ... NOREDO新建库（成本高，慎用） - 注意：
CLEAR命令本身不写入控制文件，直到下一次BACKUP或LIST类命令触发元数据刷新，才真正生效
容易被忽略的权限与环境陷阱
在 RAC 或 Data Guard 环境下，CLEAR 命令只作用于当前连接的实例，不会同步到其他节点。更隐蔽的是：如果你用恢复目录（recovery catalog），CLEAR 只改本地控制文件，目录里旧配置还留着，下次 RESYNC CATALOG 又会被拉回来。
- 在 catalog 模式下，必须先
CONNECT CATALOG，再执行CLEAR，否则改的只是 target 控制文件 - RMAN 连接时若用了
NO CATALOG模式，CLEAR生效快，但重启 RMAN 后，若控制文件被重建或恢复过，配置可能丢失 - 使用 OS 认证登录时，确保
rman target /连的是你想操作的那个实例（尤其 RAC 下） - 执行前最好先
LIST CONFIGURATION（12c+）或SHOW ALL截图存档，避免 CLEAR 过度导致备份策略失效
最麻烦的不是命令怎么写，而是搞不清某条配置到底是控制文件记的、还是目录记的、还是根本没生效——建议每次 CLEAR 后立刻 SHOW ALL 并对比前后输出，别信“应该清掉了”。
