SSIS包应该在数据库SQL Server还是单独的应用服务器上运行？

Question

我的公司似乎将应用程序代码放在与数据库不同的服务器上。

我们是一个数据仓库，主要使用SSIS和T-SQL将数据转换并加载到SQL Server中。我们想使用C＃.NET应用程序来执行一些步骤

例如，迭代文件并调用Web服务。

鉴于SQL Server 2008现在自动安装.NET 3.5并支持.NET存储过程，是否有理由禁止用.NET编写的.ETL代码在数据库服务器上运行？在同一个盒子上运行SSIS和.NET代码将有助于简化我们的工作流程，因此我们不必担心调度应用程序必须控制跨服务器的流量。

我确实理解，例如在Web应用程序中，将业务逻辑层与数据库层分开是合适的。

一个可能的障碍：在我的公司中，DBA不是App Server的管理员，并且没有权利将db Client工具安装到应用服务器，App Serve管理员可能不应该与安装数据库有任何关系客户端工具。如果他们这样做，则必须在App服务器管理员和数据库服务器管理员之间进行协调。也许DBA可以共享App Server的所有权。公司通常如何处理这个问题？

Answer 1

最佳做法是将SQL Server完全保留在盒子上。 SQL Server使用用户模式协作多任务和资源控制，假设100％拥有systemn，如果其他进程窃取内存或CPU，则不能很好地发挥作用。请参阅Dynamic Memory Management和SQL Server Batch or Task Scheduling。

至于.NET从SQLCLR内部进行ETL Web调用：甚至不去考虑它。从SQLCLR做任何类型的阻塞操作，你都会使SQL调度程序挨饿。

Answer 2

作为一般规则，您应该将SSIS服务器与SQL Server分开，因为SSIS是一个应用层。接下来，您的应用程序代码应该在单独的服务器上运行（可以与SSIS服务器相同）。

将您的缩放问题分开。

Answer 3

这取决于代码，数据库所需的可用性以及框的大小。如果你在SSIS管道或C＃应用程序中做了很多内存，我支持将它放在一个单独的盒子上（所有ETL，而不仅仅是其中的一部分）。如果您只是使用SSIS来调用数据库上的存储过程，那么可以将它保留在同一系统上。

话虽这么说，除非有一个压倒性的理由，否则我会避免将ETL分成盒子。它增加了很多复杂性，没有太大的好处（通常）。

话虽这么说，如果你需要运行C＃的东西，你总是可以使用SSIS中的脚本任务来控制它的执行。

Answer 4

我们通过将DTS软件包放在与SSIS服务器相同的服务器上来实现SSIS，并且我们有winservice离开另一台服务器并远程执行DTS软件包。