Oracle 19c 不具备自动识别并清理业务过期数据对应 Segment 的能力，仅支持对已显式删除/截断对象的物理空间回收，且依赖手动配置与操作。
oracle 19c 没有自动识别并清理“业务过期数据”对应的 segment 的能力——比如订单表里状态为 closed 且创建时间超过3年的记录，不会被任何内置任务自动 delete 或 truncate。所谓“自动清理 segment 空间”，仅指对已删除/截断对象的**物理空间回收**，且依赖显式配置和特定前提。
Automatic Segment Advisor 不等于自动删数据
很多人误以为 AUTOMATIC_SEGMENT_ADVISOR 会主动收缩或清理段，其实它只做两件事：扫描、建议。它不会执行 ALTER TABLE ... SHRINK SPACE，也不会触发 DROP 或 TRUNCATE。
- 它默认每晚在维护窗口运行，检查高水位线（HWM）上方空闲空间占比 > 10% 的段，并把建议写入
DBA_ADVISOR_FINDINGS - 真正释放空间必须人工执行收缩操作，例如：
ALTER TABLE sales SHRINK SPACE COMPACT - 若表未启用
ROW MOVEMENT，SHRINK会直接报错ORA-10636 - 索引需单独重建：
ALTER INDEX sales_idx REBUILD，否则仍指向旧位置
SM/ADVISOR 占用 SYSAUX 是“假膨胀”，不是可回收的 Segment
当 V$SYSAUX_OCCUPANTS 显示 SM/ADVISOR 占用巨大空间（如 10GB+），这不是因为临时段没释放，而是统计顾问任务历史输出堆积在 WRI$_ADV_OBJECTS 表中——这些是持久化元数据，不属于能被 SMON 清理的“临时段”。
- 确认是否由
AUTO_STATS_ADVISOR_TASK主导：SELECT task_name, COUNT(*) FROM dba_advisor_objects GROUP BY task_name ORDER BY 2 DESC - 停用该任务：
EXEC DBMS_STATS.DROP_ADVISOR_TASK('AUTO_STATS_ADVISOR_TASK') - 后续必须手动移动并重建表和索引，否则空间不释放：
ALTER TABLE WRI$_ADV_OBJECTS MOVE+ALTER INDEX ... REBUILD - 注意：
DROP_ADVISOR_TASK不会立即释放空间，只是阻止新数据写入
临时段（TEMP）不靠“自动任务”，靠 SMON 轮询与人为诱导
V$TEMPSEG_USAGE 里残留的 INACTIVE 记录，不是泄漏，也不是任务没跑完——SMON 每 5 分钟才轮询一次，且只合并相邻空闲 extent，不扫描业务逻辑。
- 不要查
dba_segments找临时段，它不在里面；看V$TEMP_SPACE_HEADER.FREE_BLOCKS才知真实可用块数 - 想让 SMON 尽快动作，可用：
ALTER TABLESPACE TEMP COALESCE（仅对 LMT 有效） - 避免误判：
V$SORT_SEGMENT.USED_EXTENTS = 0是已释放但字典未刷新的“幽灵段”，无法人工干预 - 分布式事务挂起（
DBA_2PC_PENDING非空）或长事务未提交时，SMON 会跳过对应临时段，必须先解决源头
真正需要人工介入的点，往往藏在“自动”二字背后：Advisor 不执行动作、SMON 不实时响应、SYSAUX 膨胀不可逆——所有“自动”都以显式配置为前提，且多数不处理业务语义上的“过期”。
