oracle已彻底弃用dmt，9.2起禁止创建，lmt通过位图管理消除字典争用，assm进一步解决段头块瓶颈；uniform适合容量稳定场景，autoallocate为默认且自适应扩展。
dmt 已被 oracle 彻底弃用，连创建语句都会报错
oracle 从 9.2 版本起就禁止创建新的字典管理表空间（dmt），哪怕你显式写上 extent management dictionary，也会直接报 ora-12913: 无法创建字典管理的表空间。这不是配置问题，是硬性限制——除非你在初始化数据库时把 system 表空间设为 dmt（极罕见且不推荐），否则整个库都进不了 dmt 生态。
-
SYSTEM表空间一旦是本地管理（LMT），其他任何表空间都不可能回退到 DMT 模式 - 用
DBCA创建的临时表空间，即使界面上选了“字典管理”，实际查dba_tablespaces仍是LOCAL - 试图对已有 LMT 库执行
ALTER TABLESPACE ... EXTENT MANAGEMENT DICTIONARY？语法不支持，直接报错
LMT 的位图管理到底省了什么开销
本地管理表空间（LMT）把空间分配状态记在数据文件头部的位图里，而不是去查 SYS.UET$ 和 SYS.FET$ 这两个数据字典表。这意味着：
- 每次分配或释放一个
extent，不再触发递归 SQL，也不需要更新数据字典表，自然没有UNDO记录 - 高并发建表、大批量插入时，不会在
UET$/FET$上出现热块争用（latch: cache buffers chains或enq: US - contention类等待） - 不用定期执行
ALTER TABLESPACE ... COALESCE合并空闲碎片——位图自己能识别连续空闲区段
简单说：LMT 把「查字典 → 加锁 → 改字典 → 写 UNDO」这整条链路砍掉了，只做一次数据文件头的位翻转。
UNIFORM vs AUTOALLOCATE：两种 extent 分配策略怎么选
LMT 支持两种空间分配方式，直接影响后续对象的空间行为：
-
UNIFORM SIZE 1M：所有 extent 固定大小，适合预估容量稳定、I/O 均匀的场景（如历史归档表）。但若插入大量小记录，容易浪费空间 -
AUTOALLOCATE（默认）：由 Oracle 自动选择 64K/1M/8M 等大小，适应不同段增长节奏。但首次分配小 extent 后，后续可能因频繁扩展引发更多位图更新
注意：AUTOALLOCATE 下无法再设置 PCTUSED、FREELISTS 等参数——这些是 DMT 时代的遗物，LMT + ASSM 下全由位图 freelist 自动接管。
ASSM 是 LMT 的增强，不是替代；没开 ASSM 的 LMT 仍算“半残废”
SEGMENT SPACE MANAGEMENT AUTO（即 ASSM）必须依附于 LMT，但它解决的是段内空间管理问题，和表空间级的 extent 管理是两层事。没开 ASSM 的 LMT 表空间，虽然避免了字典争用，但段头块（segment header）仍会成为高并发 INSERT 的瓶颈。
- 开启 ASSM 后，段内空闲空间用位图管理，取代传统单向 freelist 链表，大幅降低段头块争用（
enq: TX - allocate ITL entry或buffer busy waits减少） - 创建表空间时不显式指定
SEGMENT SPACE MANAGEMENT AUTO，默认就是它（Oracle 10g+）；但迁移老库时可能遗留MANUAL模式，需手工ALTER TABLESPACE ... SEGMENT SPACE MANAGEMENT AUTO - 一旦启用 ASSM，就不能再为表或索引指定
FREELIST GROUPS、PCTUSED—— 参数会被忽略，还可能报ORA-1134警告
真正容易被忽略的点是：很多 DBA 看到表空间是 EXTENT MANAGEMENT LOCAL 就以为万事大吉，却没确认 SEGMENT SPACE MANAGEMENT 是否为 AUTO，结果高并发写入时段头块依然卡死。
