我试图找到示例，但它们都很简单，只有一个 where 子句。这是情况。我有一堆从另一个数据库传输的遗留数据。我在同一个数据库中也有“好”表。我需要将（数据转换）数据从旧表传输到 w 表。因为这是一组不同的表，所以数据转换需要复杂的连接才能将旧数据正确地放入新表中。
所以，旧表旧数据。
新表必须有旧数据，但它需要大量连接才能将旧数据正确地放入新表中。
我可以使用带有很多这样的连接的直接路径吗？INSERT SELECT（大量连接）直接路径是否适用于已经在同一个数据库上的表（表之间的传输）？它仅用于从文本文件中加载表格吗？
谢谢你。
不，相反，这意味着您需要在 NOLOGGING 加载后进行备份，而不是您无法备份数据库。
请允许我详细说明一下。通常，当您在 Oracle 中执行 DML 时，您所做更改的前图像会记录在 UNDO 中，并且所有更改（包括 UNDO 更改）首先写入 REDO。这就是 Oracle 管理事务、实例恢复和数据库恢复的方式。如果事务被中止或回滚，Oracle 使用 UNDO 中的信息来撤消事务所做的更改。如果实例崩溃，那么在实例重新启动时，Oracle 将使用 REDO 和 UNDO 中的信息恢复到最后提交的事务。首先，Oracle 会读取 REDO 并前滚，然后，使用 UNDO 回滚所有在崩溃时未提交的事务。通过这种方式，Oracle 能够恢复到最后提交的事务。
现在，当您在插入语句上指定 APPEND 提示时，Oracle 将直接加载执行 INSERT。这意味着数据从高水位线上方加载到全新的、从未使用过的块中。由于正在加载的块是全新的，没有“前映像”，因此，Oracle 可以避免编写 UNDO，从而提高性能。如果数据库处于 NOARCHIVELOG 模式，那么 Oracle 也不会写入 REDO。在处于 ARCHIVELOG 模式的数据库上，Oracle 仍然会写入 REDO，除非在您执行插入 /*+ 附加 */ 之前，您将表设置为 NOLOGGING，（即，alter table tab_name nologging;）。在这种情况下，表的 REDO 日志记录被禁用。但是，这是您可能遇到备份/恢复问题的地方。如果您执行 NOLOGGING 直接加载，然后您遭受媒体故障，并且包含带有 nologging 操作的段的数据文件是从 nologging 加载之前的备份中恢复的，那么重做日志将不包含恢复该段所需的更改。那么，会发生什么？好吧，当您执行 NOLOGGING 加载时，Oracle 会将范围失效记录写入重做日志，而不是实际更改。然后，如果您在恢复中使用该重做，这些数据块将被标记为逻辑损坏。针对该段的任何后续查询都将收到 ORA-26040 错误。
那么，如何避免这种情况呢？好吧，您应该始终在任何 NOLOGGING 直接加载后立即进行备份。如果您从 nologging 加载后的备份中恢复/恢复，则没有问题，因为数据将位于已恢复文件的数据块中。
希望这很清楚，
-标记
SELECT 中的查询可以像您希望的直接路径插入一样复杂。直接路径仅指目标表。它与读取或处理数据的方式无关。
如果您正在执行直接路径插入，则要求 Oracle 将新数据插入到表的高水位线之上，这样您就可以绕过在现有块中重用空间以插入新行的正常代码。它还必须阻止其他插入，因为您不能在直接路径插入期间更改表的高水位线。如果您有一个可以在其中进行加载的停机时间窗口，这可能不是什么大问题，但是如果您希望现有表在加载期间可用于其他应用程序，这将是一个很大的问题。
是的，查询复杂性不应该有任何任意限制。
如果你插入 /*+ APPEND */ 到 target_table 中选择 .... from source1, source2..., sourceN where
它应该可以正常工作。但请考虑，负载的性能将受到该查询的性能的限制，因此，如果您期望获得良好的性能，请确保它经过良好调整。
最后，考虑在目标表上设置 NOLOGGING 是否会显着提高性能。但是，如果您决定实施 NOLOGGING，还要考虑备份恢复的影响。
希望有帮助，
-标记