staleness = 'needs_compile' 表示物化视图语法有效但元数据与基表结构不一致，必须先执行alter materialized view ... compile才能恢复刷新能力；跳过此步直接刷新会失败或静默退化，且自动刷新不会触发编译。
STALENESS = 'NEEDS_COMPILE' 表示物化视图定义语法有效，但其元数据与基表结构已不一致，必须先执行 ALTER MATERIALIZED VIEW ... COMPILE 才能恢复刷新能力——跳过这步直接刷新会失败或静默退化。
基表 DDL 后未手动编译是主因
当对基表执行 ALTER TABLE ... ADD COLUMN、DROP COLUMN、MODIFY 或 EXCHANGE PARTITION 等操作后，Oracle 不会自动同步物化视图的内部元数据。即使物化视图本身没被改写，它的依赖快照就已过期。
-
STALENESS = 'NEEDS_COMPILE'通常伴随COMPILE_STATE = 'VALID'，说明语法没问题，但结构映射断了 - 查证命令：
SELECT MVIEW_NAME, STALENESS, COMPILE_STATE, LAST_REFRESH_DATE FROM DBA_MVIEWS WHERE MVIEW_NAME = 'YOUR_MV_NAME' - 常见诱因：基表加了
NOT NULL列但物化视图日志没重建；主键约束被禁用（STATUS = 'DISABLED'）；分区键表达式变更但 MV 定义未重载
COMPILE 操作不修复底层问题，只校验和重绑定
ALTER MATERIALIZED VIEW mv_name COMPILE 不会重建日志、不检查约束、不验证列兼容性，它只是让 Oracle 重新解析定义语句，并尝试重新绑定到当前基表结构。
- 若基表缺失主键或唯一索引，
COMPILE可能成功返回，但后续 FAST 刷新仍报ORA-12052 - 若基表某列被删，而 MV 查询中仍引用该列，
COMPILE会失败并留COMPILE_STATE = 'INVALID' - 必须配合
DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME')查REFRESH_FAST_POSSIBLE和MSGTXT字段，才能确认是否真可刷
为什么不能靠自动刷新触发编译？
Oracle 的自动刷新作业（如通过 DBMS_SCHEDULER）在遇到 STALENESS = 'NEEDS_COMPILE' 时不会尝试编译，而是直接跳过或报 ORA-12012 错误。
- 刷新作业日志里常见提示：
ORA-12008: error in materialized view refresh path，但根源其实是编译态卡住 - ON COMMIT 刷新模式下，
NEEDS_COMPILE会导致事务提交失败，报ORA-12052，而非延迟刷新 - 必须人工干预：先
ALTER MATERIALIZED VIEW ... COMPILE，再调DBMS_MVIEW.REFRESH，顺序不能反
真正容易被忽略的是：状态为 NEEDS_COMPILE 时，CAN_USE_LOG 往往已是 'NO'，说明物化视图日志链已经断裂——此时光编译没用，得顺藤摸瓜查 USER_MVIEW_LOGS 和 USER_CONSTRAINTS，否则刷新永远卡在 STALE。
