小编Sur*_*tam的帖子

Oracle 数据库处于开启noarchivelog模式，并tablespace配置了nologging选项，保持不会出现恢复任何数据的情况。

ETL过程中发生了以下场景：

1. 第一小时的 AWR 在负载配置文件中显示每秒 15GB，每笔事务 131K。
2. 第一小时 AWR 显示“实例活动统计信息”中记录了 54TB 重做生成

我想知道为什么在这种情况下会生成如此大量的重做。

考虑以下过度重做的上下文：

1. 众所周知，字典特定的表空间被强制进行日志记录。
2. 考虑到这NOLOGGING无论如何不适用于由MERGE语句产生的任何 UPDATE 操作。
3. NOLOGGING 是通过 CTAS 和 DML（如插入）显式指定的，并使用 /*+ APPEND */插入语句的提示来绕过日志记录，即使 nologging 选项在表/表空间级别处于活动状态也是如此。

问题：

1. 1, 2 and 3除了生成如此大容量的 REDO之外，任何人都可以看到任何其他考虑因素吗？
2. 在 #2 的情况下，54TB（似乎简单地通过每秒 15G X 60 分钟 X 60 小时计算）重做生成在一小时窗口内是不可能的。怀疑 Oracle AWR 报告存在一些错误，它应该是自 Oracle 启动以来生成的全部重做。
3. 怀疑每秒生成的重做值存在错误。

非常感谢对上述问题和考虑的任何建设性答案，以便如果我错了，我可以纠正自己。

我有一个从 Oracle(11.2.0.4) 物化视图获取数据的应用程序，当关联表上发生任何 DML 操作或关联对象无效时，物化视图的预期行为将变为无效。

我的物化视图选项如下所列，并确认关联对象始终有效。

CREATE materialized VIEW mv_emp_test1 
NOLOGGING COMPRESS build IMMEDIATE 
REFRESH FORCE 
START WITH (SYSDATE) NEXT (SYSDATE+5/1024)
as
......

当物化视图每 5 分钟刷新一次时，它会进入 INVALID 状态，并且如果应用以下任何方法，则变为有效状态：

alter materialized view mv_emp_test1 recompile;
or
exec dbms_mview.refresh('mv_emp_test1');

另外，检查了相关文档和错误，metalink中的Doc ID 264036.1已经包含了确切的场景，但没有找到适当的解决方法，以便每5分钟自动刷新一次。