Oracle 19c中CREATE TABLESPACE必须显式声明EXTENT MANAGEMENT LOCAL，虽默认为本地管理但省略会报ORA-02165错误；字典管理已禁用，EXTENT MANAGEMENT类型创建后不可更改。
CREATE TABLESPACE 时默认就是 LOCAL，但必须显式声明
oracle 19c 中，新建永久表空间（permanent）默认采用本地管理（local），但语法上**不允许省略 extent management local 子句**。如果漏写，会报错 ora-02165: invalid option for create tablespace。
原因在于：虽然底层逻辑已强制本地化，但 Oracle 仍要求显式声明，以避免与过时的字典管理（DICTIONARY）混淆——后者在 19c 中已完全禁用（ORA-12913 错误）。
-
EXTENT MANAGEMENT LOCAL是强制语法项，不可省略 - 不支持
EXTENT MANAGEMENT DICTIONARY，哪怕加了也会直接报错 - 若未指定
AUTOALLOCATE或UNIFORM SIZE，默认启用AUTOALLOCATE
查询已有表空间是否为 LOCAL 管理
用 dba_tablespaces 查看 EXTENT_MANAGEMENT 列即可确认，值为 LOCAL 即表示本地管理。
常见误判点：有人查 SEGMENT_SPACE_MANAGEMENT（是 ASSM/MSSM，管的是段内块分配），它和 EXTENT_MANAGEMENT 完全无关。
- 执行：
SELECT tablespace_name, extent_management FROM dba_tablespaces; - 系统表空间（如
SYSTEM、SYSAUX）和用户表空间在 19c 中均为LOCAL -
UNDOTBS1和TEMP表空间也一定是LOCAL，且ALLOCATION_TYPE固定为SYSTEM（即AUTOALLOCATE）
AUTOALLOCATE vs UNIFORM：选哪个取决于对象大小分布
AUTOALLOCATE 是默认策略，由 Oracle 自动选择 64K/1M/8M/64M 等 extent 大小；UNIFORM SIZE 强制所有 extent 等大（如 UNIFORM SIZE 1M）。二者不能混用，且一旦建好无法修改（需重建表空间）。
- 适合
AUTOALLOCATE的场景：表空间中对象大小差异大（既有小表也有大分区表）、DBA 不想干预空间细节 - 适合
UNIFORM的场景：临时表空间（TEMP必须用）、预估空间使用极精确、需避免小 extent 碎片（如 OLTP 核心业务表空间） -
UNIFORM在UNDO表空间中不被允许——会报ORA-30013 -
UNIFORM SIZE若不指定，默认为1M；但若DB_BLOCK_SIZE=8K，实际分配单位仍是整数倍块数（如 128 块 = 1M）
ALTER TABLESPACE 不能修改 EXTENT MANAGEMENT 方式
表空间创建后，EXTENT MANAGEMENT 类型不可更改。既不能从 LOCAL 改成 DICTIONARY（语法禁止），也不能反向迁移（DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL 在 19c 中对普通表空间已失效，仅限特殊兼容场景）。
真正需要“切换”的唯一情况是：极老数据库升级后遗留字典管理表空间（ORA-12913 提示你根本建不出新的字典表空间）。此时必须导出数据 → 新建本地管理表空间 → 导入。
-
ALTER TABLESPACE ... EXTENT MANAGEMENT LOCAL是非法语法，会报ORA-02231 -
DBMS_SPACE_ADMIN包中的迁移过程在 19c 中仅对SYSTEM表空间在受限模式下有理论支持，但生产环境严禁尝试 - 确认方式只有建库时指定或新建时显式声明——没有运行时补救路径
本地管理不是“可选项”，而是 19c 的刚性事实；真正的操作分水岭其实在 AUTOALLOCATE 和 UNIFORM 之间——这个选择一旦落地，就锁死了 extent 分配行为，后续无法调整，得提前想清楚。
