我刚接触SSIS，有两个问题
1.我想将1，25，000行从一个表传输到同一个数据库中的另一个表。但是当我使用Data Flow Task时，花费了太多的时间。我尝试使用ADO NET Destination和OLE DB Destination，但是性能不可接受。当我在Execute SQL Task中编写等效查询时，它提供了可接受的性能。为什么性能会有如此大的差异？
INSERT INTO表1从表2中选择 *
1.基于第一个观察，我改变了我的包。它完全由Execute SQL Tasks组成，要么带有直接查询，要么带有存储过程。如果我可以只使用Execute SQL Task解决我的问题，那么为什么要使用SSIS呢？正如许多文档和文章所指出的那样。我认为它可靠、易于维护，而且相对较快。
2条答案
按热度按时间xdnvmnnf1#
性能差异
有许多因素可能导致“直接”数据流任务和等效的执行SQL任务的性能下降。
1.网络延迟。您正在同一服务器和示例上执行从表b向表a的插入。在执行SQL任务中，我可以在服务器B上运行一个包，从服务器A查询125万行，然后通过网络将这些行传输到服务器B。然后，这些数据将被传输回如果您的网络很差，数据量很大（尤其是二进制类型），或者只是服务器之间的距离很远（服务器A在美国，服务器B在印度），那么性能就会很差
1.内存不足。假设包与目标/源数据库在同一服务器上执行，但由于数据流任务是内存中引擎，因此速度仍然可能很慢。这意味着，所有要从源流向目标的数据都将进入内存。SSIS可以获得的内存越多，速度就越快。但是，它将不得不与操作系统以及SQL Server本身争夺内存分配。尽管SSIS是SQL Server集成服务，它与SQL Server数据库不在同一内存空间中运行。如果您的服务器分配了10 GB内存，操作系统使用了2GB，而SQL Server要求使用8 GB，SSIS几乎没有操作空间。它不能要求SQL Server给予它的一些内存，这样操作系统就必须在数据涓涓细流通过狭窄的数据管道移动时分页。
1.劣质目标。根据您使用的SSIS版本，OLE DB目标的默认访问模式为“表或视图”。这是一个很好的设置，可以尝试防止低级锁升级为表锁。但是，这导致逐行插入的痛苦（发送1250万个唯一的insert语句）。与
Execute SQL Task的INSERT INTO的基于集合的方法形成对比。SSIS的较新版本默认访问方法为“Fast”这将表现得更像基于集合的等效项，并产生更好的性能。1.调试。在BIDS/SSDT中运行包会产生开销。包的执行会被 Package 在DTS调试主机中。这可能会导致包执行速度“相当慢”。对于执行SQL任务，调试器所能做的并不多--它运行或不运行。对于数据流，调试器可以检查、监视等，这会减少可用内存量（请参阅第2部分），并且由于执行各种检查而使其速度变慢。若要获得更准确的比较，请始终从命令行（dtexec. exe/file MyPackage.dtsx）运行包，或从SQL Server代理对其进行调度。
Package 设计
一个SSIS包本身并没有什么问题。如果通过运行查询可以很容易地解决这个问题，那么我会完全放弃SSIS，编写适当的存储过程，用SQL代理调度它，然后就可以完成了。
也许吧。我仍然喜欢使用SSIS，即使是像这样的“简单”案例，因为它可以确保一致的可交付性。这听起来可能不多，但从维护的Angular 来看，知道与数据有关的 * 所有东西 * 都包含在这些源代码控制的SSIS包中是很好的。我不必记住或训练新手任务A-C是“简单的”因此，它们是从SQL代理作业调用的存储过程。任务D-J（或者是K）甚至比这更简单，因此，只需在代理作业中执行“行内”查询以加载数据，然后我们就有了用于其余内容的包。除了Service Broker和一些Web服务之外，这些也会更新数据库。我年纪越大，接触的地方越多，我就越能在一致的，即使矫枉过正的解决方案交付方法中找到价值。
性能并不是一切，但是SSIS团队确实使用SSIS设置了ETL基准，因此它绝对有能力快速推送一些数据。
随着这个答案越来越长，我将简单地把它留着，因为SSIS和数据流相对于直接TSQL的优势是本机的，开箱即用
在我看来很难打败他们。
lztngnrs2#
如果要在“参数Map”选项卡中将SSIS变量作为参数传递，并通过表达式将值分配给这些变量，则执行SQL任务将花费大量时间来计算该表达式。请使用表达式任务（单独）分配变量，而不要在“变量”选项卡中使用表达式。