TRUNCATE PARTITION 不会直接破坏物化视图日志，但会遗留未消费的 SNAPTIME$$ 记录，导致 FAST 刷新失败或卡在日志扫描阶段；必须使用 PRESERVE MATERIALIZED VIEW LOG 参数、及时清理日志并重建 snaptime$$/sequence$$ 复合索引。
TRUNCATE PARTITION 会破坏物化视图日志吗？
不会直接损坏，但会留下未消费的 SNAPTIME$$ 记录，导致后续 FAST 刷新失败或卡在日志扫描阶段。Oracle 不会自动标记被 TRUNCATE 分区里的变更记录为“已消费”，而物化视图刷新仍会全量扫描整个 MLOG$_xxx 表——哪怕其中大部分行对应的是已被清空的分区数据。
TRUNCATE PARTITION 前必须确认的三件事
不是所有分区都能随便 TRUNCATE，尤其当它关联着物化视图日志时：
- 查
DBA_MVIEW_LOGS确认该分区表是否建了日志：SELECT LOG_TABLE, MASTER, ROWIDS, PRIMARY_KEY FROM DBA_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE' - 查
DBA_REGISTERED_SNAPSHOTS确认是否有 MV 正在使用该日志：SELECT * FROM DBA_REGISTERED_SNAPSHOTS WHERE LOG_OWNER = 'OWNER' AND LOG_NAME = 'MLOG$_YOUR_TABLE' - 查
DBA_TAB_PARTITIONS确认目标分区是否含未刷新的变更：SELECT partition_name, high_value FROM DBA_TAB_PARTITIONS WHERE table_name = 'YOUR_TABLE' AND partition_name = 'P_2023'，再结合SNAPTIME$$范围判断是否安全
TRUNCATE PARTITION 时必须加的参数
Oracle 12c+ 支持显式保留日志元信息，避免后续 CREATE MATERIALIZED VIEW 报 ORA-12083 或刷新异常：
- 用
TRUNCATE TABLE owner.table_name DROP PARTITION p_name PRESERVE MATERIALIZED VIEW LOG—— 这是唯一合规方式 - 不加
PRESERVE MATERIALIZED VIEW LOG，Oracle 可能清理日志结构元数据，导致日志表头块残留状态不一致 - 不能用
ALTER TABLE ... TRUNCATE PARTITION ... UPDATE GLOBAL INDEXES替代，它不处理日志消费状态，且对物化视图日志无感知
TRUNCATE 后必须立刻补的操作
光执行 TRUNCATE 不够，日志表里那些指向已删分区的旧记录还在，不处理就会拖慢下一次刷新：
- 立即调用
DBMS_MVIEW.PURGE_LOG('YOUR_TABLE', 1)清理过期日志（数字为保留天数），强制推进SNAPTIME$$边界 - 更新日志表统计信息：
DBMS_STATS.GATHER_TABLE_STATS('OWNER', 'MLOG$_YOUR_TABLE')，否则优化器可能继续走全表扫描 - 检查并重建关键索引：
CREATE INDEX idx_mlog_snap_seq ON MLOG$_YOUR_TABLE (snaptime$$, sequence$$)，这是 FAST 刷新跳过无效分区的核心加速点
真正卡住人的，从来不是 TRUNCATE 本身，而是忘了 PRESERVE MATERIALIZED VIEW LOG 参数、没清 SNAPTIME$$、也没重建那个两字段复合索引——这三个点漏掉任意一个，物化视图下次刷新就大概率回到“扫描百万行、排序两小时”的状态。
