我目前正在编写一个 SSIS 包,它通过 OLE DB 源从存储过程中检索数据。存储过程包含一个相当讨厌的查询,我可以通过使用临时表来改进它。如果我将这些临时表切换为表变量,逻辑读取次数会从大约 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 年则无效。
Use SET FMTONLY OFF
在存储过程的开头。这适用于 2008 年,但不适用于 2014 年。此外,它会导致存储过程为返回的每个列(在本例中超过 30 个)运行一次,即使它确实有效,这也是一个破坏性的因素。
Use EXEC ... WITH RESULT SETS (( ... ));
。这在 2014 年有效,但在 2008 年则无效。
部署一个返回正确元数据的存储过程,构建并部署 SSIS 包,然后将存储过程修改为正确的版本。这似乎在这两种环境中都不起作用,并且这会使我们的 ETL 框架内开发的任何其他 ETL 应用程序变得复杂。
如果我想不出任何办法,我可以将不同的存储过程和包部署到不同的层,但我非常不喜欢这样做。一方面,这将使未来的版本变得复杂,而且我还需要确保在升级服务器后我不会忘记更新存储过程和包。
我还可以在数据库中创建真实的表来代替这些临时表。我不太喜欢这个解决方案,但这是我可以忍受的。如果我最终这样做,我可能会转而使用WITH RESULT SETS
将来。
然而,我个人不太关心这些解决方案,所以我想知道是否有任何我错过的解决方法可能会更好一些。
尽管您不情愿,但我认为您做出了正确的选择,并且专门的暂存区是正确的选择。我合作过的大多数生产 ETL 都有专门的暂存区database,不用介意桌子。然后,您将受益于能够更明确地控制存储,这使得性能更加可靠,并且整个事情通常更易于维护。例如,您可以为这些具有自己的文件组等的表创建一个专用的连续快速磁盘空间块。我当然宁愿看到 2 个独立的 SP 依赖于几个物理表,而不是一个真正粗糙的单个 SP。
也就是说,在不知道任何细节的情况下,这只是我的经验,因此对未来的读者提出警告:与所有数据库一样,一定要测量场景的实际性能(之前和之后),而不是根据查询做出任何假设计划——它可能会误导你。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)