我们有一个使用 Oracle 数据库 10g 企业版的 OLTP 应用程序， 并计划构建业务报告层以满足以下需求。
我们正在考虑的解决方案是在当前 OLTP 上使用 Oracle 物化视图 (MV) 创建一个数据库缓存层。 MV 将被非规范化并设计用于报告。 MV 日志将使用增量刷新同步对 MV 的更改。
我的问题是，
谢谢你， 雪利酒
【问题讨论】：
标签： database-design oracle10g reporting materialized-views datamart
一般来说，我会考虑使用视图层或物化视图层来报告用户。除非存在具体的性能问题，否则我的偏好是与视图一起使用，着眼于创建偶尔使用查询重写来加速选定报告的具体化视图。
如果您使用实体化视图，您显然会第二次实体化数据，但其格式会导致存储效率降低。这意味着系统中的大部分空间将分配给非规范化的物化视图及其索引。这可能会从您的磁盘供应商那里产生一笔巨额账单，并且可能会导致对 SAN 资源的争用。
物化视图还意味着 OLTP 和报告用户之间对缓存空间的竞争更加激烈。由于它们存储在不同的对象中，正在寻找最近活动的报告将无法从 OLTP 活动的缓存中的热块中受益，反之亦然。您可以通过向其添加 RAM 或将报告移至非高峰时间来缓解此问题，但这不是最有效的解决方案。如果您几乎只拥有历史报告，这可能没什么大不了的——无论如何都不会共享，因为这些流程对完全不同的块感兴趣——但如果你有很多运营报告，它就变得很重要。
物化视图也可能不太灵活。如果您想以多种方式呈现相同的数据，则多次物化它会增加磁盘和缓存的实际成本，并增加定期刷新物化视图层所需的时间。在实践中，这往往意味着报告用户获得数据的最小公分母视图，并且在对数据进行切片和切块时必须重新发明轮子，因为 IT 不想为他们创建新的物化视图。
正如我之前所说，我的偏好是常规视图层。这避免了多次存储数据的成本，并且可以在 OLTP 和报告查询之间共享缓存中的块。它还使得为用户提供不同的数据视图变得相对容易，并且无需让业务用户了解他们报告的数据有多陈旧。如果由于 OLTP 数据模型不支持您要运行的查询类型而导致性能成为问题，您可以通过query rewrite 创建目标物化视图，其作用类似于索引。这意味着用户可以查询常规视图，DBA 稍后可以添加生成全部或部分结果的物化视图，优化器可以更改查询计划以使用新的物化视图，而不是扫描表并执行操作比如在运行时聚合数据。
在某些时候，您可能希望将报告流量转移到具有更多维度数据模型的真实数据仓库。如果您发现您确实需要物化视图层而不是常规视图层的性能，我会强烈考虑使用事实和维度的真实数据仓库。您将获得更灵活的报告，解决与使用完整的物化视图层可能遇到的基本相同的 ETL 难题。
【讨论】：