SSIS 包全表加载缓慢

Question

我们有一个 SSIS 包，显然被开发团队称为“慢”。由于他们没有使用 SSIS ETL 的人，因此作为 DBA，我尝试深入研究。以下是我找到的信息：SQL Server 已从 2014 版本升级到 2017，因此它具有两个版本的 SSIS。

1. 他们将大小为 200 GB 的 SQL Server 表加载到 SSIS 中，然后使用命令行压缩功能将数据压缩到平面文件中。
2. 数据流任务很简单select * from view——视图只是包含没有其他花哨连接的表。
3. 在进行故障排除时，我发现在 SQL Server 上几乎没有任何负载，可能是因为 select 命令在单线程中运行而不使用 SQL Server 内核。
4. 当我运行相同的 select * 命令（仅 5 秒，因为它是 200 GB 表）时，即使我的命令也是单线程的。
5. 该包具有 SQL 作业显示的配置文件（这是包的运行方式）以及一些连接设置。
6. 在 BIDS 中打开包显示 defaultBufferMaxRows 仅为 10000（可能是默认值）（因为配置文件或任何变量没有客户值，我猜这也是包正在使用的）。

SQL 和 SSIS 都在同一台服务器上。SQL 已分配最大内存，为 SSIS 和 OS 留下大约 100 GB。

请分享有关如何强制 SQL Server 使用多个线程运行此 select 命令以便整个表更快地进入 SSIS 缓冲池的任何想法。

编辑：我知道bcp可以比任何进程更快地读取数据并将其保存到平面文件，但此时对 SSIS 包的更改必须保持最少，并探索可以合并到 SSIS 包中的选项。

Edit2 : Parallelism 非常适合我的 SQL Server，因为我验证了很多其他查询。有问题的表是 200 GB。这只是 SSIS 的东西，它并没有像它应该的那样努力地敲打我的数据库。

Edit3：我取得了一些进展，将缓冲区值调整为 100 MB，将最大行数调整为 100000，现在包似乎做得更好了。当我直接使用 dtexec 实用程序在服务器上运行这个包时，它会产生每秒 40-50 MB 的良好负载，但通过 SQL 作业它永远不会产生超过 10 MB 的 lod。所以我想弄清楚这种行为。

Edit4：我发现当我直接从登录到服务器并调用 dtexec 实用程序运行包时，它运行良好，因为它在数据库上产生了良好的负载，导致数据 I\O 在 30-50 MB\sec 之间保持稳定。SQL 作业中的同一件事永远不会超过 I\O 超过 10 MB\sec。

我什至尝试使用代理运行包并选择 cmdline 操作但没有更改。特工真的很糟糕，这里有什么问题吗？

最后的尝试：我对我最后的观察感到困惑：1）通过调用 dtexc 实用程序从 Windows 节点的命令提示符运行时，同一个包的运行速度提高了 3 倍 2）当由 SQL 代理调用时，完全相同的包运行速度比上面慢 3 倍Windows 和 SQL Server 上的 sysadmin 权限

在这两种情况下，我都尝试查看它们调用的 DTEXEC 版本，并且它们都调用了相同的版本。那么为什么一个人会这么慢是我的理解。

Answer 1

表上的任何索引都可能会减慢加载速度。如果有任何索引，请尝试在加载之前删除它们，然后在加载后重新创建它们。这也会更新索引统计信息，该统计信息会因批量插入而产生偏差。