开启block change tracking（bct）可大幅提升增量备份效率，alter database enable block change tracking需sysdba权限且路径不能为nfs/asm；rman压缩建议禁用或选'basic'；显式allocate channel rate比parallelism更可控；虚拟环境中需绕过i/o减速带并调整配置。
开启Block Change Tracking加速增量备份
全库备份本身不走BCT，但如果你的备份策略是“0级 + 后续1级”，那么1级备份速度直接决定整体窗口——而BCT能让1级从扫描全文件变成读一个小位图文件。实测11g+版本开启后，1级耗时下降60%~80%，相当于把整个备份周期压缩了一大截。
-
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/oradata/PROD/bct_file.f'必须用SYSDBA权限执行，且数据库处于OPEN或MOUNT状态 - 路径不能是NFS或ASM，否则报
ORA-19721；建议单独挂SSD小盘，避免和数据文件争I/O - 启用后务必验证：
SELECT STATUS, FILENAME FROM V$BLOCK_CHANGE_TRACKING，只有STATUS = 'ENABLED'才算真正生效 -
BACKUP INCREMENTAL LEVEL 1 DATABASE才触发BCT；LEVEL 0或带NOT BACKED UP SINCE TIME的语法会绕过它
禁用或降级COMPRESSION ALGORITHM
RMAN默认启用压缩（尤其11g+），但CPU密集型压缩常成为瓶颈：‘MEDIUM’比‘BASIC’CPU开销翻倍，‘HIGH’可能让单核吞吐跌破10MB/s。当磁盘读速已逼近上限（如SATA实测220MB/s），压缩反而拖慢整体节奏。
- 若无强压缩需求，直接关掉：
CONFIGURE COMPRESSION ALGORITHM 'NONE' - 若必须压缩，选
'BASIC'（11g默认）或'LOW'；避免'MEDIUM'和'HIGH' - 验证是否生效：
SELECT * FROM V$RMAN_CONFIGURATION WHERE NAME = 'COMPRESSION ALGORITHM' - 注意：
BACKUP DURATION ... MINIMIZE LOAD对压缩环节完全无效，别指望它降CPU
显式ALLOCATE CHANNEL + RATE限速
盲目加通道数量（PARALLELISM）常适得其反：I/O已达瓶颈时，多通道只会加剧latch: cache buffers chains争用和调度抖动。真正可控的是单通道写入速率——它能稳住CPU、降低上下文切换、缓解缓冲区压力。
- 在
RUN块内显式分配：ALLOCATE CHANNEL c1 DEVICE TYPE DISK RATE 15M（从10–20 MB/s起步） - 切忌在
CONFIGURE CHANNEL里设RATE，否则CROSSCHECK、DELETE OBSOLETE等日常命令也被拖慢 - 大文件（>50GB）必须配合
SECTION SIZE，否则RMAN强制串行读，其余通道干等：BACKUP DATAFILE 1 SECTION SIZE=200M - 每开一个通道，务必紧跟
RELEASE CHANNEL c1，避免空转进程持续消耗CPU周期
绕过虚拟层I/O减速带
在VMware、KVM等虚拟环境中，RMAN要经过Guest OS → Hypervisor → 存储控制器三层路径，任意一层缓存策略或资源争用都会拉低吞吐。物理机上有效的参数，在虚拟机里可能失效甚至起反作用。
- 确认磁盘直写：ESXi检查
scsi0:0.writeThrough = "TRUE"；KVM用cache=none而非cache=writeback -
db_recovery_file_dest必须指向本地ASM或直连PV SCSI设备，不能是NFS/CIFS共享路径 - channel并发数 ≤ 可用vCPU × 1.2（留余量），例如4 vCPU就设
PARALLELISM 4，而非盲目设8 - 压缩算法改用
'MEDIUM'（虚拟环境特有平衡点），BACKUP OPTIMIZATION建议关闭，避免hypervisor层元数据不一致
实际调优中，最容易被忽略的是CONFIGURE CHANNEL的隐式驻留行为——它会让所有RMAN操作（包括日常维护）自动分配通道并长期占用PGA。真正的控制权，始终在你显式写的ALLOCATE和RELEASE之间。
