本文将讨论如何设计高性能、并行处理能力强的SSIS包，识别性能差劲的SSIS包，SSIS包中的分布式事务，以及如何在包执行失败的地方重新开始包的执行。
第一篇:SQL Server集成服务最佳实践:语句优化
第二篇:SQL Server的SSIS最佳实践:优化数据表
最佳实践10：使用并行执行提升性能
通过并行执行包和数据流任务，SSIS实现了较好的性能，SSIS包和数据流任务的并行执行可以由SSIS的两个属性进行控制。
MaxConcurrentExecutables：它指定一个包内的最大并行执行数（包内不同的任务），即SSIS运行引擎可以创建的线程数量，如果你的包制定的是连续工作流，这些属性不会有任何差异，但如果你的包制定了并行任务，这个属性就需要改变，其默认值是-1，表示所有可用的处理器数+2，如果你的处理器支持超线程，那它就是所有逻辑处理器的数量+2。
EngineThreads：MaxConcurrentExecutables是SSIS运行时引擎并行执行时使用的属性，EngineThreads是数据管道引擎使用的属性，在SSIS 2005中默认值是5，在SSIS 2008中默认值是10，这个属性指定源线程（从源抽取数据）和工作线程（执行数据转换和加载）的数量，这些线程是由数据流管道引擎创建的，管理数据流任务中数据的传输和转换。如果EngineThreads的值为5，表示最大可以创建5个源线程和5个工作线程。注意，这个属性仅仅是给数据流管道引擎的一个建议，管道引擎可以视需求创建更多或更少的线程。
假设你有一个包，它有5个并行数据流任务，MaxConcurrentExecutables属性的值为3，当你开始执行这个包时，运行时将会并行启动3个数据流任务，任何数据流任务执行完时，下一个等待的数据流任务就会启动，以此类推，此时在数据流任务内发生的事情是由EngineThreads属性控制的。在最佳实践6中我已经谈到，一个数据流任务会被拆分成多个执行树，数据流管道引擎会创建源和工作线程，它们的数量等于EngineThreads属性的值，也就是可以并行执行的执行树的数量。如果你将EngineThreads的值设为5，那么你的数据流任务就会被拆分成5个执行树，但并不意味着所有执行树会并行执行。
在修改这些属性时一定要非常小心，在应用到生产环境之前进行彻底的测试是必要的，因为如何正确配置了这些属性，在系统有限的资源限制下，通过并行执行可以提高性能，但如果配置不当，也会损害性能，因为从一个线程到另一个线程存在太多的上下文切换，建议创建并行执行的线程数量不要超过可用的处理器数量。
最佳实践11：什么时候使用时间日志，什么时候应该避免使用事件日志
日志时诊断运行期间发生的问题的最佳方法，当你的代码没有按预期执行时，它可以帮上大忙。现在，几乎所有的编程语言都提供了日志机制，通过日志确定异常问题或运行失败的根本原因。SSIS允许你开启日志功能，它允许你选择不同的事件和组件记录日志，并且可以指定日志的存放位置。
虽然日志可以帮你确定问题的根本原因，但它会引起性能下降，特别是如果过度使用日志，性能下降会更明显，因此我建议你仅当必要时才开启日志功能，你可以动态设置LoggingMode属性的值来启用或禁用日志功能，当你怀疑某个包有问题时，你可以开启日志功能，并选中合适的事件进行记录。
最佳实践12：使用性能计数器监控SSIS性能
除了日志可以进行性能诊断外，SSIS还引入了性能计数器来监控SSIS运行时和数据流管道引擎的性能。例如，SSIS包实例计数器表示运行在系统上的SSIS包数量，行读取和行写入计数器分别表示来自源的总行数和写入到目标的总行数，缓冲区使用和缓冲区内存计数器分别表示创建的总缓冲区数量和缓冲区使用的内存大小，缓冲区输出是一个非常重要的计数器，表示当物理内存不足时写入到磁盘的缓冲区数量，BLOB字节读、BLOB字节写和BLOB文件使用计数器分别表示BLOB数据传输时BLOB字节读、写和数据流引擎目前在使用的用于输出BLOB数据的文件的数量。
如果你从安装有SQL Server和SSIS的Windows Server 2003升级到Windows Server 2008，SSIS性能计数器将会消失，因为升级过程移除了这些性能计数器，如果想找回这些性能计数器，请参考这篇知识库文章(http://support.microsoft.com/kb/955632)。
最佳实践13：SSIS中的分布式事务及其影响
SSIS允许你将多个可执行程序组合到一起，然后通过分布式事务在一个事务中执行，你需要启动Windows服务中的分布式事务协调处理器服务，起初一听起来感觉很酷，但它可能会有阻塞问题，特别是当某个任务的执行周期很长时，很容易发生阻塞。例如，假设在队列中你有一组数据流任务，一个Web Service任务，然后又是一个数据流任务，第一个数据流任务从源抽取数据，需要几分钟时间，Web Service任务从一个Web Service抽取数据，需要花几个小时，最后的数据流任务合并这些数据，并将它们上载到最终表中。现在如果你在一个事务中执行这三个任务，资源将会被第一个任务锁定，直到其结束，即使它不需要Web Service任务执行需要的资源。
因此即使SSIS提供了分布式事务的功能，但也应该谨慎使用，即使你真要使用它，也要及时将任务清除出组，并要谨慎设置IsolationLevel属性。我的建议是尽可能避免使用这个特性，转而寻求其他替代解决方案。
最佳实践14：检查点特性如何帮助包重启
SSIS有一个很酷的新特性叫做检查点(Checkpoint)，它允许你的包在下次执行时，从上次失败的地方开始启动，这样可以节省不少执行时间。你可以通过设置包的三个属性(CheckpointFileName，CheckpointUsage 和 SaveCheckpoints)开启用这个新特性，除此之外，你还需要将所有需要重启任务的FailPackageOnFailure属性设为True，设置了这个属性后，执行失败时会将相关信息捕获到检查点文件中，下次执行时就从上次失败的地方开始执行起走。
那它是如何工作的呢?当你为某个包启用检查点属性后，执行状态会写入到检查点文件中，这个文件的名字和位置是通过CheckpointFileName属性指定的。下一次执行时，运行时引擎会参考检查点文件，在重新执行包之前，先查看最后一次执行的状态，如果它发现最后一次执行的状态为失败，它就知道最后一次失败的地方，然后就从那个地方重新开始执行。如果在下一次执行前你删除了这个文件，包将会从头开始执行。
启用这个特性后，在下一次执行时，你可以节省大量的时间，因为它会跳过执行成功的步骤。这里需要注意的是，你可以让一个任务加入检查点，包括数据流任务，但它不能应用到数据流任务内，即你只能在数据流任务级别启用它，不能在数据流任务内部使用检查点。假设你有一个数据流任务，并将FailPackageOnFailure属性设为True让其加入检查点，现在在数据流任务内，你有5个连续转换，前四个都执行成功了，在第五个时执行失败了，在下一次执行时，还是会从第一个转换开始执行，前四个转换会再执行一次。