主页 / dba / 问题 / 87645
Accepted
Suresh Gautam
Asked: 2015-01-06 20:18:58 +0800 CST

Oracle nologging 对 REDO 生成的影响

  • 772

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

在 ETL 过程中发生了以下情况：

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

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

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

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

问题：

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

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

oracle performance

2 个回答

  1. Best Answer

    要深入了解这一点，您可能需要确定生成 REDO 的 SQL 语句。不幸的是，我认为没有任何简单、完全自动化的方法来检测每个 SQL 的 REDO。

    但是追踪最差的 SQL 语句通常并不太难。由于您已经获得了 AWR，请查看按 Elapsed Time 排序的 SQL Statistics 部分。如果有很多 REDO，那么其中一个语句可能会突出。例如，如果顶部语句是UPDATE、DELETE、MERGE (UPDATE)或INSERT没有提示（或带有错误提示）的 an。

    可能最上面的语句都是 CTAS 或INSERT /*+ APPEND */. 在这种情况下，请查看每个顶级语句的解释计划，例如使用select * from table(dbms_xplan.display_awr(sql_id => 'sql_id from AWR')); 如果执行计划说，LOAD AS SELECT那么它正在使用直接路径插入并且没问题。如果它说LOAD TABLE CONVENTIONAL，那就是问题陈述。

    可能它们都可以，但是 REDO 是由索引生成的。索引不会生成 REDO 的唯一方法是索引设置为NOLOGGING并且索引是在INSERT. 索引NOLOGGING仅适用于索引 DDL。您可能需要删除/禁用和重新创建/重建索引以减少重做。

    INSERT根据我的经验，语句未在直接路径写入中运行的最可能原因是：

    1. 在目标表上启用外键索引，使用引用分区时除外。
    2. 错误的提示语法。例如，如果加号之前有一个空格，如下所示：/* +. 或者如果提示被放置在一个稍微错误的位置，像这样 INSERT INTO /*+ append */ ...。
    3. 不支持的奇怪数据类型。我记不清了，但我认为 LOB 有一些额外的限制，比如您可能需要进行分区。
    4. 在目标表上触发。
    5. 我可能忘记了其他一些原因。

    发布整个 SQL 语句和执行计划，我们也许可以帮助调查。

    如果这些都没有帮助，那么它可能是一个 AWR 错误。每秒 15GB 非常高，但并非不可能。如果 Exadata 系统能够实现这一点，我不会感到太惊讶。

    • 4

  2. 如果索引到位：总是记录索引中的更新。

    另一件事是：nologging 仅用于复制数据的语句。

    insert into x values (y,z)将始终被记录，

    insert into x select y,z from source可以取消记录。

    • 3

相关问题