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

Question

我目前正在编写一个 SSIS 包，它通过 OLE DB 源从存储过程中检索数据。存储过程包含一个相当讨厌的查询，我可以通过使用临时表来改进它。如果我将这些临时表切换到表变量，逻辑读取从大约 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 依赖于几个物理表，而不是一个非常粗糙的单个表。

也就是说，在不了解任何细节的情况下，这只是我的经验，因此对未来读者的警告：与所有事物数据库一样，请务必衡量您的场景的实际性能（之前和之后），而不是基于任何假设关于查询计划 - 这可能会误导您。