通过 SSIS 包将巨大的平面文件加载到 SQL 表太慢

Question

我每周都会收到大约 8 个巨大的分隔平面文件，这些文件将被加载到 SQL Server (2012) 表中。所有文件的总行数约为 1.5 亿，每个文件的行数不同。我有一个简单的 SSIS 包，它将平面文件中的数据（使用 foreach 容器）加载到历史表中。然后在这个历史表上运行一个选择查询来选择当前周的数据并加载到一个临时表中。

随着历史记录表变得非常大（80 亿行），我们遇到了问题。所以我决定备份历史表中的数据并截断。在截断之前，包执行时间按顺序从 15 小时到 63 小时不等。我们希望在截断后它应该回到 15 小时或更短。但令我惊讶的是，即使在 20 多个小时后，包仍在运行。最糟糕的是它仍在加载历史记录表。最新数据约为 1.2 亿。它仍然需要加载暂存数据，并且可能需要同样长的时间。

历史表和暂存表都没有任何索引，这就是为什么对历史表进行选择查询会占用大部分执行时间的原因。但是从所有平面文件加载到历史表总是不到 3 小时。 我希望我说得通。有人能帮我理解这周这个不寻常的执行时间背后的原因吗？谢谢。

注意： 最大文件（8GB）在 3 分钟内从平面文件源读取。所以我认为来源不是这里的瓶颈。

Answer 1

没有很好的理由，恕我直言，为什么该服务器要花这么长时间来加载这么多数据。你是说过去需要 3 个小时的过程，现在需要 60 多个？是第一部分（数据加载）还是第二部分（历史表）突然变慢了？或者，两者同时进行？

我认为我要做的第一件事是“信任，但要验证”这里没有索引在起作用。我要看的第二件事是这个表空间的存储分配......它是否空间不足，以至于 SQL 服务器不得不做一堆额外的体操来获取和维护存储空间？这个过程是如何提交的？在每一行之后？你能证明包定义最近没有改变吗？

显然，如今“1.5 亿行”并不是很多数据； 8GB也不是。如果您“简单地”将这些行移动到未索引的表中，那么“3 小时”将是一个慷慨的期望。显然，这种行为的唯一可靠根本原因是磁盘 I/O 负载急剧增加，我完全怀疑“过度提交”可能是原因的一部分: 重写而不是“懒惰写入”，重新读取而不是缓存。