SSIS存储过程使用Temp Table 2008和2014

Question

我目前正在编写一个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包.数据需要在下周开始移动.因此,我需要找到一种方法来解决两种环境的元数据问题.这是我到目前为止所尝试的:

1. 在IF 1=0 块中添加虚拟选择,返回正确的元数据.这适用于2008年,但不是2014年.

2. SET FMTONLY OFF在存储过程的开头使用.这适用于2008年,但不适用于2014年.此外,它会导致存储过程为每个返回的列运行一次(在这种情况下超过30),即使它确实有效,这也是一个交易破坏者.

3. 使用EXEC ... WITH RESULT SETS (( ... ));.这适用于2014年,但不是在2008年.

4. 部署存储过程,该存储过程返回正确的元数据,构建和部署SSIS包,然后将存储过程修改为正确的版本.这似乎在两种环境中都不起作用,这会使我们的ETL框架中开发的任何其他ETL应用程序复杂化.

如果我无法解决任何问题,我可以将不同的存储过程和包部署到不同的层,但我更倾向于此.首先,这会使未来版本复杂化,我还需要确保在升级服务器后不要忘记更新存储过程和包.

我也可以在数据库中创建真正的表来取代这些临时表.我真的不喜欢这个解决方案,但这是我能够容忍的.如果我最终这样做,我可能会转而使用它WITH RESULT SETS.

但是,我个人并不关心这些解决方案中的任何一个,所以我想知道是否有任何我错过的解决方法可能会更好一些.

Answer 1

尽管您不情愿，但我认为您做出了正确的选择，并且专门的暂存区是正确的选择。我使用过的大多数生产 ETL 都有一个专用的临时数据库，更不用说表了。然后，您将受益于能够更明确地控制存储，这使得性能更加可靠，并且整个事情通常更易于维护。例如，您可以为这些表创建一个专用的连续快速磁盘空间块，并使用它们自己的文件组等。我当然宁愿看到 2 个独立的 SP 依赖于几个物理表，而不是一个真正粗糙的单个 SP。

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