Oracle 19c TEMP表空间强制本地管理，不支持字典管理，ALTER TABLESPACE ... EXTENT MANAGEMENT DICTIONARY会报ORA-12913；其空间分配依赖位图而非数据字典，真实可用空间需查v$temp_space_header.free_blocks，重建TEMP必须用CREATE TEMPORARY TABLESPACE。
oracle 19c 的 temp 表空间默认就是本地管理（lmt），所谓“推荐设置”其实是误解——它不支持字典管理，根本没法选。
为什么 ALTER TABLESPACE ... EXTENT MANAGEMENT DICTIONARY 在 TEMP 上会报错
执行 ALTER TABLESPACE temp EXTENT MANAGEMENT DICTIONARY 会直接失败，报 ORA-12913: Cannot create dictionary managed tablespace。因为从 Oracle 10g 起，临时表空间强制使用本地管理，数据库内核已移除对字典管理 TEMP 的支持逻辑。这不是配置建议，而是硬性限制。
本地管理 TEMP 的实际好处只体现在底层机制上
- 临时文件（
tempfile）的 extent 分配由文件头的位图控制，不依赖sys.fet$或sys.uet$等数据字典表 —— 所以不会产生额外的 dictionary latch 争用 - 排序操作分配临时段时跳过数据字典更新，减少 redo/undo 生成（TEMP 表空间本身也不写 redo，但本地管理进一步削减了内部开销）
- SMON 不负责回收 TEMP 的空闲 extent，但位图管理让新分配更轻量；高位 extent 占用后不自动收缩，是设计使然，和是否本地管理无关
容易被忽略的关键事实：DBA_TEMP_FILES 不反映真实可用空间
很多人查 DBA_TEMP_FILES.bytes 发现还有 20GB，却频繁遇到 ORA-01652: unable to extend temp segment。真正决定能否分配新临时段的是 v$temp_space_header.free_blocks：
SELECT tablespace_name, round((free_blocks * block_size) / 1024 / 1024) free_mb FROM v$temp_space_header;
这个值接近 0 时，哪怕 DBA_TEMP_FILES 显示文件很大，也会立即报错。位图里没有连续空闲块，本地管理就无法分配新 extent —— 这不是 bug，是本地管理在 TEMP 场景下的必然表现。
重建 TEMP 表空间时，本地管理是唯一路径
当 v$temp_space_header.free_mb 耗尽且确认无活跃会话时，必须重建：
- 新建语句必须用
CREATE TEMPORARY TABLESPACE，隐式启用本地管理，无需、也不能加EXTENT MANAGEMENT LOCAL -
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE new_temp切换后，旧 TEMP 仍被已有会话持有，需等所有会话断开或 kill 掉残留v$sort_usage记录 - 旧 TEMP 删除前，务必验证
SELECT * FROM v$sort_usage WHERE tablespace_name = 'OLD_TEMP'返回空集
临时文件不 shrink、不 auto-shrink、不回收高位 extent —— 本地管理让这些行为成为确定性事实，而不是配置选项。接受它，比试图绕过它更可靠。
