OLTP应用程序的业务报告

Question

我们有一个使用Oracle数据库10g企业版的OLTP应用程序，并计划构建业务报告层以满足以下需求。

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

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

我的问题是，

1. 这种方法有意义吗(MV的)？有人用MV来构建OLTP报告解决方案吗？
2. 这种方法的缺点是什么？
3. 如何使用Oracle CDC和表，以及执行同步的过程。
4. 还有其他方法吗？

谢谢你，雪莉

Answer 1

通常，我会想到一个视图层或一个物化视图层，用于报告用户。除非有具体的性能问题，否则我倾向于使用视图来创建偶尔的物化视图，这些视图使用查询重写来加速选定的报表。

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

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

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

正如我前面所说，我的首选是一个常规的视图层。这避免了多次存储数据的成本，并使得在OLTP和报表查询之间共享缓存中的块成为可能。它还可以相对容易地给用户提供不同的数据视图，并且不需要让业务用户知道他们报告的数据是如何过时的。如果由于OLTP数据模型不支持要运行的查询类型，因此性能成为问题时，可以通过查询重写创建具有目标的物化视图，这些视图与索引类似。这意味着用户可以查询常规视图，DBA稍后可以添加一个物化视图，该视图生成全部或部分结果，优化器可以更改查询计划以使用新的物化视图，而不是扫描表和在运行时进行聚合数据等工作。

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