物化视图日志本身不撑爆SYSTEM表空间，真正导致SYSTEM膨胀的是FAST刷新触发的PL/SQL频繁编译，使IDL_UB1$等系统表持续写入；迁移MLOG$_表无效，需优化刷新策略、停用异常作业、禁用非必要FAST并清理IDL缓存。
物化视图日志本身不会直接撑爆system表空间，但它的存在会间接引爆idl_ub1$等系统表——问题不在mlog$_xxx，而在刷新行为触发的pl/sql编译链路。
为什么把MLOG$_表迁到独立表空间也救不了SYSTEM？
很多人看到MLOG$_YOUR_TABLE占了几十GB，第一反应是“把它挪出SYSTEM”。但现实是：物化视图日志表默认建在源表所在表空间，而源表通常也不在SYSTEM里；真正吃掉SYSTEM的是IDL_UB1$、IDL_UB2$这些Oracle内部PL/SQL编译缓存表。它们在每次FAST刷新时被反复写入，尤其当物化视图定义含复杂查询或依赖多个包时，每刷新一次就可能生成数百条piece记录。
-
DBMS_MVIEW.REFRESH执行时，Oracle需重解析、重编译相关PL/SQL对象（包括物化视图自身的查询定义），这部分元数据全写进IDL_UB1$ -
MLOG$_表即使建在USERS表空间，只要刷新作业跑在SYSTEM表空间上下文（如通过DBMS_SCHEDULER默认JOB_CLASS），其编译开销仍压在SYSTEM上 - 迁移
MLOG$_表本身不改变刷新机制，反而可能因跨表空间DML引入额外锁等待，加剧刷新延迟，进一步拉长IDL_UB1$驻留时间
真正该动的是刷新策略和编译边界
SYSTEM暴增不是存储配置问题，而是执行路径失控。核心动作是切断“高频刷新 → 频繁编译 → IDL_UB1$膨胀”的正反馈循环：
- 检查
dba_scheduler_jobs中所有物化视图刷新任务，停掉状态为BROKEN或FAILED的作业——DBMS_MVIEW.REFRESH失败后不会自动重试，残留的失败状态会持续触发无效编译尝试 - 对非实时场景，把
REFRESH FAST ON COMMIT改为ON DEMAND，并用DBMS_MVIEW.REFRESH('MV_NAME', 'F')显式控制时机，避免隐式提交触发不可控编译 - 确认物化视图定义是否真需要FAST：如果查询含
ROW_NUMBER()、UNION ALL多表连接、或未在所有JOIN表上建日志，则FAST必然退化为COMPLETE，此时强制FAST只会徒增IDL_UB1$写入
紧急收缩IDL_UB1$的实操步骤
当IDL_UB1$已占SYSTEM 90%+，必须立即干预。注意：这不是常规维护，而是故障响应：
- 先查清哪些物化视图正在活跃刷新：
SELECT mview_name, last_refresh_date FROM dba_mviews WHERE refresh_mode = 'FAST'，重点关注last_refresh_date异常陈旧（>24h）的项 - 临时禁用高危刷新：
EXEC DBMS_MVIEW.UNREGISTER_MVIEW('OWNER', 'MV_NAME');（注意：这会断开日志消费链，仅限紧急止血） - 清理IDL缓存：
EXEC DBMS_UTILITY.COMPILE_SCHEMA(schema => 'SYS', compile_all => FALSE);—— 这会回收部分未引用的DIANA树，比直接删IDL_UB1$安全得多 - 若仍需释放空间，唯一合规方式是重启数据库后加
_kghdsidx_count=1隐含参数启动，再运行ALTER SYSTEM FLUSH SHARED_POOL;（该操作需DBA严格评估，生产环境慎用）
最易被忽略的一点：物化视图日志的生命周期和IDL_UB1$完全解耦。你删掉MLOG$_表，IDL_UB1$照涨不误；你清空IDL_UB1$，日志表里的变更记录也不会自动消失。两者得分开治理，不能指望一个操作解决两个维度的问题。
