DBA_TAB_MODIFICATIONS不反映分区级活跃度，因其仅记录表级DML行数且PARTITION_NAME恒为NULL，设计目的仅为判断统计信息是否陈旧，而非性能监控。
分区表本身没有“活跃度”指标，oracle 不提供内置的 per-partition 访问计数器；所谓“监控活跃度并自动移动”，本质是结合业务语义 + 外部可观测信号 + 手动触发逻辑来实现的。
为什么 DBA_TAB_MODIFICATIONS 不反映分区级真实活跃度
很多人误以为 DBA_TAB_MODIFICATIONS 能看出哪个分区被频繁 DML —— 实际上它只记录表级变更行数（INSERTS/UPDATES/DELETES），且默认不开启、需手动 DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO 刷新，分区字段（PARTITION_NAME）在该视图中始终为 NULL。即使你查 DBA_TAB_MODIFICATIONS，也得不到分区粒度的写入热度。
- 该视图设计初衷是辅助统计信息收集判断是否
STALE，不是性能监控工具 - 分区裁剪后执行计划里看不到实际扫描了多少分区块，
V$SQL_PLAN中OBJECT_OWNER和OBJECT_NAME是表名，不是分区名 - 想靠它驱动“自动移动”，等于用温度计当 GPS —— 类型错配
真正可用的分区活跃度信号来源
必须从外围找可采集、可归因、有时序的信号。以下三类最实用：
-
V$SEGMENT_STATISTICS中LOGICAL_READS和PHYSICAL_READS按OBJECT_NAME+OBJECT_TYPE统计，但分区表的每个分区对应一个独立段（SEGMENT_NAME= 分区名），所以你可以查：SELECT OBJECT_NAME, STATISTIC_NAME, VALUE FROM V$SEGMENT_STATISTICS WHERE OBJECT_NAME IN (SELECT PARTITION_NAME FROM DBA_TAB_PARTITIONS WHERE TABLE_NAME = 'SALES') AND STATISTIC_NAME IN ('logical reads', 'physical reads'); - AWR 报告中
Top Segments by Logical Reads或Physical Reads部分，会列出具体分区段名（如SALES_Q1_2026），这是生产环境最可信的读取热度证据 - 应用层日志或中间件埋点：比如订单服务按
ORDER_DATE路由到对应分区，日志里带分区标识（partition=Q2_2026），再聚合即可得访问频次
自动移动分区数据的可行路径与关键限制
Oracle 19c 支持在线移动分区（ALTER TABLE ... MOVE PARTITION），但“自动”二字要打引号 —— 它不支持基于阈值的触发式移动，必须由外部调度器驱动。
- 移动前必须确认目标表空间存在且有足够空间：
SELECT BYTES/1024/1024 AS MB FROM DBA_DATA_FILES WHERE TABLESPACE_NAME = 'TS_HOT' - 移动过程会持有
TM锁，阻塞对该分区的 DML，虽不锁全表，但高并发场景下仍需避开业务高峰 - 不能跨引擎移动（比如从普通表空间移到加密表空间），也不能改变分区键结构，仅支持物理重定位
- 典型命令：
ALTER TABLE sales MOVE PARTITION sales_q2_2026 TABLESPACE ts_hot ONLINE UPDATE INDEXES;
其中ONLINE允许并发 DML，但索引维护仍需额外资源
别踩坑：把“活跃度”和“统计信息陈旧度”混为一谈
看到某个分区 LAST_ANALYZED 很老，就认为它“不活跃”——这是常见误解。分区可能刚被大量写入，但统计信息还没刷新；也可能长期只读，但统计信息一直没过期（STALE_PERCENT 默认 10%，写入量不够就不标记 stale）。DBA_TAB_STATISTICS 的 STALENESS 字段只反映采样偏差，不反映访问频率。
真正需要关注的是：你定义的“活跃”到底指什么？是最近 24 小时读取次数 >1000？还是写入量超过该分区总容量 5%？这个业务含义必须前置明确，否则所有监控和自动动作都会失焦。
