【问题标题】:Transaction Performance Impact of Materialized View Logs物化视图日志的事务性能影响
【发布时间】:2013-07-30 21:11:20
【问题描述】:

我一直在为一家主要以交易为中心的公司(使用 Oracle 数据库)研究如何使用物化视图进行数据聚合和报告。当前的报告系统依赖于一系列视图,这些视图掩盖了应用程序的许多复杂数据逻辑。这些视图在调用时会给系统带来沉重的负担。

我们有兴趣使用“快速刷新”进行增量更新,以便在用于报告之前执行一些复杂的查询逻辑;但是,组织内部担心物化视图日志(此快速刷新所需的)将对我们当前在数据库中的事务性能产生影响。这种表现对我们的组织非常重要,因此我们非常害怕任何变化。

这是我们需要实现的物化视图日志类型的示例:

create materialized view log on transaction
  with rowid, sequence(transaction_id,account_id,order_id,currency_id,price,transaction_date,payment_processor_id)
  including new values;

我们不会在更新时使用“on commit”子句,而是在创建视图时使用“on demand”子句,因为我们知道这会对性能产生影响。

实施这种类型的日志记录会影响数据库事务性能吗?我想它一定会稍微影响性能,因为提交中包含了一个额外的写入过程(到日志),但我在 Oracle 文档中找不到对此的任何引用。任何有关此主题的文献或建议将不胜感激。

感谢您的帮助!

【问题讨论】:

    标签: oracle logging materialized-views


    【解决方案1】:

    是的,会有影响。物化日志需要同步维护,因此事务将需要为基表中修改的每一行将新行插入物化视图日志。影响有多大在很大程度上取决于系统。如果您的系统受 I/O 限制并且您已经对其进行了优化,以便将更改物理写入基表是等待时间的重要部分,那么影响将比您的系统受 CPU 限制并且您的大部分等待时间用于读取数据或执行计算。

    如果您真的关心 OLTP 系统的性能,将报告分流到不同服务器上的不同数据库是有意义的。您可以使用 Streams(或 GoldenGate,如果您负担得起额外许可)将数据复制到报告服务器,这对源的影响比物化视图要小,因为重做信息可以异步读取(并且可以在报告服务器,而不是将工作负载放在生产服务器上)。然后,您可以在报告服务器上定义物化视图,它们不会对 OLTP 服务器产生任何影响。或者您可以创建一个逻辑备用数据库作为您的报告服务器并在那里创建物化视图。无论哪种方式,将报告工作负载移出生产服务器并异步读取重做数据将保护生产服务器的性能。

    【讨论】:

    • 感谢您的回答。我相信您是对的,将报告工作负载从生产中移出是处理此问题的最佳实践解决方案。如果只有物化视图可以基于重做日志的异步读取来刷新。
    猜你喜欢
    • 2023-02-03
    • 2023-03-26
    • 1970-01-01
    • 1970-01-01
    • 2012-03-08
    • 2020-04-22
    • 1970-01-01
    • 2015-07-31
    • 2012-11-16
    相关资源
    最近更新 更多