Database design OLTP应用程序上的业务报告

我们有一个使用Oracle Database 10g Enterprise Edition的OLTP应用程序， 并计划构建一个业务报告层，以满足以下需求

• 当前OLTP数据库设计的复杂性
• 提高当前OLTP报告的查询性能
• 提供对其他应用程序的只读访问
• 允许业务用户执行临时报告

我们正在考虑的解决方案是在当前OLTP上使用Oracle物化视图（MV）创建DB缓存层。 MV将被非规范化，并设计用于报告。MV日志将使用增量刷新同步对MV的更改

我的问题是,

这种方法有意义吗（MV）？是否有人使用MV构建OLTP报告解决方案

这种方法（MV）有哪些缺点

使用Oracle CDC和表以及执行同步的过程如何

还有其他方法吗

谢谢,，

---

雪莉

一般来说，我会考虑为报告用户提供一个视图层或物化视图层。除非存在具体的性能问题，否则我更倾向于使用视图，以创建偶尔使用查询重写来加速选定报告的物化视图

如果使用物化视图，显然会再次物化数据，但其格式会导致存储效率降低。这意味着系统中的大部分空间将分配给非规范化的物化视图及其索引。这可能会从您的磁盘供应商那里产生一笔相当大的费用，并可能造成SAN资源的竞争

物化视图还意味着OLTP和报告用户之间对缓存空间的竞争更加激烈。由于它们存储在不同的对象中，因此查找最近活动的报告将无法从OLTP活动的缓存中的热块中获益，反之亦然。您可以通过使用RAM或将报告转移到非高峰时间来缓解此问题，但这并不是最有效的解决方案。如果您有几乎完全的历史报告，这可能不是什么大不了的事——因为流程对完全不同的块感兴趣，所以无论如何都不会有共享——但是如果您有大量的操作报告，它就变得很重要了

物化视图也可能不那么灵活。如果您想以多种方式呈现相同的数据，那么将其物化多次会增加磁盘和缓存的实际成本，并增加定期刷新物化视图层所需的时间。在实践中，这往往意味着报告用户得到的是数据的最小公分母视图，当他们对数据进行切分时，必须重新发明轮子，因为它不想为他们创建新的物化视图

如前所述，我的首选是常规视图层。这避免了多次存储数据的成本，并使得在OLTP和报告查询之间共享缓存中的块成为可能。它还可以相对容易地为用户提供不同的数据视图，并且无需让业务用户了解他们报告的数据有多陈旧。如果由于OLTP数据模型不支持您想要运行的查询类型而导致性能出现问题时，您可以通过创建类似索引的目标物化视图。这意味着用户可以查询常规视图，DBA可以稍后添加生成全部或部分结果的物化视图，优化器可以更改查询计划以使用新的物化视图，而不是扫描表和在运行时聚合数据

---

在某种程度上，您可能希望将报告流量移动到具有更高维度数据模型的真实数据仓库中。如果您发现您确实需要物化视图层而不是常规视图层的性能，我会强烈考虑使用具有事实和维度的真实数据仓库。您将获得更灵活的报告功能，与完整物化视图层可能遇到的ETL问题基本相同。

@Sherry-为enterprise not express重写帖子。感谢您使用enterprise edition重新发布，关于MV的存储和资源问题，我们的观点是正确的。OLTP肯定存在性能问题。数据仓库本身就是一头野兽。另外，我们的理解是，仓库更多地用于OLAP，即数据挖掘类型的报告，而不是操作报告。我们是ISV（OLTP供应商），创建数据仓库实际上是不可行的。