Oracle 来自大表的查询在合并期间很慢

我们的应用程序从大表 (约120mil行) 读取数据。索引设置正确，因此读取查询速度很快 (最多几十毫秒)。应用程序不会更改表中的数据，只是使用相同的查询只是子句读取

每天有一个ETL作业将更改 (从外部系统) 填充到delta表，并因此运行存储过程，该过程通过合并将更改从delta填充到主表。上次在delta表中有1600万条记录。
我们的问题是，在合并过程中，一些应用程序查询很慢 (1-35秒而不是几毫秒)。这只是日常查询的0.056%，但无论如何我们都需要减轻这种情况。查询是相同的，只是在 “中” 子句中可以为某些列设置更多值 (例如

PRODUCT_CODE IN (:5 , :6, :7)

与。

PRODUCT_CODE IN (:5)

)。

我们应该使用什么解决方案来消除数据更新对读取查询的影响？
我们看到了两种可能性:
1) 将物化视图1:1与主表一起使用，仅在对主表执行ETL合并后才刷新
2) 将表同义词与主表的2个版本 (主动和被动) 一起使用。将对被动表进行更新，一旦完成 (包括索引和统计重新计算)，同义词将更改为被动表，使其处于活动状态。
提到的任何解决方案都可以解决我们的问题吗？
谢谢，罗伯特

也许你需要做的第一件事是找出缓慢的原因。潜在原因是:

a- machine在合并期间缺乏CPU
合并期间b机缺乏IO带宽
c-查询正在进行块清理
d- query正在进行大量的读取一致性撤消工作

首先找到原因很重要，因为 (例如) 如果它的 (1) 或 (2)，那么您建议的选择不会有太大的好处，因为您仍然在做同样多的工作。

所以我会在这个过程中查看您的查询的一些跟踪，但是使用dbms_session，但也有一些会话统计的快照 (清理和撤消记录应用的统计信息在这里是相关的)

假设你的机器很好，你被 (c) 或 (d) 击中，那么就你的选择而言，要小心的一件事是，当你 “轻弹开关” 时，所有的查询都将不得不再次经历一个解析阶段。这是否是一个问题，真的取决于音量/频率。

此外，如果您沿着被动/主动路线而不是合并，通常创建表即选择会更有效