非默认块大小表空间恢复必须显式指定BLOCKSIZE参数；RMAN默认按8K解析备份集，若不指定对应块大小（如4096），会导致RMAN-06023错误或静默跳过，且备份时未声明BLOCKSIZE将导致元数据不匹配，恢复失败。
非默认块大小表空间恢复必须显式指定BLOCKSIZE参数
RMAN默认按数据库默认块大小（通常是8K）解析备份集，遇到非默认块大小的表空间（如2K、4K、16K、32K），若不显式声明BLOCKSIZE，restore tablespace会报RMAN-06023或静默跳过对应数据文件。这是因为RMAN元数据中记录的块大小与控制文件中V$TABLESPACE.BLOCK_SIZE不匹配时，无法自动关联备份片。
实操建议：
- 先查清目标表空间实际块大小：
SELECT BLOCK_SIZE FROM V$TABLESPACE WHERE NAME = 'TS_4K'; - 确认备份集中是否含该块大小的数据文件：
LIST BACKUP OF TABLESPACE ts_4k;—— 注意输出中BSIZE列值是否匹配 - 恢复命令必须带
BLOCKSIZE子句：RESTORE TABLESPACE ts_4k BLOCKSIZE 4096;（单位为字节，不可写成4K） - 若用
RESTORE DATABASE连带恢复该表空间，同样需加BLOCKSIZE 4096，否则只恢复默认块大小部分
备份时未指定BLOCKSIZE会导致恢复失败
很多DBA在做BACKUP TABLESPACE ts_4k时忽略BLOCKSIZE参数，误以为RMAN能自动识别。实际上，RMAN在备份阶段就将块大小作为备份集元数据的一部分固化下来；如果备份时没声明，RMAN会按数据库默认块大小记录，后续RESTORE就找不到匹配项。
常见错误现象：
-
RMAN-06023: no backup or copy of datafile X found to restore，但LIST BACKUP明明显示有备份 - 备份集
LIST输出中BSIZE列为8192，而表空间实际是4096 - 用
VALIDATE BACKUPSET校验时提示block size mismatch
补救方法只有两个：重做一次带BLOCKSIZE的备份，或从归档日志+全库备份中手工重建该表空间（不推荐）。
混合块大小环境下的RECOVER必须保持BLOCKSIZE一致
RECOVER TABLESPACE本身不校验块大小，但它依赖RESTORE生成的数据文件物理结构。如果RESTORE阶段用了错误的BLOCKSIZE（比如把16K表空间误设为8K），RECOVER会成功执行但数据文件头损坏，OPEN时直接报ORA-01122或ORA-01200。
关键检查点：
- 恢复前确认
V$DATAFILE中该表空间对应文件的FILE#和NAME路径无误 - 恢复后、
ALTER TABLESPACE ... ONLINE前，运行：SELECT FILE#, BLOCK_SIZE FROM V$DATAFILE WHERE FILE# = X;验证块大小是否与表空间定义一致 - 若表空间跨多个PDB，注意每个PDB的
ts_name在RMAN中需写成pdb1:ts_4k，且BLOCKSIZE仍要单独指定
AUXILIARY实例恢复单表时BLOCKSIZE容易被忽略
用RECOVER TABLE恢复存于非默认块大小表空间中的表时，RMAN会自动创建AUXILIARY实例。这个实例默认使用目标库的db_block_size，如果源表空间是16K，AUXILIARY实例启动就会失败，报ORA-01092或ORA-00704。
必须显式在AUXILIARY DESTINATION路径下提供定制的初始化参数文件（pfile），其中包含：
*.db_block_size=16384 *.compatible='19.0.0' *.db_name='aux19c'
然后在RECOVER TABLE命令中引用该pfile：AUXILIARY DESTINATION '/u01/aux' PARFILE '/u01/aux/init_aux.ora'。漏掉这步，整个恢复流程会在第3步（创建辅助实例）卡住，且错误日志分散在trace目录里，不易定位。
最麻烦的不是命令写错，而是块大小不一致引发的隐性损坏——它可能让表看起来“恢复成功”，但第一次SELECT COUNT(*)就触发ORA-00600 [kcbz_check_objd_typ_3]。务必在ONLINE后立刻用DBVERIFY扫描对应数据文件。
