interval分区必须配store in，否则自动创建的分区默认落入用户默认表空间，引发i/o热点；正确写法为store in(ts1,ts2,ts3)，启用轮询分配以分散负载。
为什么 INTERVAL 分区必须配 STORE IN？
Oracle 21c 的 INTERVAL 分区本身不指定具体表空间，若建表时漏掉 STORE IN，后续自动创建的分区会默认落到当前用户的默认表空间，极易引发 I/O 热点或跨表空间混用问题。
- 正确写法必须显式声明：
STORE IN (ts1, ts2, ts3)，让 Oracle 轮询分配新分区 - 表空间列表需提前存在且状态为
ONLINE，否则插入数据触发自动建分区时会报ORA-01652 - 不建议只写一个表空间（如
STORE IN (ts1)），这等于放弃轮询机制，失去负载分散效果
如何用 DBMS_SCHEDULER 实现分区自动清理？
手动 DROP PARTITION 不可持续，用调度器配合 PL/SQL 才算真正自动化。关键不是“能不能跑”，而是“跑得稳不稳、删得准不准”。
- 先写清理逻辑：封装成存储过程，用
DBA_TAB_PARTITIONS查HIGH_VALUE解析出分区边界时间，再比对保留策略（如只留最近 12 个月） - 调度任务必须设
job_class并绑定资源组，避免清理任务挤占业务 SQL 的 CPU 或 I/O - 加异常捕获和日志记录——
DBMS_SCHEDULER.CREATE_JOB的raise_events参数要打开，否则失败无声无息 - 测试阶段务必用
DBMS_SCHEDULER.RUN_JOB手动触发一次，确认分区名解析逻辑无误（尤其注意DATE类型的HIGH_VALUE是字符串格式）
分区交换（EXCHANGE PARTITION）为何总卡在索引验证？
用 EXCHANGE PARTITION 加载历史数据时，90% 的失败源于本地索引状态不一致，不是语法错，是对象元数据没对齐。
- 交换前，源表（非分区表）的索引必须和目标分区表的对应本地索引字段顺序、类型、空值属性完全一致，连函数索引里的表达式都不能有空格差异
- 目标分区的本地索引状态必须是
USABLE，若之前执行过ALTER INDEX ... UNUSABLE，得先REBUILD - 加上
WITHOUT VALIDATION可跳过数据一致性校验，但仅限你 100% 确保源表数据符合分区键约束——否则后续查询可能返回错误结果 - 交换后立即查
DBA_IND_PARTITIONS，确认索引状态是否批量更新为USABLE，别只看语句没报错就以为成功
自动维护最易被忽略的权限链
调度任务能跑起来，不代表它有权删分区。Oracle 21c 对分区 DDL 的权限检查是穿透式的，缺一环就静默失败。
- 执行调度任务的用户（比如
SCHEDULER_ADMIN）必须有ALTER ANY TABLE，不能只给ALTER TABLE（那是对象级，不够） - 如果分区表在 PDB 里，该用户还得在 CDB 层有
SET CONTAINER权限，否则跨容器操作直接被拦 -
DBMS_SCHEDULER默认以创建者身份运行任务，但若用了credential指定其他用户，则那个用户也得有同等权限——权限不会继承
自动化不是配完就完事，每次数据库打补丁、升级 PDB 或调整资源管理器配置后，都得重新验证权限链是否断裂。这点比语法细节更常导致维护中断。
