SSIS 将数据传输到 Oracle 数据库非常慢答案

【问题标题】：SSIS Transferring Data to an Oracle DB is Extremely SlowSSIS 将数据传输到 Oracle 数据库非常慢
【发布时间】：2017-05-10 00:44:45
【问题描述】：

我们正在从两个不同的来源将数据传输到 Oracle 数据库，而且速度非常慢。

请参阅下面的注释和图片。有什么建议吗？

注意事项：

我们正在使用 Microsoft OLE DB Provider for Oracle。
一个数据源是 SQL Server，包含大约 5M 条记录。
第二个数据源是 Oracle，包含大约 7 亿条记录。
在尝试传输 SQL Server 数据时，我们将其拆分为 “控制流”中有五个“数据流任务”。每个“数据流任务” 反过来使用内部使用“SQL命令”的“OLE DB源” 有效地选择了 5M 记录中的 1M。当我们运行这个包它运行第一个数据流任务大约 3 小时，仅转移了大约 50,000 条记录，直到我们结束流程。
我们在 Oracle 数据方面也有类似的经验。
由于某种原因，保存到 Oracle 目标非常慢。
有趣的是，我们曾经将相同的 700M 记录从 Oracle 转移到 SQL Server（所以相反的方向），它按预期工作大约 4.5 到 5 小时。

图片：

【问题讨论】：

考虑使用 Oracle OLE DB 提供程序而不是 Microsoft。还可以考虑创建链接服务器。看起来您可以只使用带有链接服务器的单个 SQL 存储过程而不是 SSIS 来完成此任务。 serverfault.com/questions/175257/…

标签： sql-server oracle ssis

【解决方案1】：

在 Oracle 方面，您可以检查 v$session 以查看时间花费在哪里（如果 AWR 在 Oracle 实例上获得许可，您可以使用 DBA_HIST_ACTIVE_SESS_HISTORY 或 v$active_session_history）。

我每天都在处理 Oracle 性能问题（超过 300 个生产 Oracle 实例），所以我有资格说我无法为您的问题提供具体答案，但我可以为您指明正确的方向。

导致插入速度变慢的典型过程错误：

不使用数组插入
为每个插入连接到数据库（听起来很奇怪？相信我我见过以这种方式设置 DataStage 和其他 ETL 工具）
应用服务器/客户端与 Oracle 实例不在同一局域网中
要插入的表上的索引（尤其是与位映射索引）；需要每个索引更新和表更新声明
Oracle 实例上的重做日志文件太小（驱动重做日志文件切换）
DB 端的 log_buffer 参数太小
没有足够的数据库写入器（请参阅 db_writer_processes 初始化参数）
提交过于频繁

【讨论】：

感谢您的回复，我会看一下，看看我发现了什么。

【解决方案2】：

不是答案，只是一堆观察和问题......

数据管道中的任何一个组件都可能成为瓶颈。

在 SSIS 中以交互方式运行时，您首先需要观察行数，看看是否有任何明显的阻塞发生 - 即，在数据转换转换之前您的行数是否较大，而转换后的行数较低？还是在 Oracle 目的地？还是只是需要很长时间才能摆脱 SQL？检查 SQL 端的一种快速方法是将其转储到本地文件 - 这主要衡量 SQL 选择性能，而不会受到 Oracle 的任何阻塞。

在 SQL Server 中运行源查询时，返回所有行需要多长时间？

您的数据转换转换可以在源查询中执行。每次转换都需要设置缓冲区、内存等，并且会减慢和阻塞数据流。避免这些，而是在源查询中执行此操作

Oracle 驱动程序中存在的各种缓冲区和配置。 @RogerCornejo 已经详细解决了这个问题。对于 Oracle 的读取性能，我发现更改 FetchBufferSize 有很大的不同，但是您在此处执行写入操作，所以情况并非如此。

最后，两个数据库服务器和 SSIS 客户端工具在网络方面位于何处？如果您在三个不同的服务器上运行它，那么您需要考虑网络吞吐量。

如果您按照建议使用链接服务器，请注意 SSIS 根本不进行任何处理，因此您将整个部分排除在外

如果您只是在寻找传输数据的最快方式，您可能会发现转储到文件和批量插入是最快的

【讨论】：

感谢您的回复。我正在审查选项
好建议@nic.mcdermaid！
它以转换前的小行数和转换后类似的小数开始。我们在一夜之间运行它，大约 8 小时后它仍在运行，转换前大约有 120 万，转换后有 30 万。在 SQL 中返回整个查询只需要 2-3 分钟。我们需要数据转换，因为我们在从 SQL 转换到 Oracle 时遇到了 Unicode 字符串错误。
看来这至少是您的问题之一。你得到了什么确切的错误？我建议您更改数据流以在源 SQL 中进行转换。请贴出错误，以及SQL列和Oracle列的数据类型
感谢您的回复。错误是“无法在 unicode 和非 unicode 字符串之间转换”。我发现在 SQL Server 和 Oracle 之间使用 OLE DB 提供程序时，它对源和目标上选择的数据类型更加敏感。

【解决方案3】：

感谢大家的建议。对于那些将来可能会遇到类似问题的人，我将发布最终对我有用的内容。 答案是……切换供应商。 ODBC 或 Attunity 提供程序要快得多，几乎快 800 倍。

请记住，我的目标是将数据从 SQL Server 数据库移动到 Oracle 数据库。我最初对源和目标都使用了 OLE DB 提供程序。如果您将数据从 SQL Server 移动到 SQL Server，此提供程序可以正常工作，因为它允许您在目标上使用“快速加载”选项，这反过来又允许您使用批处理。

但是，OLE DB 提供程序不允许以 Oracle DB 作为目标的“快速加载”选项（无法使其工作并在其他地方读取它不起作用）。因为我不能使用“快速加载”选项，所以我不能批处理，而是逐行插入记录，这非常慢。

一位同事建议尝试 ODBC，其他人建议尝试 Microsoft 的 Attunity Connectors for Oracle。我不认为差异会如此之大，因为根据我的经验，ODBC 的性能与 OLE DB 相似（有时甚至更低）（没有尝试过 Attunity）。但是...那是在 SQL Server 数据库之间移动数据或留在 Microsoft 世界的时候。

将数据从 SQL Server 数据库移动到 Oracle 数据库时，存在巨大差异！ ODBC 和 Attunity 的表现都显着优于 OLE DB。

这是我将 540 万条记录从 SQL Server 数据库插入到 Oracle 数据库的汇总性能测试结果。

在一台本地计算机上完成所有工作时。

OLE DB 源和目标插入 每分钟 12,000 条记录，这将花费 大约。 7 小时 完成。
ODBC 源和目标每分钟插入 900 万条记录，只用了 大约。 30 秒 完成。

将数据从一台网络/远程计算机移动到另一台网络/远程计算机时。

OLE DB 源和目标插入 每分钟 115 条记录，这将花费 大约。 32 天 完成。
ODBC 源和目标插入 每分钟 100 万条记录，只用了 大约 100 万条记录。 5 分钟 完成。

大不同！

现在为什么在本地工作时只需要 30 秒，而在远程工作时需要 5 分钟，这是另一天的另一个问题，但现在我有一些可行的方法（它应该在网络上较慢，但令人惊讶的是它慢得多）。

再次感谢大家！

补充说明：

我的 OLE DB 结果与适用于 Oracle 数据库的 Microsoft 或 Oracle OLE DB 提供程序相似。
Attunity 比 ODBC 快一点。我没有在远程服务器或更大的数据集上进行测试，但在本地它比 ODBC 快大约 2 到 3 秒。这些秒数可能会累积在一个大型数据集上，因此请注意。

【讨论】：