13亿记录ETL优化Oracle to SQL Server答案

【问题标题】：1.3 billion record ETL optimization Oracle to SQL Server13亿记录ETL优化Oracle to SQL Server
【发布时间】：2014-08-30 16:42:24
【问题描述】：

我有一个关于优化在 Oracle 和 SQL Server 之间传输 10 亿到 13 亿条记录（未来容量高达 20 亿或更多记录）的好方法的问题。

*编辑*我忘了提——这个过程需要每周运行一次，在 1 个周末的时间范围内。

目前我计划使用 ETL 包。我现在正在寻找 Talend 或 SSIS。

这是数据设置。数据驻留在 Oracle 上，需要先收集并重新打包后再传输。

目前我的流程是这样的： 1.) 存储过程提取所有数据并将其重新打包到 oracle 表中。 2.) ETL 将扫描此表并将其移动到 SQL Server DB。 3.) Oracle 和 SQL Server 上的表是一样的。

我一直在寻找有关优化流程的一些想法。如何优化插入到 SQLserver 中的好方法？

1.) 我想只是将表放在 SQL Server 上，然后将表创建为 select * from oracle_table

2.) 存储过程的重新设计，使其在 ETL 中运行（使我不必插入到 oracle 中），然后直接插入到 SQL Server -- 在使用 Talend（我不能代表 SSIS）进行小批量测试时，我遇到了一些性能问题 - 重组过程需要更长的时间来提取数据，然后直接在 Oracle 上调用它。这是正常的，还是我搞砸了优化？

3.) 有没有更好的方法来进行我不知道的海量数据传输？

任何建议都会很棒。我认为链接服务器是这里的一种选择，但没有设置，而且我以前从未设置过。

任何点/提示都会很棒，因为我对这一切都很陌生。

【问题讨论】：

您真的每周都会生成 1-20 亿个全新的行吗？这似乎不太可能。最大的优化来源似乎很有可能是构建变更数据捕获流程，这样您就只需要移动一周内实际添加或修改的任何一小部分行。
实际上是的——我知道这听起来很疯狂，但数据每周都在变化，并且会自我更正。
那么您的 1-20 亿行中的绝大多数每周都在变化？这似乎不太可能。即使您有一个正在纠正数据的流程，从一周到下一周，绝大多数数据似乎很有可能不会发生变化。
在这张大桌子上备份和恢复不会有任何帮助吗？如果两台服务器都使用相同的 SAN，那肯定是有益的。我以前没有这样做过，只是把它扔在那里，以便有人可以阐明一些事实。

标签： sql-server oracle optimization ssis etl

【解决方案1】：

您最好的方法是：

将存储过程的结果直接推送到平面文件。
使用 bcp 或 BULK INSERT 将平面文件推送到 SQL Server。

如果您绝对需要Oracle中的表副本，那么我至少会比较以下性能：

使用存储过程写入表
使用 Bulk Loader 将您生成的同一平面文件导入 Oracle 中

【讨论】：

只有一个项目将数据从 Oracle 移动到 SQL Server 的样本大小，您能否帮助我和未来的读者为什么要支付导出到文件和从文件导入到 SQL 的额外费用服务器与仅使用 SSIS 等 ETL 工具将其全部保存在内存中？
@billinkc ：我不是在寻找一场激烈的战争，但你是说根据你的经验，SSIS 比导出/导入更快吗？也许我们没有正确设置 SSIS，但我从事的一个项目，导出/加载是总时间的 1/2。
即使使用 Attunity 适配器，SSIS 中的 Oracle 源在大容量传输方面的性能也从未像 Oracle->file->BULK INSERT 那样好，即使有成本也是如此。对我们来说，我们已经看到了移动少至 3000 万（宽）行时的性能权衡。另外，您可以更轻松地并行化文件进程，尽管我很想知道 Attunity 的并行性功能如何与一种分区存储过程一起使用，该过程在不同的索引点访问所有相同的基表。
对于大多数用途，我只会使用 SSIS - 源输入，目标输出。但是，作为大型数据集的来源，Oracle 绝对是一种情况，（根据我的经验）数据流吞吐量非常好，但与平面文件中间人相比却不是最优的。
@shellter 我也不是。顺便说一句，这里的讨论很好，应该修补到 Kyle 的答案中，以帮助人们理解 why 与 internet sez。 “视情况而定”的标准警告适用，但我的观点是，在一般意义上，(Disk Reads from source + disk write for export + disk read for import + disk write for SQL Server) > (Disk reads from source + abuse of memory + Disk write for SQL Server)。如果在集体的经验中该公式不适用于 Oracle，那么我将做一个注释以始终评估这两种方法。

【解决方案2】：

有一些最佳实践和注意事项可以让您以更好的方式做到这一点

对目标使用分区
使用 Memory_Optimized 表进行暂存甚至作为目标
不要使用 select * ，即使你需要所有的 Columns ，尽量拉出你需要的列

-使用批量插入（特别是在 SSIS 中）
以适当的方式对源和目标使用 drop/Recreate Indexing 策略
为 oracle 使用 Microsoft attunity 连接器（在 SSIS 中）
使用并行加载

【讨论】：