与在执行SQL任务中编写sql查询相比,SSIS中的DataFlow任务非常慢

Question

我是SSIS的新手并且有一对问题

1. 我想在同一个数据库中将1,25,000行从一个表传输到另一个表.但是当我使用时Data Flow Task,它需要花费太多时间.我试过使用ADO NET Destination和一个OLE DB Destination但是性能是不可接受的.当我在其中编写等效查询时,Execute SQL Task它提供了可接受的性能.为什么性能会有这么大差异.

   INSERT INTO table1 select*from table2

2. 根据第一次观察,我改变了我的包裹.它完全由Execute SQL Tasks直接查询或存储过程组成.如果我只用the来解决我的问题Execute SQL Task,那么为什么人们会像许多文件和文章所说的那样使用SSIS.我看到它可靠,易于维护且速度相对较快.

Answer 1

性能差异

有许多事情可能导致"直接"数据流任务和等效的执行SQL任务的性能.

1. 网络延迟.您正在同一服务器和实例上的表b中执行insert a table a.在执行SQL任务中,该工作将完全在同一台机器上执行.我可以在服务器B上运行一个包,它从服务器A查询1.25M行,然后通过网络流到服务器B.然后,这些数据将流回服务器A进行相应的INSERT操作.如果您的网络很差,数据范围很广 - 特别是二进制类型,或者服务器之间距离很远(服务器A在美国,服务器B在印度),性能会很差
2. 记忆饥饿.假设程序包在与目标/源数据库相同的服务器上执行,它仍然可能很慢,因为数据流任务是内存引擎.意思是,所有从源流到目的地的数据都将进入内存.SSIS可以获得的内存越多,它就越快.但是,它必须与操作系统进行内存分配以及SQL Server本身.即使SSIS是SQL Server Integration Services,它也不会在与SQL Server数据库相同的内存空间中运行.如果您的服务器拥有10GB的内存分配给它和操作系统使用2GB和SQL Server声称8GB,很少有余地SSIS操作.它不能要求SQL Server放弃一些内存,因此操作系统必须分页,而数据的涓流通过一个受限制的数据管道.
3. 伪劣目的地.根据您使用的SSIS版本,OLE DB目标的默认访问模式为"表或视图".这是一个很好的设置,可以尝试阻止低级锁升级到表锁.但是,这会导致行插入令人痛苦(要发送1.25M唯一插入语句).与Execute SQL TaskINSERT INTO 的基于集合的方法形成对比.更新版本的SSIS默认访问目标的"快速"版本的方法.这将更像基于集合的等价物,并产生更好的性能.
4. OLE DB命令转换.有一个OLE DB目标,有些人将其与OLE DB命令转换混淆.这是两个非常不同的组件,具有不同的用途.前者是目的地并消耗所有数据.它可以非常快.后者总是 RBAR.它将对流经它的每一行执行单例操作.
5. 调试.在BIDS/SSDT中运行包的开销很大.包执行包装在DTS调试主机中.这可能导致程序包执行"不可忽视"的减速.调试器无法对执行SQL任务执行任何操作 - 它运行或不执行.数据流,它可以检查,监视等大量内存,这减少了可用的内存量(参见第2页),并且由于它正在执行各种检查而减慢了速度.要获得更准确的比较,请始终从命令行(dtexec.exe /文件MyPackage.dtsx)运行包或从SQL Server代理安排它.

包装设计

SSIS包没有任何内在错误,只是Execute SQL Tasks.如果通过运行查询很容易解决问题,那么我将完全放弃SSIS并编写适当的存储过程并使用SQL Agent进行调度并完成.

也许.即使对于像这样的"简单"案例,我仍然喜欢使用SSIS,它可以确保一致的可交付成果.这可能听起来不是很多,但从维护的角度来看,知道所有与数据混淆的内容都包含在这些源控制的SSIS包中可能会很好.我不必记住或训练任务AC"简单"的新人,因此他们是从SQL Agent作业调用的存储过程.任务DJ,或者它是K,甚至比这更简单,所以它只是代理作业中的"在线"查询来加载数据,然后我们有其他东西的包.除Service Broker事物和一些Web服务外,它们也会更新数据库.我得到的越老,我接触的地方越多,我就越能找到一致的,即使是过度杀戮的解决方案交付方法.

性能并非一切,但SSIS团队确实使用SSIS设置了ETL基准,因此它绝对有能力匆忙推送一些数据.

由于这个答案长得很长,我只是将它留作SSIS的优势,直接TSQL上的数据流是原生的,开箱即用

• 记录
• 错误处理
• 组态
• 并行

我的钱很难打败那些人.