RMAN压缩需同时满足企业版、显式配置CONFIGURE COMPRESSION ALGORITHM 'BASIC'及AS COMPRESSED BACKUPSET才生效；磁盘仅支持BASIC算法，设MEDIUM/HIGH或标准版下均静默忽略；验证须查V$RMAN_BACKUP_JOB_DETAILS中COMPRESSION_RATIO>1且OUTPUT_BYTES_DISPLAY<INPUT_BYTES_DISPLAY。
压缩没变小、CPU飙高、备份卡住——不是RMAN不行，是配置没对齐。
为什么AS COMPRESSED BACKUPSET不压缩
写了这个关键字，不代表真压缩。RMAN只把它当“愿望清单”，真正干活的是CONFIGURE COMPRESSION ALGORITHM。磁盘备份（DEVICE TYPE DISK）只认'BASIC'，设成'MEDIUM'或'HIGH'会被静默忽略，连报错都没有。
- 先查当前生效算法：
SHOW COMPRESSION ALGORITHM;—— 如果不是'BASIC'，立刻重配 - 企业版才支持压缩；标准版下哪怕配了
'BASIC'也会跳过，不提示 - NFS/ZFS等文件系统级压缩开启时，
OUTPUT_BYTES_DISPLAY可能看不出变化，但底层I/O已减少，建议关掉上层压缩单独验证 - 验证是否真压缩，别看.bkp文件大小，执行：
SELECT INPUT_BYTES_DISPLAY, OUTPUT_BYTES_DISPLAY, COMPRESSION_RATIO FROM V$RMAN_BACKUP_JOB_DETAILS WHERE START_TIME > SYSDATE - 1/24;——COMPRESSION_RATIO > 1.0且OUTPUT_BYTES_DISPLAY < INPUT_BYTES_DISPLAY才算数
压缩导致CPU持续95%怎么办
CPU高不是因为“太慢”，而是磁盘读 + 归档扫描 + 压缩计算三者在争抢资源。调DURATION或加通道数量基本没用，反而加剧调度抖动。
- 最有效动作：把算法降级或关闭。
CONFIGURE COMPRESSION ALGORITHM 'NONE';或'BASIC'（比'MEDIUM'省一半CPU） - 别在
CONFIGURE CHANNEL里设RATE，它会影响所有RMAN操作（包括CROSSCHECK）。改在RUN块里显式声明：ALLOCATE CHANNEL c1 DEVICE TYPE DISK RATE 15M; - 从10–20 MB/s起步，配合
iostat -x 1观察%util是否回落至70%以下；配完立刻RELEASE CHANNEL c1 - 单个数据文件>50GB时，必须加
SECTION SIZE，否则其余通道全程空转，CPU却还在干校验、内存拷贝这些活
MAXOPENFILES在磁带备份中设多大
磁带不是磁盘，MAXOPENFILES设高了不是提速，是触发MML拒绝连接（常见报错：RMAN-03009 + ORA-19554）。这不是RMAN错，是介质管理器（如NetBackup）侧协商失败。
- 合理值通常为4，且必须≤
PARALLELISM，否则通道会卡死 - 它受三重硬约束：MML单客户端最大流数（查
bp.conf里的NUMBER_OF_STREAMS）、物理驱动器数量（1台最多撑2–3流）、PGA内存（每+1个open file多占~1MB） - 实操写法必须在
RUN块内显式分配：allocate channel c1 device type sbt parms 'ENV=(NB_ORA_CLASS=RMAN_PROD)' maxopenfiles 4; - 典型错误：
PARALLELISM 6但只allocate了2个channel，每个maxopenfiles 8→ 2个channel全卡住，剩下4个并行度彻底浪费
自动控制文件备份为什么总失败
CONFIGURE CONTROLFILE AUTOBACKUP ON只是打开开关，路径不对、权限不够、RAC没走共享路径，备份就静默消失，日志里都不留痕迹。
- 必须显式指定格式路径：
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/shared/backup/%F';——%F不可省，它展开为c-DBID-YYYYMMDD-SS格式 - RAC环境路径必须所有节点可读写（ASM或NFS），不能用
/u01/backup这种本地路径 - 自动备份只在三类事件后触发：
BACKUP/COPY成功、ARCHIVELOG切换、OPEN RESETLOGS；SWITCH LOGFILE或CREATE TABLESPACE不会触发 - 生成的
%F文件不参与DELETE OBSOLETE，得单独监控清理，否则FRA迟早爆满报ORA-19809
压缩本身不难，难的是让每个环节都对齐：算法匹配设备类型、CPU负载让位于I/O瓶颈、磁带参数服从MML物理限制、自动备份依赖路径而非开关。最容易被忽略的，是以为SHOW命令返回了配置，就等于它真在起作用。
