直接查 DBA_TABLESPACE_USAGE_METRICS，used_pct ≥ 95% 即 UNDOTBS 被撑爆；物化视图 COMPLETE 刷新默认 ATOMIC_REFRESH=TRUE 会全量 INSERT 并生成大量 UNDO，尤其含 LOB/CLOB 列时；改用 ATOMIC_REFRESH=FALSE 可避免，但需满足无聚合/JOIN/子查询且显式传参。
直接查 DBA_TABLESPACE_USAGE_METRICS，used_pct ≥ 95% 就是它在撑爆 UNDOTBS；别看 DBA_FREE_SPACE，那只是“碎片空闲”，对 undo 段分配没用。
确认是不是物化视图刷新在吃 UNDO
物化视图 COMPLETE 刷新默认走 ATOMIC_REFRESH => TRUE，会建临时表 + 全量 INSERT，LOB/CLOB 列哪怕只 SELECT * 带出来，也会触发物理复制路径，UNDO 瞬间暴涨。不是所有刷新都这样，但只要看到 ORA-30036 或 ORA-01555 且时间点和刷新任务重合，基本就是它。
- 查最近刷新记录：
SELECT job_name, status, actual_start_date FROM dba_scheduler_job_run_details WHERE job_name LIKE '%MV%' AND actual_start_date > SYSDATE - 1 ORDER BY actual_start_date DESC - 查当前高消耗事务：
SELECT s.sid, s.serial#, s.username, t.used_ublk, sq.sql_text FROM v$transaction t JOIN v$session s ON t.ses_addr = s.saddr LEFT JOIN v$sql sq ON s.sql_id = sq.sql_id WHERE t.used_ublk > 5000 ORDER BY t.used_ublk DESC—— 如果sql_text含DBMS_MVIEW.REFRESH或物化视图名，坐实了 - 注意：
used_ublk单位是数据块，一个块通常 8KB，>10000 就代表已占约 80MB UNDO 段
为什么 ATOMIC_REFRESH=TRUE 会撑爆 UNDO
因为 Oracle 内部把它当“原子事务”处理：先建同结构临时表 → 全量 INSERT /*+ APPEND */ 进去 → 再 DROP 原表 → RENAME 临时表。整个过程所有列（尤其是隐式 LOB）都要写 UNDO，百万级数据一刷，UNDO 日志翻倍生成。
- 即使物化视图定义里没显式写 CLOB，只要基表有、且 SELECT * 包含它，就逃不掉
-
ATOMIC_REFRESH => FALSE能跳过这一步，改用TRUNCATE + INSERT /*+ APPEND */，完全不走 UNDO —— 但前提是物化视图不能含聚合、JOIN、子查询，否则 Oracle 会悄悄忽略该参数，照旧走原子路径 - 调用时必须显式传参：
DBMS_MVIEW.REFRESH('MV_NAME', method => 'C', atomic_refresh => FALSE)，定时任务里写死，别依赖默认值
排查时最容易漏掉的两个系统表
物化视图刷新不只压 UNDO，还可能顺带把 SYSTEM 表空间拖垮 —— 关键线索是 IDL_UB1$ 和 OBJ$ 的异常增长。它们不显眼，但刷新频繁时会偷偷膨胀。
-
IDL_UB1$存 PL/SQL 编译单元，每次刷新都会触发相关包重编译，每个 piece 存一条记录。查它：SELECT segment_name, round(bytes/1024/1024) size_mb FROM dba_segments WHERE tablespace_name = 'SYSTEM' AND segment_name = 'IDL_UB1$'，超 200MB 就得警惕 -
OBJ$是对象元数据核心表，如果物化视图定义反复重建（比如开发环境误删重建），OBJ#持续递增但旧记录未清理，也会推高 SYSTEM 使用率 - 这两个表不会报 ORA-30036，但会和 UNDO 爆满同时发生——别只盯 UNDOTBS，SYSTEM 也得一起看
真正卡住人的从来不是“怎么扩 UNDO”，而是“为什么刚扩完又满了”。物化视图刷新的 UNDO 开销是结构性的，不改刷新方式或字段定义，扩容只是缓兵之计；LOB 列、隐式编译、定时任务参数遗漏，任何一个没对齐，ATOMIC_REFRESH => FALSE 就形同虚设。
