我是SSIS的新手并且有一对问题
我想在同一个数据库中将1,25,000行从一个表传输到另一个表。但是当我使用Data Flow Task
时,需要花费太多时间。我尝试使用ADO NET Destination
和OLE DB Destination
,但性能无法接受。当我在Execute SQL Task
内写出等效查询时,它提供了可接受的性能。为什么性能会有这么大差异。
INSERT INTO table1 select * from table2
根据第一次观察,我改变了我的包裹。它完全由Execute SQL Tasks
组成,可以是直接查询,也可以是存储过程。如果我只使用Execute SQL Task
来解决我的问题,那么为什么会像许多文档和文章那样使用SSIS。我看到它可靠,易于维护且速度相对较快。
答案 0 :(得分:22)
有许多事情可能导致“直接”数据流任务和等效的执行SQL任务的性能。
Execute SQL Task
INSERT INTO的基于集合的方法形成对比。更新版本的SSIS默认访问目标的“快速”版本的方法。这将更像是基于集合的等价物,并且可以产生更好的性能。仅仅Execute SQL Task
的SSIS包没有任何内在错误。如果通过运行查询很容易解决问题,那么我将完全放弃SSIS并编写适当的存储过程并使用SQL Agent进行安排并完成。
也许。即使对于像这样的“简单”案例,我仍然喜欢使用SSIS,它可以确保一致的可交付成果。这听起来可能不是很多,但从维护的角度来看,很高兴知道这些源控制的SSIS包中包含了与数据混淆的所有。我不必记住或训练任务A-C“简单”的新人,因此他们是从SQL Agent作业调用的存储过程。任务D-J,或者它是K,甚至比这更简单,所以它只是代理作业中的“在线”查询来加载数据,然后我们有其他东西的包。除Service Broker事物和一些Web服务外,它们也会更新数据库。我得到的年龄越大,我接触的地方越多,我就越能找到一致的,即使是过度杀戮的解决方案交付方法的价值。
性能并非一切,但SSIS团队确实使用SSIS设置了ETL基准,因此它绝对有能力匆忙推送一些数据。
由于这个答案越来越长,我只是将其视为SSIS的优势而且直接TSQL上的数据流是原生的,开箱即用
我的钱很难打败那些人。
答案 1 :(得分:0)
如果要在“参数映射”选项卡中将SSIS变量作为参数传递,并通过表达式将值分配给这些变量,则执行SQL任务会花费大量时间来评估该表达式。 (单独)使用表达式任务分配变量,而不是在“变量”选项卡中使用表达式。