不能直接迁移非标准块表空间到标准块，必须通过expdp/impdp逻辑重建：先导出数据（content=data_only），再在目标库建标准块表空间，最后用remap_tablespace和transform=segment_attributes:n导入并验证块大小一致性。
不能直接“迁移”非标准块表空间到标准块——oracle 不允许修改已存在表空间的 blocksize，哪怕目标库 db_block_size 是 8k。你实际要做的，是把数据逻辑导出、重建到标准块表空间中。
为什么 ALTER TABLESPACE ... BLOCKSIZE 不生效
Oracle 表空间创建后，BLOCKSIZE 就固化在数据文件头和段结构里，没有对应 DDL 或系统视图支持修改。执行类似语句会直接报错 ORA-02231: missing or invalid option to ALTER TABLESPACE；试图用 ALTER SYSTEM SET db_block_size 更是无效——该参数只在建库时起作用，重启后仍回退，且改了会导致旧数据文件完全无法加载。
必须走 EXPDP/IMPDP 逻辑重建路径
这是唯一可行方式，核心是绕过物理块结构依赖，靠 Data Pump 提取行级数据再写入新结构：
- 源库导出时加
CONTENT=DATA_ONLY，跳过原表空间 DDL（避免导入时冲突） - 目标库提前建好标准块表空间（如
DB_BLOCK_SIZE=8192），并确保用户默认表空间指向它 - 导入时用
REMAP_TABLESPACE=OLD_TS:NEW_TS，强制所有对象落地到新表空间 - 别漏掉
TRANSFORM=SEGMENT_ATTRIBUTES:N，否则索引/LOB 段属性仍带原块大小信息，可能触发隐式转换失败
容易被忽略的缓存与兼容性陷阱
即使你成功导入，若源库曾启用 DB_16K_CACHE_SIZE 参数，而目标库没关干净，某些后台进程仍可能尝试加载 16K 缓存池，导致 v$sgastat 出现异常内存占用，甚至影响其他标准块操作：
- 检查目标库是否残留非标准块参数：
SELECT name, value FROM v$parameter WHERE name LIKE 'db_%k_cache_size'，若有非零值，需在 spfile 中设为 0 并重启 - 验证目标表空间真实块大小：
SELECT tablespace_name, block_size FROM dba_tablespaces WHERE tablespace_name = 'NEW_TS'，结果必须等于SELECT value FROM v$parameter WHERE name = 'db_block_size' - 导入后首次查询大表时观察执行计划：如果出现
TABLE ACCESS BY INDEX ROWID BATCHED但逻辑读远高于预期，可能是索引块未对齐标准缓存，需重建索引
真正耗时的不是命令执行，而是确认每个环节的块大小状态是否彻底剥离——尤其当源库混用多种块尺寸时，一个 DBA_TABLESPACES 查询漏看，就可能让应用在某张表上突然报 ORA-01410: invalid ROWID。
