drop index后段仍留在dba_segments是oracle 19c延迟清理机制所致，smon进程异步回收，需确认无依赖（如物化视图日志、函数索引、活跃事务）后再等待或手动推进清理，invalid状态索引不会被优化器选用。
为什么DROP INDEX不生效，段还留在DBA_SEGMENTS里
执行DROP INDEX后，索引状态在DBA_INDEXES.STATUS里变成INVALID，但DBA_SEGMENTS中仍查到对应段——这不是命令失败，而是Oracle 19c的延迟清理机制在起作用。SMON进程只在空闲时异步回收索引段物理空间，若系统负载高、或该索引曾被大量DML使用过，段可能卡在“标记删除但未释放”状态数小时甚至更久。
确认索引段是否真可安全清理
别急着强制干预。先验证它是否已无任何逻辑依赖或活跃引用：
- 查是否有函数索引依赖该列：
SELECT object_name, object_type FROM dba_dependencies WHERE referenced_name = 'YOUR_INDEX_NAME' AND referenced_type = 'INDEX' - 查是否被物化视图日志引用：
SELECT log_table FROM dba_mview_logs WHERE log_owner = 'OWNER' AND master = 'TABLE_NAME' - 查是否有未提交事务仍在访问原表（哪怕没直接查索引）：
SELECT sid, sql_id FROM v$session WHERE state = 'ACTIVE' AND sql_id IN (SELECT sql_id FROM v$sql WHERE sql_text LIKE '%YOUR_TABLE%')
只要以上任一查询返回非空结果，说明该索引段仍被隐式持有，硬删会引发ORA-00604/ORA-01410等连锁错误。
强制触发SMON清理或绕过延迟机制
如果确认无依赖，但段迟迟不消失，可手动推进清理流程：
- 唤醒SMON主动扫描：
ALTER SYSTEM FLUSH SHARED_POOL（副作用大，仅限维护窗口） - 更稳妥方式：让SMON立刻处理该段，执行
ALTER SYSTEM SET "_cleanup_rollback_segments"=TRUE SCOPE=MEMORY（仅会话级生效，不影响全局） - 终极手段（极少需用）：重启数据库实例——SMON会在OPEN阶段强制完成所有待清理段，但生产环境应避免
注意：DROP INDEX本身不写归档、不触发检查点，所以即使段未立即消失，也不会阻塞备份或RMAN操作；但若该索引曾用于分区本地索引，需额外确认DBA_IND_PARTITIONS.STATUS也已清空。
删完后空间没释放？别碰SHRINK
索引段删除后，DBA_SEGMENTS.BYTES不变是正常现象——Oracle不会自动下调表空间高水位线（HWM）。此时ALTER INDEX ... SHRINK SPACE无效（索引已不存在），而对基表执行SHRINK也无意义。真正要做的只有两件事：
- 确认段已从
DBA_SEGMENTS消失（查不到即代表物理释放完成） - 若表空间内碎片多，等业务低峰时用
ALTER TABLESPACE ... COALESCE合并相邻空闲区，而非针对单个索引段操作
最容易被忽略的是：某些DBA会误以为INVALID状态的索引还能被查询计划引用，其实优化器在硬解析时已完全跳过该索引——只要DBA_INDEXES.STATUS不是VALID，就不可能走索引扫描，不必为“看着还在”而焦虑。
