\_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。
