RMAN SBT备份比磁盘备份快的根本原因是绕过操作系统文件I/O路径，由介质管理器卸载压缩加密、支持高并发且不依赖本地文件系统锁。
RMAN 管道备份（即通过 BACKUP ... FORMAT 'SBT_TAPE' ... 或配合介质管理器 SBT 接口）在某些场景下比直接写磁盘的文件备份更快，根本原因不是“管道本身快”，而是它绕开了操作系统级的文件 I/O 路径和本地磁盘瓶颈，把压力转移到了更专一、更可扩展的备份基础设施上。
管道备份实际走的是 SBT 接口，不是 Unix pipe
很多人误以为 backup ... format '/path/%u' 是“文件备份”，而 backup ... format 'oracle.sbt' 是“管道备份”——其实后者调用的是 oracle 的 sbt（system backup to tape）api，由第三方介质管理器（如 netbackup、commvault、oracle secure backup）或云存储适配器（如 oci object storage sbt）实现。它不经过 write() 系统调用，也不生成本地临时文件。
- 典型错误现象：监控
iostat -x 1发现磁盘 %util 持续 100%，但备份耗时长 → 说明瓶颈在本地磁盘吞吐或文件系统锁争用 - 使用
SBT后，iostat显示磁盘负载大幅下降，网络或专用备份网卡（如 10GbE 或 InfiniBand）成为主要 I/O 载体 -
v$backup_async_io中的TYPE字段会显示SBT而非DISK，确认走的是介质管理路径
并行度不受本地文件系统限制
本地磁盘备份受制于文件系统并发能力（比如 ext4 对单个目录的 inode 锁、XFS 的 AG 锁），尤其当多个 CHANNEL 写入同一挂载点时，容易出现 write contention。而 SBT 接口由介质管理器内部调度，通常支持数千并发流，且不依赖 OS 文件句柄。
- 常见错误：分配 8 个
CHANNEL到同一/u01/backup目录，实际并发写入只有 2–3 个线程有效 - 改用
SBT后，8 个通道能真正并行发起数据传输请求，介质管理器负责合并、分片、加密、上传 - 注意：必须在
ALLOCATE CHANNEL中显式指定DEVICE TYPE SBT，否则即使FORMAT写了'oracle.sbt'也会 fallback 到 disk
压缩与加密由介质管理器卸载
本地备份若启用 AS COMPRESSED BACKUPSET，压缩由 RMAN 进程内完成，吃 CPU；而主流 SBT 插件（如 NetBackup Accelerator、OCI SBT）支持硬件加速压缩/加密，在备份网关或存储端完成，RMAN 进程几乎零开销。
- 验证方式：对比
top -H -p $(pgrep -f "rman.*target")中线程 CPU 占用率 —— SBT 模式下通常 - 不推荐在 RMAN 里同时开
COMPRESSED+SBT，除非明确知道介质管理器不处理压缩（此时反而双重压缩浪费资源） - 部分云 SBT 实现（如 AWS S3 via sbt_host）默认启用 AES-256 加密，无需 RMAN 额外配置
SET ENCRYPTION ON
避免快速恢复区（FRA）空间争抢
当 DB_RECOVERY_FILE_DEST 和备份目标共用同一块盘时，归档日志切换、闪回日志写入、RMAN 备份三者会争夺 I/O 和空间。SBT 备份完全绕过 FRA，不占用 DB_RECOVERY_FILE_DEST_SIZE 配额，也不会触发 ORA-19809（超出 FRA 限制）。
- 典型场景：OLTP 系统每小时切 20GB 归档，FRA 设置为 100GB，RMAN 备份又占 50GB → 很快报错
- 改用 SBT 后，归档日志可直传至远程介质，FRA 只需保留最近 4 小时归档 + 控制文件快照即可
- 注意：
BACKUP ARCHIVELOG ALL DELETE INPUT在 SBT 模式下仍会先 copy 到 FRA 再 delete，除非加NOT BACKED UP n TIMES条件规避
