Oracle 19c表空间无“自动优化”，仅支持自动索引（AUTO_INDEX_MODE）和SYSAUX组件自动清理；LMT默认启用extent自动管理，SEGMENT SPACE MANAGEMENT AUTO亦默认开启；SYSAUX空间告警需查V$SYSAUX_OCCUPANTS并针对性清理AWR、统计信息或审计数据。
oracle 19c 的表空间本身不支持“自动优化”——所谓“自动优化”是误传，真正可启用的是自动索引（auto_index_mode）和 sysaux 表空间内组件的自动清理策略，而非表空间层级的空间分配或收缩。
为什么查不到 AUTO_SPACE_MANAGEMENT 这类参数
因为 Oracle 从 10g 起就已废弃字典管理表空间（DMT），默认全部使用本地管理表空间（LMT），而 LMT 的区（extent）管理方式天然就是“自动”的。你执行 CREATE TABLESPACE 时不加 EXTENT MANAGEMENT DICTIONARY，就已是自动管理。所谓“新版本自动优化”不是新增一个开关，而是指：
-
SEGMENT SPACE MANAGEMENT AUTO（默认启用，用位图管理空闲块，无需手动ALTER TABLE ... MOVE整理） - SYSAUX 中部分组件（如
OPTIMIZER_STATS、AWR）支持基于保留策略的自动清理，但需显式配置 - 自动索引功能会悄悄在
SYSAUX或指定表空间建索引，可能意外撑大空间——这不是优化，是风险点
V$SYSAUX_OCCUPANTS 是诊断 SYSAUX 空间暴增的唯一可靠入口
当监控告警说 SYSAUX 使用率超 85%，别急着扩容，先跑这句：
SELECT OCCUPANT_NAME, ROUND(SPACE_USAGE_KBYTES/1024/1024, 2) AS GB FROM V$SYSAUX_OCCUPANTS ORDER BY SPACE_USAGE_KBYTES DESC;
常见高占用组件及应对：
-
SM/AWR：AWR 快照保留天数太长 → 调整DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS，例如设retention => 7*24*60（7 天） -
SM/OPTSTAT：统计信息历史堆积 → 执行DBMS_STATS.PURGE_STATS（注意：19c 默认不自动 purge，必须手动或调度） -
UNIFIED AUDIT：审计记录未归档清理 → 检查UNIFIED_AUDIT_TRAIL表大小，用DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL清理
这些操作都不需要停库，但必须用 SYS 或具备 EXECUTE_CATALOG_ROLE 的用户执行。
自动索引（AUTO_INDEX_MODE）对表空间的真实影响
开启后，Oracle 会在后台自动创建、验证、删除索引，所有对象默认落在 SYSAUX 表空间，除非你显式指定：
ALTER SYSTEM SET AUTO_INDEX_TABLESPACES = 'MY_INDEX_TS' SCOPE=BOTH;
但要注意：
- 即使指定了
MY_INDEX_TS，自动索引的元数据、日志、临时结构仍写入SYSAUX -
AUTO_INDEX_MODE = IMPLEMENT不等于“全自动无忧”，它会生成大量测试索引，若业务 SQL 频繁变更，SYSAUX可能持续增长 - 关闭方式不是删表空间，而是
ALTER SYSTEM SET AUTO_INDEX_MODE = OFF，之后需手动清理残留索引：DROP INDEX "SYS_AI_..."
真正容易被忽略的是：SYSAUX 不可离线，所有清理操作都得在数据库运行中完成；而很多 DBA 把 SYSAUX 当成普通表空间，试图 ALTER DATABASE DATAFILE ... RESIZE 缩容，结果报错 ORA-01275 —— 它只允许扩展，不允许缩小。
