在 DWH 环境中，出于性能原因，我需要将视图具体化为一个大约为 10 的表格。 100 列和 50.000.000 条记录。每天插入约 60.000 条新记录，并对现有记录执行约 80.000 条更新。根据决定，我不允许使用物化视图，因为架构师声称这会导致性能问题。我不能再争论这个案子了，这是一个不可撤销的决定，我必须接受。 所以我想在晚上每天满负荷，例如截断并插入。但如果作业失败，该表可能不是空的，但必须包含上次成功填充的数据。 因此我想到了类似故障转移表之类的东西，如果出现任何问题，将使用它：
IF v_load_job_failed THEN failover_table ELSE 正则表
根据预定义的条件，是否会使用类似故障转移表而不是另一个表？类似于在执行之前重写或操作选择查询的触发器？
我知道这有点肮脏的解决方法。
【问题讨论】：
标签： sql oracle data-warehouse
如果您有空间（短暂）双重存储，我建议
1) 克隆现有表（所有索引、授权等），但使用 _TMP 命名
2) 加载_TMP
3) 将基表重命名为_BKP
4) 重命名 _TMP 以匹配基表
5) 将 _BKP 重命名为 _TMP
6) 截断_TMP
ETA：#1 将是“一次”； 2-6 将成为每日脚本的一部分。
这一切都假设 (1) 检测所有新记录和所有更新记录以及 (2) 使用 MERGE (INSERT+UPDATE) 将这些更改的记录集成到基表中的性能与满负载“不相上下”。
（就我个人而言，无论如何，我倾向于全负载方法；当有人调整并入视图 def 中的引用值并更改所有记录的值时，您会发现自己在等待长达一周的更新50,000,000 条记录。通过满载方法完全消除了这种担忧）
综上所述，应该注意的是，如果正确定义了 MV，则 MV-refresh 方法在各方面都与此方法相同，除了： 1) 更简单/更少移动的部件 2）更透明（视图def的SQL附在MV上，不埋在某个PL/SQL包或.sql脚本中） 3) 在表重命名之间不会有“昙花一现”的时间，查询/进程可能看不到表并失败。
ETA：可以通过多种方式使用“分区魔术”来解决此问题，从而避免数据或表丢失的“短暂”时间。
例如，您可以有一个偶数日和奇数日分区。在奇数日插入数据（不提交），然后截断偶数日（同时删除旧日并暴露新日）。但这值得复杂吗？您需要添加一列进行分区，并处理重新运行的复杂性 - 如果您的逻辑不严格，您最终会截断刚刚加载的数据。但是，这确实可以防止出现故障
一种确实可以避免任何“昙花一现”并且不太容易出现“哎呀”的方法：
1）添加始终具有值 1 的“DUMMY”列。
2) 创建 _TMP 表（也带有“DUMMY”列）并按 DUMMY 列分区（因此所有行都转到同一个分区）
-- 每日脚本 --
3）加载_TMP表
4) _TMP 表与主基表的交换分区 WITHOUT VALIDATION INCLUDING INDEXES
需要重复一下：如果资源使用到 MV-refresh，所有这些方法都是等效的；它们只是更复杂，而且往往会让开发人员觉得“精明”地解决了已经解决的问题。
最后一点 - 解决 David Aldridge - 首先，每日刷新表不应该启用日志记录。在恢复方案中，只需确保您有步骤在恢复基表后运行刷新脚本。
在性能方面，里程会有所不同；但根据我的经验，识别和修改更改/插入的行的复杂性可能会变得非常棘手（在某些时候，有人会对您的脚本没有考虑的基础数据做一些事情；要么产生不正确的结果，要么产生性能障碍）。 DWH 环境倾向于适应这样的过程而没有什么问题。除非/直到完全刷新证明的开销超出系统可以承受的范围，否则它通常是最简单的“设置后忘记”方法。
关于这一点，如果数据可以在逻辑上分为“可能更新的实时行”与“永远不会更新的历史行”，您可以提出分区方案和流程每天只会截断/重新加载“实时”数据。
【讨论】：
物化视图只是一组带有基础表的元数据，没有理由不能以类似于物化视图内部机制的方式维护表。
我建议使用 MERGE 语句作为单个查询，而不是截断/插入。它要么完全成功，要么回滚以保持以前的数据完好无损。 60,000 条新记录和 80,000 条修改记录并不多。
我认为，如果您至少从一个简单的单一 SQL 语句开始，然后看看它如何为您工作，那么您就不会出错。如果您确实决定采用多步骤流程，请确保它在任何可能在中途出错的阶段自动恢复 - 这可能是个棘手的问题。
【讨论】：