Oracle 19c中LMT是强制默认且唯一推荐模式，DMT已被彻底弃用；LMT通过数据文件头部位图管理extent，避免SYS.UET$/FET$争用和ST enqueue latch瓶颈，AUTOALLOCATE自适应分配，UNIFORM适合容量稳定场景，ASSM必须依附LMT以位图替代freelist解决段内争用。
本地管理表空间（LMT）在 Oracle 19c 中是强制默认且唯一推荐的模式，字典管理表空间（DMT）不仅已被弃用，而且在 10g 及以后版本中无法新建——如果你在 19c 里看到 DMT，只可能是从极老版本迁移遗留下来的。
为什么 LMT 能彻底避免 ST enqueue latch 竞争
字典管理依赖 SYS.UET$ 和 SYS.FET$ 两张数据字典表记录已用/空闲区（extent），每次分配或回收 extent 都要对这两张表执行 INSERT/UPDATE/DELETE。这些操作本质是递归 SQL，必须串行获取 ST（space transaction）enqueue latch，高并发 DML 下极易卡在这里。
LMT 把位图直接存在数据文件头部，分配一个 extent 只需翻转对应 bit，不走 SQL、不生成 undo、不写 redo（仅位图变更部分有少量 redo），自然绕开 latch 争用。
- DMT 场景下，100 个会话同时 insert 小行，可能排队等同一个
STlatch - LMT 下，只要位图没冲突（比如不同数据文件或不同位图区域），100 个会话可并行完成 extent 分配
EXTENT MANAGEMENT LOCAL 的两种分配策略怎么选
创建 LMT 时必须指定 extent 分配方式：AUTOALLOCATE（默认）或 UNIFORM SIZE n。二者影响的是 extent 初始大小和增长逻辑，不是性能高低问题，而是适用场景差异：
-
AUTOALLOCATE：Oracle 自动按需分配 64K/1M/8M/64M 等规格，适合对象大小差异大、无法预估增长节奏的通用业务表空间 -
UNIFORM SIZE 128K：所有 extent 固定大小，适合批量加载、日志类小对象密集场景，能减少位图碎片，但若对象实际需要远大于该 size，会频繁申请多个 extent
注意：UNIFORM 模式下，NEXT、PCTINCREASE 等存储参数被忽略；AUTOALLOCATE 下这些参数也无效——因为 extent 大小不由段定义控制。
ASSM 是 LMT 的增强，不是替代方案
SEGMENT SPACE MANAGEMENT AUTO 必须配合 EXTENT MANAGEMENT LOCAL 使用，它解决的是段（segment）内部块级空间管理问题，用位图替代 freelist，消除段头块争用。
常见误解是“开了 ASSM 就不用管 freelist 了”，但要注意：
- ASSM 表空间中，
PCTUSED、FREELISTS、FREELIST GROUPS参数会被完全忽略，硬写进去也不生效 - 如果应用依赖手动调优 freelist（比如旧版 OLTP 应用），迁移到 ASSM 前需验证热点块行为是否变化
- ASSM 在高并发小事务更新同一张表时，可能因位图更新产生新的争用点（如
enq: TX - allocate ITL entry），这不是 LMT 的问题，而是 ASSM 自身机制使然
真正容易被忽略的点是：SYSTEM 表空间在 19c 中必须是 LMT，一旦 SYSTEM 是 LMT，整个库就再也不能创建任何新的 DMT 表空间——哪怕你显式写 EXTENT MANAGEMENT DICTIONARY，Oracle 也会报错 ORA-12913: Cannot create dictionary managed tablespace。所以别试图“回退”，重点是确认遗留 DMT 表空间是否还有活动对象，再规划迁移。
