我对 SSIS 有点陌生。我在 SQL Server 上有很多“开发”、构建、查询、调整性能，但不是管理/整体性能建模的大师。
所以这是我的问题 --- SSIS 包是否应该在与数据仓库（SQL 服务器数据库）相同的服务器上运行？
一方面，我已经收到一条神秘的错误消息，即 SSIS 中的某些“批量插入”任务只能针对本地数据库运行。也许这可以解决。也许它不能而且更快，因此将 ETL 放在与 db 相同的盒子上。
第二 --- 即使可以解决这个问题，无论如何将 ETL 放在与数据库相同的服务器上不是更快吗？或者除非在地理上尽可能接近？（即不是不同的大陆）。
特别是，ETL 在一夜之间运行，而数据库不是在一夜之间运行的（但是可能是备份进程）——但我预计彼此之间不会有太多的绊脚石。
如果批量插入任务只能在本地数据库上完成，那么测试/开发环境是否也需要在数据库服务器上设置？只是想知道什么是明智的。这是一家较小的商店，但我们会做一些事情。
哦，天哪，不，不要使用 SQL Server 目标。
在这一点上，微不足道的性能提升不值得它在加载数据时可能抛出的随机错误。OLE DB Destination 坚如磐石，提供出色的性能，并且不会遭受在 SQL Server Destination 中可能遇到的严重错误。这两个组件都可以将数据存储到 SQL Server 中，并且作为奖励，OLE DB 目标允许您从任何服务器运行 SSIS 包。
据我了解，SQL Server Destination 由一些非常聪明的巫毒教来工作。基本上，SSIS 引擎将数据加载到 SQL Server 中，并且由于SSIS超级承诺，双指发誓，数据是好的，所以它在数据库端进行最少的检查就被吸入了。
在 2005/2008 年困扰许多用户的问题是，在考虑插入数据和实际插入数据之间会发生一些事情，其中唯一报告的错误将是非常有见地的东西，例如“目标组件报告错误” 。但是，如果您立即重新启动程序包 - 不更改源或目标数据库，数据将正常加载。
至于架构师级别的问题，如果您使用 OLE DB 目标设计您的包，那么您可以比使用 SQL Server 目标更加灵活。为了获得良好的性能，SQL Server 最想要的一件事是什么？记忆。它可以在 RAM 中保存的信息越多，您将拥有更好的性能。SQL Server 会保留该内存多长时间？直到它重新启动或直到事情变得非常糟糕并且它被迫回馈以免服务器翻倒。
SQL Server Integration Services 是一个高性能的 ETL 引擎。它能够通过将数据全部保存在内存中而不是将其写入临时文件或表来非常快速地转换数据。它可以加载到内存中的数据行越多，它可以处理的并发更改就越多，您的吞吐量就会增加。但是，SSIS 资源消耗的一般模式是突发性的。当然，它可能看起来像饥饿的河马，因为它开始消耗它看到的所有东西，但它会运行 - 可能持续几分钟，也可能是几个小时，但一旦完成，所有资源都会被释放并可供一般处理。
由于 SSIS 是一个内存中的 ETL 工具，而 SQL Server 真的很喜欢内存，所以他们会打架。也许不是今天。服务器有 256 GB 的内存，SQL Server 只使用了 180，所以剩下 30% 的空间用于操作系统级别的进程，而 SSIS 在该空间中表现出色。
时间过去了，哦，业务正在增长，我们有新的网络事物整天在数据库上跳动，现在所有这些分析师都在使用 Access 攻击服务器并提取所有数据只是为了将其过滤为“今天”一次它进入他们的桌面。现在 SQL Server 要求越来越多的内存。您可以更改 SQL Server 中的最大服务器内存设置，以便为数据库引擎提供更多功能，但要为其他操作系统任务（如 SSIS）（它不在 SQL Server 的内存空间中运行）付出代价。
在某些时候，您可能会遇到这样一种情况，即您已经最大化了服务器的物理内存并减少了在该机器上运行的所有不是 SQL Server 的东西，而剩下的唯一东西就是 SSIS。那么现在怎么办？
在 OLE DB 目标世界中，您建立另一个实例（或使用现有的、税负较低的盒子），将您的包从服务器 1 部署/移动到 2。只要新盒子上存在权限和任何文件系统依赖项，您'重做。
在 SQL Server 目标世界中，您必须编辑每个包并更改目标组件、测试、完成任何更改管理审查流程，然后进行部署。
某些因素将成为 SSIS 性能的限制因素：内存、网络、存储、CPU。如果您有包通过网络提取 TB 的数据，只是为了写入 KB 的数据，是的，包的子集可能需要尽可能靠近源运行。
新手 SSIS 开发人员可以编写一些真正占用大量内存的包。例如，他们需要将来自 server1.database1 的客户和他们的订单放在一起，也在 server1.database1 中。如果他们只使用这些工具，他们可能有两个 OLE DB 源组件，它们将所有客户和所有订单都带入内存。要加入数据，他们需要使用合并组件。哦，但这对排序数据有要求。不用担心，工具箱中有一个方便的排序组件，因此我们将其中一个添加到我们的每个源中，然后连接连接。此时，我们只是将所有数据拉入内存，将它们全部排序在内存中，然后将可用内存减半到“异步/阻塞组件之前”和“阻塞组件之后”
没问题，他们重写并意识到他们可以在源中添加一个显式的 ORDER BY，并将其标记为这样，并消除两个 SORT，但他们仍然需要为连接付出代价。
或者，实际编写查询的人看到他们在做什么并说“让我们使用单个查询来获取这些数据。让数据库引擎使用它的索引来提高效率”