Oracle 11g中如何调整RMAN的Block Size以匹配存储特性

_BLKSIZE 不控制物理 I/O 块大小，仅影响 RMAN 内部缓冲区；盲目调大易导致非对齐读写和性能下降，因其受 ASM AU、存储条带、OS 调度器等多重约束，且 11gR2+ 默认忽略全局设置，必须在 ALLOCATE CHANNEL 时显式指定才生效。

_blksize 参数不是直接控制物理 i/o 块大小的开关，盲目调大反而引发非对齐读写和性能下降。

为什么 SET _BLKSIZE=1048576 没效果甚至更慢

RMAN 的 _BLKSIZE 仅影响其内部缓冲区单位，不等于下发给存储的物理块。真实 I/O 大小由 DB_FILE_MULTIBLOCK_READ_COUNT × DB_BLOCK_SIZE 与底层驱动协商决定，受 ASM AU、存储条带（stripe unit）、OS I/O 调度器共同约束。若存储条带为 64KB，却设 _BLKSIZE=1MB，每次读写会跨多个条带，产生大量非对齐 I/O 和内部碎片。

Oracle 11gR2+ 默认忽略全局 SET _BLKSIZE，除非显式启用 SET COMMAND ID 或在 ALLOCATE CHANNEL 中透传。

• 常见误操作：执行 CONFIGURE DEVICE TYPE DISK PARALLELISM 4 后直接 SET _BLKSIZE=1048576，但未绑定到具体 channel，该设置完全不生效
• 11gR2 对 DISK 类型不支持在 ALLOCATE CHANNEL 中用 PARMS 传 _BLKSIZE；仅 SBT 通道可通过 PARMS='ENV=(_BLKSIZE=262144)' 强制透传

怎么查清你的存储条带和 ASM AU 是否匹配

不查清底层，调 _BLKSIZE 就是蒙眼调参。重点看三处：

• 查 ASM 磁盘组：运行 SELECT name, allocation_unit_size, sector_size FROM v$asm_diskgroup —— 其中 allocation_unit_size（通常为 1MB）才是 ASM 对齐的最小单元，_BLKSIZE 应为其整数分之一（如 128KB、256KB）或整数倍（需配合 MAXPIECESIZE 控制）
• 查底层存储条带：对裸设备或 LUN，用 dd if=/dev/zero of=/tmp/test bs=64k count=1000 oflag=direct + iostat -x 1 观察 avgrq-sz，若长期偏离 128 或 256（单位扇区，512B），说明上层未对齐
• 查当前备份通道实际 I/O 行为：备份过程中执行 SELECT event, p1text, p1 FROM v$session_event WHERE sid IN (SELECT sid FROM v$session WHERE program LIKE '%rman%') AND event LIKE 'direct path%'，观察 p1（物理块大小，单位 OS block）是否接近你设的 _BLKSIZE

RMAN channel 级别强制对齐的实操写法

全局 SET _BLKSIZE 不可靠，必须在分配 channel 时显式控制。注意版本差异：

• 11gR2：DISK 类型无法在 ALLOCATE CHANNEL 中设 _BLKSIZE；只能对 SBT 通道用 PARMS='ENV=(_BLKSIZE=262144)'（值必须是 512B 整数倍，且 ≤ MAXPIECESIZE/8）
• 所有版本都禁止在 CONFIGURE CHANNEL 中配置 _BLKSIZE，它会被忽略
• 真正起效的写法是：ALLOCATE CHANNEL c1 DEVICE TYPE DISK MAXPIECESIZE 2G; 配合合理设置 DB_FILE_MULTIBLOCK_READ_COUNT（例如 AU=1MB 时设为 128，对应 128×8K=1MB）

最易被忽略的一点：_BLKSIZE 的数值意义只在 channel 分配那一刻生效，且仅对后续该 channel 执行的 backup 命令有效；一旦 channel 释放，设置即丢失。生产环境务必把对齐逻辑固化进 RMAN 脚本的 ALLOCATE CHANNEL 步骤里，而不是依赖全局 SET。