跟踪SSIS包中的数据加载性能问题

Question

有没有办法确定影响SSIS包加载性能的数据库差异是什么？

我有一个软件包可以在大约5分钟内加载并对我的笔记本电脑数据库上的~100k记录进行各种处理

在测试服务器上尝试相同的包和相同的数据，这在CPU和内存中都是一个合理的盒子，并且它仍在运行...到目前为止大约1小时:-( 用一小组数据检查包，然后运行Ok

Answer 1

过去几周我遇到过类似的问题，这里有几个你可以考虑的事情，按重要性递减的顺序列出，根据对我们来说最大的不同：

1. 不要假设有关服务器的任何内容。 我们发现我们的生产服务器的RAID配置错误（惠普向我们出售了固件不匹配的磁盘），磁盘写入速度实际上是它的50倍。因此，请使用Perfmon检查服务器指标。

2. 检查是否为SQL Server分配了足够的RAM 。插入大型数据集通常需要使用RAM和TempDB来构建索引等。确保SQL有足够的RAM，不需要换到Pagefile.sys。

3. 根据SSIS的圣杯，避免使用T-SQL 语句操纵大型数据集。即使您使用简单恢复模型，所有T-SQL语句都会导致更改的数据写入事务日志。简单恢复模型和完全恢复模型之间的唯一区别是，Simple会在每次事务后自动截断日志文件。这意味着大型数据集在使用T-SQL操作时会破坏日志文件，从而导致性能下降。

4. 对于大型数据集，如果可能，在源处进行数据排序。 SSIS Sort组件在相当大的数据集上窒息，唯一可行的替代方案（Ordinal，Inc。的nSort）对于每个CPU不可转移许可证的成本为900美元。所以...如果您绝对需要大型数据集，那么请考虑将其作为中间步骤加载到临时数据库中。

5. 如果您知道您的程序包将在目标服务器上运行，请使用SQL Server目标，因为它提供的性能比OLE DB大约高15％，因为它与SQL Server共享内存

6. 在数据库连接管理器上将网络包大小增加到32767 。这允许大量数据从源服务器更快地移动，并且可以显着改善对大型数据集的读取。

7. 如果使用Lookup转换，试验缓存大小 - 对较小的查找数据集使用缓存连接或完全缓存模式，对较大的数据集使用部分/无缓存。这可以释放急需的RAM。

8. 如果组合多个大型数据集，请使用RAW文件或临时数据库来保存已转换的数据集，然后将在一个数据流操作中插入所有表的数据，并且锁定目标表。使用登台表或RAW文件也可以帮助重温表锁定争用。

9. 最后但并非最不重要的是，尝试使用DefaultBufferSize和DefaulBufferMaxRows 属性。您需要使用Perfmon.exe监视程序包的“Buffers Spooled”性能计数器，并向上调整缓冲区大小 ，直到看到缓冲区被假脱机（分页到磁盘），然后稍微退一步。

第8点对于非常大的数据集尤为重要，因为如果出现以下情况，您只能实现最小日志记录的批量插入操作：

• 目的地表为空，
• 表在加载操作期间被锁定。
• 数据库处于简单/批量记录恢复模式。

这意味着对表的子进程批量加载将始终完全记录，因此您希望在第一次数据加载时将尽可能多的数据放入表中。

最后，如果您可以对目标表进行分区，然后将数据并行加载到每个分区中，则可以将加载时间缩短2.5倍，尽管这通常不是一个可行的选项。

Answer 2

如果您排除了网络延迟，那么最可能的罪魁祸首（包含实际数据量）就是您的管道组织。具体来说，您正在沿着管道进行哪些转换。

数据转换有四种形式：

• 流媒体（完全在进程中/在内存中）
• 非阻塞（但仍使用I / O，例如查找，oledb命令）
• 半阻塞（部分阻塞管道，但不完全阻止，例如合并连接）
• 阻止（阻止管道直到完全接收，例如排序，聚合）

如果您进行了一些阻止变换，那么这将大大压缩您在大型数据集上的性能。即使是非平衡输入的半阻塞，也会长时间阻塞。

Answer 3

根据我的经验，SSIS中最大的性能因素是网络延迟。在服务器本地运行的程序包运行速度比网络上的任何其他程序快得多。除此之外，我无法想到为什么速度会大不相同的任何原因。运行SQL事件探查器几分钟可能会产生一些线索。

Answer 4

在MSDN forums的CozyRoc指出了正确的方向......
- 使用SSMS /管理/活动监视器并发现大量TRANSACTION条目
- 让我思考，阅读Ole Db连接器并取消选中Table Lock
- WHAM ......数据加载正常： - ）

仍然不明白为什么它在我的笔记本电脑d / b上正常工作，并在测试服务器上停滞？
- 我是唯一一个使用测试d / b的人，所以这并不是说桌子上应该有任何争用吗？