truncate partition 使物化视图 staleness 变为 unusable，因该 ddl 操作跳过重做/回滚且不写入物化视图日志，导致增量变更路径不可追踪，oracle 主动废止元数据有效性以防止 fast 刷新错乱。
截断分区（TRUNCATE PARTITION）后物化视图 STALENESS 变为 UNUSABLE，不是刷新失败，而是 Oracle 主动废止其元数据有效性——因为 TRUNCATE 是 DDL 操作，隐式提交且不可回滚，物化视图无法安全推导被删数据的增量变更路径。
TRUNCATE PARTITION 为什么直接让物化视图失效
Oracle 不把 TRUNCATE PARTITION 当作普通 DML，它跳过重做/回滚机制，也不写入物化视图日志（MLOG$_xxx）。哪怕你建了带 INCLUDING NEW VALUES 的日志，TRUNCATE 也不会触发任何日志记录。物化视图依赖日志做 FAST 刷新，一旦关键变更“不可见”，Oracle 就判定整个刷新逻辑断裂，将 STALENESS 设为 UNUSABLE。
这不是 bug，是设计保护：避免因丢失变更导致 FAST 刷新结果错乱。
-
TRUNCATE PARTITION后查DBA_MVIEWS，STALENESS字段大概率是UNUSABLE，不是STALE - 即使物化视图本身没用到被截断的分区，只要基表结构或行级一致性保障被破坏，状态就降级
- 和
DROP PARTITION类似，但更隐蔽：不报错、不警告，只静默改状态
修复必须分两步：COMPILE + REFRESH，顺序不能反
直接调 DBMS_MVIEW.REFRESH 会失败——UNUSABLE 状态下所有刷新参数（FAST/COMPLETE）都被忽略。必须先恢复编译态：
- 执行
ALTER MATERIALIZED VIEW your_mv_name COMPILE：仅校验语法与依赖，不触碰数据，毫秒级完成 - 再执行
DBMS_MVIEW.REFRESH('your_mv_name', 'C')：此时必须用'C'（COMPLETE），因为 FAST 路径已不可信；若坚持用'F'，仍报ORA-12054 - 如果物化视图含分区键，且被截断分区恰好覆盖其分区范围，
COMPILE可能失败——需先确认基表分区定义是否仍匹配 MV 的PARTITION BY子句
物化视图日志不会自动适配 TRUNCATE，重建是唯一可靠方式
MLOG$_xxx 表结构冻结在创建时刻，TRUNCATE 不会触发其字段增删或结构同步。若基表之后又做了 ADD COLUMN 或 MODIFY，而日志表仍按旧结构存着，后续哪怕 COMPILE 成功，FAST 刷新也会在运行时报 ORA-12054。
- 查日志有效性：
SELECT ROWIDS, PRIMARY_KEY, SEQUENCE FROM DBA_MVIEW_LOGS WHERE MASTER = 'BASE_TABLE_NAME'，三者至少两个为Y才支持 FAST - 查日志对象状态：
SELECT status FROM dba_objects WHERE object_name = 'MLOG$_BASE_TABLE_NAME'，若为INVALID，必须重建 - 重建命令：
CREATE MATERIALIZED VIEW LOG ON base_table WITH PRIMARY KEY, ROWID, SEQUENCE INCLUDING NEW VALUES（注意：需先DROP原日志）
容易被忽略的关键点：TRUNCATE 后的分区键表达式可能已失效
如果物化视图按 TRUNC(dt) 分区，而基表分区键是原始 dt 列，TRUNCATE 某个分区后，Oracle 可能无法对齐时间边界，导致 EXPLAIN_MVIEW 返回 DISABLED。这种失效不体现在 STALENESS，而是在查询重写阶段静默跳过物化视图。
- 验证方式：
DBMS_MVIEW.EXPLAIN_REWRITE查REWRITE_MECHANISM是否为NO_REWRITE，MESSAGE是否含partition key not used - 修复方向：确保物化视图定义中
PARTITION BY RANGE的列名与基表物理列名完全一致，禁用函数包装 - 临时绕过：设
QUERY_REWRITE_INTEGRITY = STALE_TOLERATED，但仅限测试环境，生产慎用
真正麻烦的不是 TRUNCATE 当下，而是它留下的“元数据断层”——状态变 UNUSABLE 只是表象，背后是日志失联、分区对齐失效、重写引擎拒识，每一步都得手动确认，不能靠一次 REFRESH 带过。
