Sql server SSIS存储过程使用临时表2008和2014

我目前正在编写一个SSIS包，它通过OLE DB源从存储过程中检索数据。该存储过程包含一个相当糟糕的查询，我已经通过使用临时表对其进行了改进。如果我将这些临时表切换到表变量，逻辑读取从130万跳到5600万。我对130万已经够不舒服了，但我不可能满足于5600万次逻辑读取。因此，我无法将临时表转换为表变量

但是，SSIS（或者更确切地说是SQL Server）无法解析此查询的元数据，因此包不会运行。我在网上找到了几种不同的解决方案，但它们似乎都不适用于SQL Server 2008和SQL Server 2014。我们目前正在将所有服务器升级到2014年，这个特定的包在开发中与2008年、QA中与2014年以及目前生产中与2008年运行。到了秋天，PROD层将在2014年推出，而DEV层将在2014年之后的某个时候推出。不幸的是，我不能等到这些升级碰巧发布了这个SSIS包。数据需要在下周开始移动。因此，我需要找到一种方法来为这两种环境解析元数据。以下是我迄今为止所尝试的：

在返回正确元数据的

IF 1=0

块中添加虚拟选择。这在2008年起作用，但在2014年不起作用

在存储过程的开头使用

SET FMTONLY OFF

。这在2008年起作用，但在2014年不起作用。此外，它会使存储过程为返回的每一列运行一次（在本例中超过30列），这是一个交易破坏者，即使它确实工作了

使用

EXEC。。。结果集（（…）。这在2014年起作用，但在2008年不起作用

部署一个返回正确元数据的存储过程，构建并部署SSIS包，然后将该存储过程修改为正确的版本。这两种环境似乎都不起作用，这将使在我们的ETL框架内开发的任何其他ETL应用程序变得复杂

如果我想不出什么，我可以将不同的存储过程和包部署到不同的层，但我更倾向于反对这种做法。首先，这将使未来的版本复杂化，我还需要确保在升级服务器后不会忘记更新存储过程和包

我还可以在数据库中创建真正的表，以取代这些临时表。我真的不喜欢这个解决方案，但这是我可以容忍的。如果我最终这样做了，我将来可能会转而使用带有结果集的

---

但是，我个人并不太喜欢这两种解决方案，因此我想知道是否有我错过的、可能会更好一些的解决方案。

尽管您不愿意，但我认为您做出了正确的选择，一个专用的暂存区是正确的选择。我使用过的大多数生产ETL都有一个专用的暂存数据库，更不用说表了。这样，您就可以更明确地控制存储，从而使性能更可靠，而且整个过程通常更易于维护。例如，您可以使用自己的文件组等为这些表创建一个专用的连续快速磁盘空间块。我当然更愿意看到两个独立的SP依赖于几个物理表，而不是一个非常粗糙的单个表

---

这就是说，在不知道任何细节的情况下，这只是我的经验，因此给未来的读者一个警告：与数据库中的所有内容一样，一定要测量场景的实际性能（之前和之后）不要根据查询计划做任何假设，这可能会误导你。

第一篇文章写得很好，你已经清楚地完成了你的研究。您是否尝试过1和3的组合？一个存储的进程，它同时具有

和结果集…

以及

如果1=0..

？您已经对SSIS处理临时表的方式在2008年和2012年之间发生的重大变化一针见血。不过，请刷新我的内存，为什么SSIS包会更改？无论调用程序是2008年还是2014年，它仍然会调用dbo.MyProc。这只是需要针对环境进行更正的底层过程，是吗？使用包装器存储过程如何？在两台SSIS服务器上，相同的SSIS代码调用相同的进程名。2014年，该proc与结果集一起使用来调用执行实际工作的子proc。在2008年，包装程序使用IF 1=0并调用相同的子程序（或2008年调用的相同程序代码）。您是否尝试将包的延迟验证设置为true，以便它在运行该步骤之前不会查找元数据？我同意Matt的观点。如果性能真的那么差，请查看优化物理临时表。尝试在不同大小和基数的数据集上发现表变量与临时表用法之间的模式。从我的经验来看，每个环境都有一个“最佳点”，在这里，访问磁盘比访问内存更有意义。有趣的是，随着时间的推移，情况会发生变化。工作保障！