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），因为你有一个“报告dabatase”同时是“live-backup”。