LMT比DMT更稳定，因其用文件头位图替代SYS.UET$/SYS.FET$字典表，消除ST latch争用与递归SQL；需同时启用ASSM才能避免segment header争用。
Oracle本地管理表空间（LMT）比字典管理表空间（DMT）更稳定，根本原因在于它彻底移除了对数据字典表 SYS.UET$ 和 SYS.FET$ 的依赖——这两张表曾是高并发下 latch 争用和事务阻塞的“风暴眼”。
为什么 DMT 容易引发 latch 争用
每次分配或回收一个 extent，DMT 都必须：
- 申请
ST (space transaction)enqueue latch（全局串行锁） - 执行递归 SQL 更新
SYS.UET$（已用区）和SYS.FET$（空闲区） - 生成 UNDO 记录 + 重做日志（哪怕只是改一行字典）
- 触发一致性读、回滚段争用、甚至 enq: US - contention 等等待事件
在批量建表、大批量 INSERT 或并行 DDL 场景下，ST latch 成为单点瓶颈，数据库响应会明显抖动甚至挂起数秒。
LMT 如何绕过字典争用
LMT 把 extent 状态直接记在数据文件头部的位图中，操作变成纯内存+磁盘头的位翻转：
- 不查
SYS.UET$/SYS.FET$，无递归 SQL - 不更新任何数据字典表，不生成 UNDO
- 不依赖
STlatch，多个会话可并行修改不同位图区域 - 无需人工
ALTER TABLESPACE ... COALESCE合并碎片，位图自动识别连续空闲区
这意味着：即使在 100+ 并发建表场景下，latch: cache buffers chains 和 enq: US - contention 类等待几乎消失。
UNIFORM vs AUTOALLOCATE 对稳定性的隐性影响
虽然两者都属 LMT，但分配策略会影响位图更新频率和空间利用率：
-
UNIFORM SIZE 1M：位图更新节奏稳定，适合归档类只读表；但小对象插入会浪费空间，可能提前耗尽位图槽位 -
AUTOALLOCATE（默认）：首次用 64K，后续升到 1M/8M；好处是适应性强，坏处是频繁升降级会增加位图块的修改次数——尤其在大量短生命周期临时段（如排序、哈希连接）场景下 - 注意：
AUTOALLOCATE下PCTUSED、FREELISTS等参数被忽略，强行指定也无效
ASSM 是 LMT 稳定性的关键补丁，不是可选项
仅启用 LMT 不等于真正稳定。没开 SEGMENT SPACE MANAGEMENT AUTO 的 LMT 表空间，仍用传统 freelist 管理段内块，段头块（segment header）会成为新瓶颈：
- 高并发 INSERT 时，所有会话争抢同一个 segment header 块上的 freelist latch
- 这种争用在
dba_hist_active_sess_history中常表现为enq: TX - allocate ITL entry或latch: segment header - 只有同时开启 LMT + ASSM，才真正实现“表空间级 + 段级”双层去中心化管理
所以生产环境创建表空间，别只写 EXTENT MANAGEMENT LOCAL，漏掉 SEGMENT SPACE MANAGEMENT AUTO 就等于穿了防弹衣却忘了戴头盔。
