SSIS数据流源中的存储过程与直接SQL命令

Question

我正在为某些SSIS包提供维护支持。这些包具有一些数据流源，其中包含需要不时修改的复杂嵌入式SQL脚本。我正在考虑将这些SQL脚本移动到存储过程中并从SSIS调用它们，以便更容易修改，测试和部署。我只是想知道新方法是否有任何负面影响。谁能给我一个提示？

Answer 1

是的，使用存储过程作为数据源存在问题（尽管在控制流程中没有在执行SQL任务中使用它们）

你可能想读这个： http://www.jasonstrate.com/2011/01/31-days-of-ssis-no-more-procedures-2031/

基本上问题是SSIS不能总是弄清楚结果集，从而找出存储过程中的列。如果你编写一个使用临时表的存储过程，我个人已经遇到过这种情况。

我不知道我会走到文章的作者那里，根本不使用过程，但要小心你不要试图用它们做太多，如果你不得不做一些复杂的事情，在数据流之前的执行sql任务中执行此操作。

Answer 2

我可以诚实地看到改善。正如您所指出的，存储过程将提供更好的安全性，由于缓存的执行计划而提供更好的性能，以及更容易的维护。

重新开始！

Answer 3

只使用简单的存储过程作为数据源，您不会遇到问题。如果程序正在使用临时表和CTE - 则无法保证您不会遇到问题。即使您可以在设计时预览结果 - 您也可能在运行时遇到错误。

Answer 4

我的经验是，尝试让sproc作为数据源起作用并不值得头疼。也许一些简单的sprocs很好，在某些情况下，TVF可以很好地工作，但如果你需要做一些复杂的操作，那么除了sproc之外别无选择。

我找到的最佳解决方法是为您需要在SSIS中使用的每个sproc创建一个输出表。

1. 修改sproc以在start时截断新输出表，并将其输出写入此输出而不是（或除此之外）以SELECT语句结尾。
2. 在数据流之前使用Exec SQL任务调用sproc。
3. 从输出表中读取数据流 - 这是一项更简单的任务。
4. 如果要节省空间，请使用另一个Exec SQL再次截断输出表。我更喜欢离开它，因为它让我稍后检查数据，让我重新运行输出数据流，如果它失败而不再调用sproc。

这肯定不如直接从sproc的输出中读取，但它有效。 FWIW，这种模式遵循了一种原则（在Oracle中是专门的），sproc不应该试图成为参数化视图。

当然，所有这些都假定你有权利调整有问题的sproc。如有必要，您可以编写一个新的包装器sproc，它会截断输出表，然后调用旧的sproc并将其输出重定向到新表。