大规模DELETE后FAST刷新失败，需启用INCLUDING NEW VALUES记录DELETE；COMPLETE刷新卡住时改用非原子模式；日志表膨胀需定期PURGE_LOG并迁移至SSD表空间；刷新前重置SNAPTIME$$避免误判。
大规模DELETE后FAST刷新失败，先确认日志是否记录了DELETE操作
物化视图日志（mlog$_xxx）默认只记录insert和update，但delete必须显式启用including new values才能捕获——否则refresh fast会跳过所有已删行，导致物化视图残留“幽灵数据”。
-
CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID, SEQUENCE(amount, order_date, status) INCLUDING NEW VALUES;中INCLUDING NEW VALUES不可省略 - 若已建日志但没加该子句，需先
DROP MATERIALIZED VIEW LOG ON sales;再重建 - 验证方式：
SELECT * FROM user_mview_logs WHERE log_table = 'MLOG$_SALES';，检查NEW_VALUES列是否为YES
DELETE量过大时COMPLETE刷新卡住，改用分批+非原子模式
单次DELETE百万行后执行REFRESH COMPLETE，Oracle默认以事务方式清空并重建物化视图，undo暴涨、锁表时间长，极易触发ORA-01555或IO打满。
- 强制走非原子刷新：
DBMS_MVIEW.REFRESH('MV_SALES', method => 'C', atomic_refresh => FALSE) - 搭配
parallelism => 2控制并发度，避免隐式并行抢占资源 - 若物化视图含分区，可先
ALTER MATERIALIZED VIEW mv_sales DROP PARTITION p_202604;再刷新，减少扫描范围
日志表本身因DELETE积压变慢，清理与迁移双管齐下
MLOG$_sales在高频DELETE场景下会快速膨胀，尤其当SNAPTIME$$长期未更新时，日志无法被PURGE_LOG回收，插入延迟飙升。
- 定期清理：
DBMS_MVIEW.PURGE_LOG('SALES', 1);保留最近1天日志（单位：天） - 迁移日志表到专用SSD表空间：
ALTER TABLE mlog$_sales MOVE TABLESPACE mvlog_tbs; - 禁用无用特性：
ALTER TABLE mlog$_sales DISABLE ROW MOVEMENT;、ALTER TABLE mlog$_sales NOCOMPRESS;
刷新前手动标记陈旧状态，避免FAST刷新误判
Oracle判断是否能FAST刷新，依赖SNAPTIME$$字段与基表变更时间戳比对。大规模DELETE后若未及时刷新，SNAPTIME$$滞后会导致系统错误认为“无变更”，跳过刷新。
- 主动重置刷新时间：
EXEC DBMS_MVIEW.REFRESH('MV_SALES', method => 'F', refresh_after_errors => TRUE);—— 即使失败也推进SNAPTIME$$ - 或直接更新日志表：
UPDATE mlog$_sales SET snaptime$$ = SYSDATE WHERE snaptime$$ （慎用，需在维护窗口执行） - 关键点：
SNAPTIME$$不是刷新触发器，而是刷新依据；它不自动更新，只在成功FAST刷新后写入
真正难处理的不是DELETE本身，而是日志表与SNAPTIME$$之间的时间差——这个差值一旦超过业务容忍窗口，物化视图就从“准实时”退化成“半黑盒”，查不到数据却报不出错。
