我收到大约8个巨大的分隔平面文件，每周一次加载到SQL服务器（2012）表中。所有文件中的总行数约为1.5亿，每个文件的行数不同。我有一个简单的SSIS包，它将数据从flatfiles（使用foreach容器）加载到历史表中。然后在此历史记录表上运行选择查询以选择当前周数据并加载到临时表中。
随着历史表变得非常大（80亿行），我们遇到了问题。所以我决定备份历史表中的数据并截断。在截断之前，包的执行时间按照该顺序从15小时到63小时不等。我们希望在截断后它应该回到15小时或更短时间。但令我惊讶的是，即使在20多个小时后包仍在运行。最糟糕的是它仍在加载历史表。最新数量约为1.2亿。它仍然需要加载登台数据，可能需要一段时间。
历史表和登台表都没有任何索引，这就是历史表上的select查询用于占用大部分执行时间的原因。但是从所有平面文件到历史表的加载总是在3小时之内。 我希望我有意义。有人可以帮助我理解本周这个不寻常的执行时间背后的原因是什么？感谢。
注意：最大文件（8GB）在3分钟内在flatfile源上读取。所以我认为来源不是瓶颈。
答案 0 :(得分：0)
没有有充分理由，恕我直言，为什么该服务器需要花费很长时间来加载那么多数据。你是说过去需要3个小时，现在需要60多个？是第一个（数据加载）还是第二个（历史表）部分突然变慢了？或者，两个一次？
我认为我要做的第一件事就是“信任，但要验证”这里没有索引。我要看的第二件事是这个表空间的存储分配......它是否已经耗尽空间，这样SQL服务器就不得不做一堆额外的calesthenics来获取和维护存储？这个过程怎么COMMIT？每排后？你可以证明最近没有改变包装定义吗？
显然，“1.5亿行”目前并不是很多数据;也不是8GB。如果您“简单地”将这些行移动到未编入索引的表中，“3小时”将是一个慷慨的期望。显然，这种行为唯一可靠的根本原因是磁盘I / O负载急剧增加，和我健康地怀疑“过多的COMMIT”可能是原因的一部分：重写而不是“懒惰写作”，重新阅读而不是缓存。