DB_BLOCK_SIZE不可在线修改，必须重建数据库；非标准块表空间需先配置对应DB_16K_CACHE_SIZE等参数并重启实例，否则缓存未生效将导致性能下降。
DB_BLOCK_SIZE 不能在线修改，必须重建数据库
oracle 实例级参数 db_block_size 一旦数据库创建完成，就无法通过 alter system 修改——不是权限不够，是底层数据文件结构强绑定块大小，改了就彻底读不了老数据。你看到的“修改成功”只是内存生效，重启后回滚，或直接报 ora-00722: invalid parameter。
真正可行的路径只有一条：导出数据 → 用新 DB_BLOCK_SIZE 重建数据库 → 导入。注意：这和“添加非标准块表空间”完全不是一回事，别被名字误导。
非标准块表空间（如 16K、32K）需要先配 DB_CACHE_SIZE 子池
想建 BLOCKSIZE 16K 的表空间？光写 CREATE TABLESPACE ... BLOCKSIZE 16384 不够。Oracle 要求对应尺寸的缓存池必须已存在且启用，否则报 ORA-29339: block size 16384 does not match any of the database block sizes。
实操要点：
- 确认
DB_BLOCK_SIZE是 8K（最常见），再设非标准块时，必须显式配置DB_16K_CACHE_SIZE（或DB_32K_CACHE_SIZE）参数，值不为 0 - 该参数只能在
spfile中设，且需重启实例才生效；ALTER SYSTEM SCOPE=SPFILE后必须重启 - 如果用的是 AMM（
MEMORY_TARGET），Oracle 会自动分配子池，但前提是总内存足够，否则仍会失败
CREATE TABLESPACE BLOCKSIZE 的实际使用场景很窄
非标准块表空间不是性能银弹。它主要解决两类问题：超大行（如含多个 BLOB 字段）导致单块放不下，或 OLAP 场景下减少物理 I/O 次数。但代价明显：
容易踩的坑：
- 索引、LOB、物化视图等对象若跨表空间存放，可能因块大小不一致引发隐式转换或访问异常
- RMAN 备份/恢复对混合块大小支持完整，但 Data Pump 导入时若未指定
REMAP_TABLESPACE，容易把对象建到默认块大小表空间，丢失预期 - 某些旧版 Oracle 客户端（如 11g R1 JDBC thin driver）连接含非标准块表空间的库时，偶发
ORA-03113: end-of-file on communication channel
验证非标准块表空间是否真生效
建完别急着用，先查两处：
SELECT tablespace_name, block_size FROM dba_tablespaces WHERE block_size != (SELECT value FROM v$parameter WHERE name = 'db_block_size');
再看缓存是否加载：
SELECT name, bytes FROM v$sgastat WHERE pool = 'DEFAULT' AND name LIKE '%16K%';（若建的是 16K）
如果第二条没结果，说明 DB_16K_CACHE_SIZE 没生效，表空间虽建成功，但所有读写都会 fallback 到 default buffer cache，性能反而更差。
块大小这事，不是设了就等于用了。缓存池没起来，等于路修好了但没通水。
