sql-server – SSIS存储过程使用Temp Table 2008和2014
我正在编写一个SSIS包,通过OLE DB Source从存储过程检索数据.存储过程包含一个相当讨厌的查询,我已经能够使用临时表来改进.如果我将这些临时表转换为表变量,则逻辑读数从大约130万跳跃到大约5600万.我对130万人感到不舒服,但是没有办法可以满足5600万条逻辑读数.因此,我无法真正将临时表转换为表变量.
但是,SSIS(或SQL Server)无法解析此查询的元数据,因此该程序包将不会运行.我已经在线找到了一些不同的解决方案,但是它们似乎都不适用于SQL Server 2008和SQL Server 2014.我们目前正在将所有服务器升级到2014,而这一特定的软件包运行于2008年DEV,2014年在质量检查和2008年在目前的生产.到秋天,PROD层将是2014年,DEV层将在此之后推出.不幸的是,我迫不及待地等到这些升级发生,才能发布这个SSIS包.数据需要在下周开始移动.因此,我需要找出一种方法来为两个环境解析元数据.这是我迄今为止所尝试过的 >在IF 1 = 0块中添加一个虚拟选择,返回正确的元数据.这在2008年工作,但不是2014年. 如果我不明白什么,我可以将不同的存储过程和程序包部署到不同的层次中,但是我更愿意这样做.一方面,这将会使未来的版本变得复杂,我也需要确保在升级服务器之后,不要忘记更新存储过程和包. 我也可以在数据库中创建真正的表,这些表将取代这些临时表.我真的不喜欢这个解决方案,但这是我能忍受的.如果我最终这样做,我将来可能会切换到使用WITH RESULT SETS. 然而,我个人并不在乎这些解决方案之一,所以我想知道是否有任何解决方法,我错过了可能会更好一些. 解决方法尽管你不情愿,我认为你做出了正确的选择,专门的分期区是正确的方式.我所工作的大多数生产ETL都有一个专门的分期数据库,不用考虑表.然后,您将受益于能够更明确地控制存储,这使得性能更可靠,整个事情通常更易于维护.例如,您可以使用自己的文件组为这些表创建一个专用的快速磁盘空间区块.我肯定会看到两个独立的SP依赖于几个物理表,而不是一个真正的单一的.也就是说,没有任何细节,这只是我的经验,所以对未来的读者来说是一个警告:与所有的数据库一样,一定要衡量你的场景的实际性能(前后),而不是基于查询做出任何假设计划 – 这可能会误导你. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |