我目前正在编写一个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 .
但是，我个人并不关心这些解决方案中的任何一个，所以我想知道是否有任何我错过的解决方法可能会更好一些 .
1 回答
尽管你不情愿，但我认为你们已经拥有一个专门的临时数据库，从不介意表格 . 然后，您可以更明确地控制存储，从而使性能更可靠，整个过程通常更易于维护 . 例如，您可以为这些表创建一个专用的连续快速磁盘空间块，并使用自己的文件组等 . 我当然更愿意看到2个独立的SP依赖于几个物理表而不是真正的单个表 .
也就是说，在不知道任何具体细节的情况下，这只是我的经验，所以对未来读者来说是一个警告：与所有数据库一样，一定要测量场景的实际性能（之前和之后），而不是根据查询做出任何假设计划 - 这可能会误导你 .