在 Oracle RMAN 性能调优实践中，隐藏参数 _BLKSIZE 经常被误读。不少人将其视作控制物理 I/O 块大小的“总开关”，不假思索地将数值调高至 1MB，结果备份性能反而下降。这背后真正的机制是什么？一句话总结：_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观察a vgrq-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 命令。
