我们看到一个 SSIS 进程在一夜之间花费了太长时间，并且运行到早上很晚。
该进程查询数据库表以返回自上次进程运行(它每天运行)以来已更改的文件列表，这可以是工作周内从 3(周末)到 40 的任何值。可能有 258 个 Excel 文件(都基于相同的模板)可以导入。
正如我所说，这个过程似乎需要很长时间(它不在专用服务器上)所以我们决定查看性能改进建议，即增加 DefaultBufferMaxRows和 DefaultBufferSize至50,000和 50MB分别针对项目中的每个数据流任务。另一个主要建议是始终在表或 View 上使用 SQL 命令——我的每个数据流任务(我有九个)都依赖于电子表格中的范围名称——如果它可能有助于提高性能，我想知道什么是 - 是否可以从具有 WHERE 条件的 Excel 工作表中进行选择？
九个导入范围从单个单元格到 10,000 行 x 230 列的范围不等。这些中的每一个都被导入到临时表中，然后合并到适当的主表中，但是我们遇到了导入无法正确理解数据类型的问题(即使使用 IMEX=1 )，所以似乎我可能会得到更好的导入如果我可以以不同的方式选择数据，并将其限制为我感兴趣的行(而不是全部 10,000 行，然后将它们作为任务的一部分进行过滤)，即特定列不为空的所有行。
这只是最初研究性能改进的一个练习，但它也将帮助我继续维护和改进包，因为它是业务的重要流程。
最佳答案
在测试合并存储过程以查看改进过程的其他方法时，发现通过 SSIS 填充的临时表之一已损坏。查询并返回 500 条记录需要 27 秒，但查看表统计信息时，该表比应有的大得多。在与我们的 DBA 交谈后，我们删除并重新创建了表，现在该过程以之前的速度运行，即对于 5 个电子表格，该过程需要 1 分 13 秒，对于 43 个电子表格，大约需要 7 分钟!
虽然我仍会在某个时候重新审视这个过程，但每个人都同意暂时保持不变。
关于sql-server - SSIS 从带有 Where 条件的 Excel 工作表中选择，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/69909973/