rman压缩需同时满足企业版、显式配置configure compression algorithm 'basic'及as compressed backupset才生效;磁盘仅支持basic算法,设medium/high或标准版下均静默忽略;验证须查v$rman_backup_job_details中compression_ratio>1且output_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 才算数
压缩导致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命令返回了配置,就等于它真在起作用。











