Oracle 物化视图与同一数据库服务器上的复制

Question

我们需要在一天中的预定时间运行报告。 该应用程序 24*7 运行，因此不存在“非高峰”时间。

因此，运行报告不应给系统增加过度的负载。

该应用程序运行在WebSphere v6.1上，数据库是Oracle 10g R2。

我可以使用以下方法

1. 一组旨在报告的非规范化表格。
2. 创建物化视图并将其用于报告。 我们可以每天更新一次视图。
3. 我们可以创建另一个模式并使用 Oracle 的 Data Guard 实时复制表。

由于我们有某些内部限制，（1）是不可行的。

我需要知道，从性能的角度来看，（2）或（3）哪个更好？

我从许多人那里听说物化视图最初工作得很好，但随着数据量的增加， 性能很差。

任何人都有在同一数据库服务器中复制表的经验（但差异实例或模式）。

Answer 1

在某种程度上，物化视图是非规范化的表 - 非规范化是您可以在 SELECT 语句中定义的任何内容，例如联接、聚合和分析函数。 在 MV 的原始定义之后，您可以向基础 MV 表添加获得所需性能所需的任何索引。

话虽如此，我认为您的选择是：

1. 在同一个数据库中使用非规范化表，这些表以某种方式由您编写的代码维护 - 此选项将为您提供对加载过程的最大控制，但代价是必须编写并维护代码。 您还可以消除单独实例的基础设施开销。 非规范化过程和报告查询将增加活动/事务数据库的资源需求，您必须调整规模来处理此问题。 通过此选项，您还可以将报告应用程序的可用性与事务系统的可用性联系起来。
2. 在同一个数据库中使用 MV - 上述关于基础设施和资源开销的评论适用，但您可以利用 Oracle 的 MV 功能进行调度（通过 DBMS_JOB 实现）和事务读取一致性（“旧”）在解析并提交新的 SELECT 之前，数据仍然可见）。
3. 在同一主机上的另一个数据库/实例中使用 MV - 通过此选项，您可以获得一些边际分离和潜在可用性，但仍然会影响数据库主机的整体资源。 Oracle 的更高版本允许您将实例内的资源使用情况控制到细粒度的级别，因此我认为没有充分的理由在同一主机上运行单独的数据库。
4. 在不同主机上的另一个数据库中使用 MV - 您可以设置到事务系统的数据库链接并通过该链接执行 MV 刷新。 您仍然会有影响源系统上资源的 MV 刷新/“加载”过程，但所有查询活动都将被隔离，并且在源系统停机期间您将获得一定程度的报告可用性。 使用此选项，您必须购买额外的 Oracle 许可证。
5. 使用 Data Guard 实例 - 缺点：额外的许可证、设置和管理的复杂性增加。 优点：对源系统的影响最小，系统的真实副本，如果您使用逻辑复制而不是物理复制，您可以在 Data Guard 数据库中创建其他结构（视图、索引等）。

Answer 2

最好的选择是在另一台计算机上使用另一个Data Guard实例（不是模式，它没有意义）。 在这种情况下，您可以拥有最新的数据库，而不会干扰生产应用程序。

如果刷新不会产生大量资源使用，那么使用物化视图是很好的选择。 而且如果针对物化视图的查询也不会浪费太多资源。

您没有谈论的第三个选项是使用 Oracle Resource Manager 它允许您通过多种可能性控制资源使用。

无论如何，我更喜欢第一个（Data Guard），因为您同时拥有“报告数据库”和“实时备份”。