我正在编写一个SSIS包，它通过OLE DB Source从存储过程中检索数据。存储过程包含一个相当讨厌的查询，我已经能够使用临时表来改进。如果我将这些临时表切换到表变量，逻辑读取数据会从大约130万跳到大约5600万。我对130万用户感到不舒服，但我无法满足于5600万次逻辑读取。因此，我无法真正将临时表转换为表变量。
但是，SSIS（或更确切地说SQL Server）无法解析此查询的元数据，因此程序包将无法运行。我在网上找到了一些不同的解决方案，但它们似乎都不适用于SQL Server 2008和SQL Server 2014.我们目前正在将所有服务器升级到2014年，而这个特定的软件包在2008年开始运行DEV，2014年在QA，2008年在生产。到秋季，PROD层将是2014年，DEV层将在此后的某个时间推广。不幸的是，我不能等到这些升级发生这个SSIS包。数据需要在下周开始移动。因此，我需要找到一种方法来解决两种环境的元数据问题。这是我到目前为止所尝试的内容：
在IF 1=0 块中添加虚拟选择，返回正确的元数据。这适用于2008年，但不适用于2014年。
在存储过程的开头使用SET FMTONLY OFF。这适用于2008年，但不适用于2014年。此外，它会导致存储过程为每个返回的列运行一次（在这种情况下超过30），即使它确实有效，这也是一个交易破坏者。
使用EXEC ... WITH RESULT SETS (( ... ));。这适用于2014年，但不适用于2008年。
部署存储过程，返回正确的元数据，构建并部署SSIS包，然后将存储过程修改为正确的版本。这似乎在两种环境中都不起作用，这会使我们的ETL框架中开发的任何其他ETL应用程序复杂化。
如果我无法解决任何问题，我可以将不同的存储过程和包部署到不同的层，但我更倾向于这样做。首先，这会使未来版本复杂化，我还需要确保在升级服务器后不要忘记更新存储过程和包。
我还可以在数据库中创建真正的表来取代这些临时表。我真的不喜欢这个解决方案，但这是我能够容忍的。如果我最终这样做，我可能会在将来转而使用WITH RESULT SETS。
但是，我个人并不关心这些解决方案中的任何一个，所以我想知道是否有任何我错过的可能会更好的解决方法。
答案 0 :(得分：1)
尽管你不情愿，但我认为你做出了正确的选择，而且专用的临时区域是正确的方法。我使用的大多数生产ETL都有一个专用的暂存数据库，更不用说表了。然后，您可以更明确地控制存储，从而使性能更可靠，整个过程通常更易于维护。例如，您可以使用自己的文件组等为这些表创建一个专用的连续快速磁盘空间块。我当然更愿意看到2个独立的SP依赖于几个物理表而不是真正的单个表。
那就是说，在不知道任何具体细节的情况下，这只是我的经验，所以对未来读者来说是一个警告：与所有数据库一样，一定要衡量场景的实际表现（之前和之后），而不是基于任何假设在查询计划上 - 它可能会误导你。