SQL Server2005整合服务: 性能优化技术

SQL Server2005整合服务: 性能优化技术
整合服务: 性能优化技术 【适用于SQL Server 2005】

摘要:本文描述了在使用SQL Server整合服务(SSIS)数据整合解决方案中常用的性能优化技术。

目录
简介
SSIS 引擎概述
运行时引擎
数据流引擎
缓存的使用.
执行树
评估设计选择
缓存大小
影响缓存大小的因素
缓存的指导方针
并行
配置设置
设计方法
评估性能
排错
可视的性能收集
总结

简 介
当你构建数据整合解决方案时，你的设计选择不仅要成功地满足功能上的需求，还要满足性能上的要求。为了做出正确的性能设计选择，你需要理解你所使用的数据整合工具的性能体系架构，这些技巧可以最大发出工具对系统资源的利用率，例如内存和CPU。
Microsoft® SQL Server™ 2005 整合服务(SSIS)为构建高性能的数据整合解决方案，提供丰富的开发环境来支持数据整合的完整功能和工作流引擎。为了满足特殊的数据整合场景的性能需求，SSIS提供了多种优化的机会来帮助你最大化资源利用率。
SSIS 引擎概述
在你利用特殊的调节SSIS包之前，了解SSIS架构是非常重要的。这个体系结构有2个重要的组件：运行时引擎和数据流引擎。
运行时引擎
运行时引擎是一个并行的控制流引擎，可以在SSIS中协调执行任务和工作单元，并管理实现这些任务的引擎线程。在极大程度上，运行时引擎的性能受SSIS外部条件的影响，例如网络带宽，并会影响例如数据库服务器，FTP服务器或邮件服务器的性能。当SSIS运行一个执行SQL语句的任务时，在向下继续运行前，它向目标数据库发送一个调用请求并等待数据库服务器的相应。在这种场景中，执行SQL语句任务的性能更多地依靠与查询执行的性能而不是SSIS运行时引擎。
数据流引擎
当你使用SSIS用于数据整合时，除了运行时引擎外，你可以使用数据流引擎管理数据的传递途径。数据流引擎通过在SSIS中特殊的数据流任务的来调用。当数据流任务之行时，SSIS数据流引擎从一个或多个数据源中抽取数据，完成所有对数据需要的转换，并将数据传递到一个或多个目的数据源。
在数据整合方案中，你可以在数据流引擎上花费大量的性能优化工作时间。就像运行时引擎一样，数据流引擎也被外部条件所影响，在SSIS中，有多种设置可以使你实现对于数据流引擎的性能优化来满足数据整合操作的需求
缓存的使用
数据流引擎使用了面向缓存的架构设计来有效的在内存中加载和操作数据集。在内存中处理的好处使你在数据整合的各个步骤中不需要数据的物理拷贝和中间状态的数据。这相当于数据流引擎操作数据时就像数据直接从数据源转移到目标数据源里。
当数据流通过传递管道，当要实现其他操作时，SSIS尽可能的尝试从预先在缓存中的重用数据。如何使用和重用缓存依赖于你在传递管道中使用的转换类型。
·         行转换 -行转化不是操作数据就是使用在这行可用的数据创建新的字段。SSIS组件中实现行转化的例子包括Derived Column，Data Conversion，Multicast和Lookup。当这些组件创建新列时，行转换不会创建其他额外的纪录。因为每个输出行和输入行有1：1的关系，行转换就是所说的同步转换。行转化在重用现存的缓存时有优势，并且不需要新的缓存复制数据来完成全部的转换。
·         部分模块转换 – 部分模块转化常用于数据集的合并。这种转换一般有多路的数据输入。所以他们的输出可能会比输入记录总数多或少，或是相等。. 因为数据的记录数量可能和输出的记录数量不相等，这种转换也被称为异步转换。在SSIS组件中实现部分模块转换的例子包括Merge，Merge Join和Union All。通过部分模块转换，转换的数据将被复制到新的缓存中，一个新的线程将引入数据流。
·         模块转换 -在创建任何输出记录前，模块转换必须读取和处理所有的输入记录。所有这种类型的转换将完成最多的工作并占用最多的可用资源。在SSIS组件中实现模块转换例子包括Aggregate和Sort。就像部分模块转换，部分模块转换也是使用了异步转换。同样，当模块转换发生时，输出数据被创建在缓存中，一个新的线程将引入数据流
转换不是只能分为同步或异步。数据源是一种特殊类型的异步组件。例如，关系型数据源组件创建2种不同的缓存：1个用于输出成功结果，1个用于输出异常结果。与之相比，目的数据源是一种特殊类型的同步组件。当你考察包的执行树后，你将看到数据源和目的数据源组件的交互。
执行树
执行树演示了你的包如何使用缓存和线程。当运行时，数据流引擎中在执行树中中止数据流任务操作。执行树指定了在包中缓存和线程的分配。每个执行树创建了新的缓存并可以执行在不同的线程中。当一个新的缓存被创建时，例如在传递添加了部分模块或模块转换，就需要额外的内存去处理这些数据转换；然而，还要注意每一个新的树也会添加额外的工作线程。
在图1和表1中考察事例描述的执行树，有2个员工数据集被合并，然后聚合后载入目地表。


图1: 实例包

注意:  在表中列出的执行树就是他们执行的顺序。

表1:执行树的定义



执行树的示例可以帮助你理解在普通的SSIS包中缓存的使用。示例也展示了在Union All这样的部分模块转换和Aggregate这样的全部模块中转换如何创建缓存和线程资源，以及像Derived Column这样不需要额外资源的行转换。
对于缓存的使用，执行树是非常有价值的。通过在数据流任务中开启包日志，然后选择管道执行树事件， 你可以显示你的包执行树。注意，直到你执行包时你才可以看到执行树。当你执行包后，你可以在Business Intelligence(BI) Development Studio中的事件日志窗口中看到相关的执行树。
评估设计选择
一旦你掌握了不同转换类型对包执行的影响，你可以做出更好的性能设计选择。在图2中，在实现同样的数据整合场景下，展现了对不同设计方法对性能的影响。


图2: 设计选择

表2: 设计评估


设计描述
在这个设计中，Script Component组件生成100,000,000行记录，首先传入一个Lookup组件。如果Lookup因为原记录中的值没有找到而失败，错误记录和会被传入到一个Derived Column转换来给错误记录指派一个默认值。当错误处理完成后，将于原有数据集合并，然后在将所有行加载到目的数据源。

像在Design Alternative 1中一样，这个设计也是用了Script Component来生成100,000,000行记录然后传入Lookup。
所有Lookup失败的记录会被忽略而不是将Lookup失败做为错误记录处理。然后使用Derived Column转换将在Lookup中生成的记录中有空值列指派一个默认值。
性能影响
在这个场景中有2个执行树，最大的性能瓶颈是在涉及为部分模块转换Union All时内存中额外的数据复制。

在这个解决方案中性能比Design Alternative 1中快21%。在这个场景中，有一个执行树，在这个操作中主要考虑到了避免无谓的创建新缓存的开销。

缓存大小
除了尽可能的使用行转换限制创建和使用的缓存数量外，在SSIS中你还能改变缓存的大小；更确切地说就是读入到缓存的记录数量。我们的目标就是尽可能的在单一缓存中读入更多地记录来有效的利用内存。
影响缓存大小的因素
执行时在从数据源读取数据前，SSIS基于一些列输入参数自动的调节缓存来完成最大化内存利用率。为了帮助SSIS尽可能的实现对内存的调整，你需要知道下列输入参数。
·         Estimated Row Size – Estimated Row Size 不是一个指定SSIS配置。而是SSIS在设计时基于从数据源收集的元数据计算的值。你可以通过尽早的识别可能的数据类型来收缩行的大小。这对平板文件数据源尤其重要，因为每列都会被识别为字符串数据类型自动的读入SSIS，除非你显示的配置列的数据类型。
·         DefaultMaxBufferRows – DefaultMaxBufferRows 是一个SSIS数据流任务的配置值，默认设置为10, 000条记录。SSIS 将Estimated Row Size 乘以DefaultMaxBufferRows 来粗略的获取每10, 000行数据你的数据集的大小。在没有理解和 DefaultMaxBufferSize 关系前，你不应该配置该值。
·         DefaultMaxBufferSize – DefaultMaxBufferSize 是另外一个SSIS数据流任务的配置值。默认情况DefaultMaxBufferSize 被自动设置为 10 MB。当你要配置这个设置时，要注意它的上界被一个SSIS的内部参数MaxBufferSize所限制，这个值为100MB，并且不能改变。
·         MinBufferSize –当MinBufferSize 没有配置时，这个参数也是非常重要的，因为SSIS使用这个内部参数来测量是否你的DefaultMaxBufferSize 配置的太低。MinBufferSize 通过你的操作系统虚拟内存分配方法的粒度来定义。
依赖于你配置的这些输入参数，SSIS在执行时使用下列场景调节缓存的大小。
·         场景 1 –当Estimated Row Size * DefaultMaxBufferRows 大于MaxBufferSize 时，SSIS会减少存在缓存中的行数来管理内存。
例如，如果SSIS计算出每条记录的Estimated Row Size为15, 000字节，预计的缓存大小将是15, 000字节/行*10, 000行，大约是143 MB，大约是DefaultMaxBufferSize 100MB的1.5倍。因为预计的大小超过了DefaultMaxBufferSize ，SSIS通过一个大约1.5的因素来减少在内存中的记录数来保持100MB的限制。在这个场景中，每个缓存的大小可以处理大约6, 600条记录。注意，当这个调整发生时，SSIS并不知道在你的数据源中有多少条记录。当数据实际在处理时，SSIS创建所需要的缓存实例数量来处理数据集合。在这个示例中，如果你有200, 000条源记录，SSIS创建大约30个这种缓存类型的实例。一个缓存类型只是引用了缓存的列的数据结构。例如，一个有A，B，C列的缓存被SSIS认为是ABC类型的缓存。实际上，SSIS将会更进一步并指派给每个缓存类型一个数字值。
·         场景2 – 当Estimated Row Size * DefaultMaxBufferRows 小于MinBufferSize 时， SSIS 会增加将保存在缓存中的行数来最大化内存的利用率。
例如，如果Estimated Row Size为5字节每行（比之前的例子小得多），5字节/行* 10, 000 行，大约是48KB，小于MinBufferSize 的64KB。因为预计的大小小于MinBufferSize ，SSIS会细微的增加记录来达到64KB的限制。
·         场景3 –如果 Estimated Row Size * DefaultMaxBufferRows 的值处在MinBufferSize 和DefaultMaxBufferSize 值之间，SSIS尝试通过数倍的MinBufferSize 调整缓存的大小来接近Estimated Row Size * DefaultMaxBufferRows 的结果，这样可以提高内存利用率。
例如，如果你的Estimated Row Size是500字节/行，500字节/行*10, 000行，大约是4.8 MB小于DefaultMaxBufferSize 的10MB，但是大于MinBufferSize 的64KB。在这个场景中，SSIS尽可能将会调整缓存到4.8MB。
缓存的指导方针
实际上，你必须基于你的环境测试这些设置，但是你可以通过下列方法来开始。
·         通过减少不需要的列和正确的配置数据类型来尽可能的减少Estimated Row Size大小。在操作运行节省内存资源前要通过任何机会来减少源数据集的大小。
·         开始时使用SSIS的DefaultMaxBufferRows和DefaultMaxBufferSize默认值。启用包日志并激活BufferSizeTuning 属性。这个属性将在日志中添加能展示在什么位置SSIS调整缓存大小的信息。你将看到下列的属性。
·         如果你的数据整合类似于场景1，你将看到：在缓存类型0种的行将导致缓存大小大于配置的最大值。在这种缓存类型中只能有383行。
·         如果你的数据整合类似于场景2，你将看到：在缓存类型3种的行将导致缓存大小小于分配的最小值65536字节。在这种缓存类型中只能有1365行。注意65536字节是执行这个包的机器中的MinBufferSize值。
·         为了尽可能的在缓存中获取更多的记录，可以通过调节DefaultMaxBufferRows和DefaultMaxBufferSize的值来实现。如果这些值设置过小将导致SSIS创建很多小块的缓存，而不是在有足够内存时我们需要的少量的大块缓存。
·         当你调整了DefaultMaxBufferRows和DefaultMaxBufferSize的值，要意识到，一旦超过了MaxBufferSize，MaxNumberofRows设置将不再有意义，因为SSIS总为了最大化内存的利用率会按比例缩小每个缓存中的记录数量。
·         注意，DefaultMaxBufferRows和DefaultMaxBufferSize 在每一个数据流任务中需要分别配置。当你在一个数据流任务中从多个数据源集成数据时，这2个设置将影响在任务中的数据源组件和转换。也要注意每个缓存有多少行是和每个缓存类型相关的。
并行
并行是在你的数据整合操作中为提升性能所使用的非常好的一项技术。SSIS自身支持对包，任务和转换的并行执行。成功的并行窍门就是通过配置操作限制你的系统资源。
配置设置
在SSIS中，每个包的控制流通过MaxConcurrentExecutables设置指定每个包在并行时SSIS最大线程数量。默认情况下，这个值设为-1，代表逻辑处理器的数量加2。
如果SSIS运行在一台独立的服务器上，并且你有很多运行在并行的操作，一些操作需要等待外部资源的相应，这时你可以提高这个值。另一方面，如果你没有独立的SSIS服务器，并且你的数据整合应用于其他的应用同时运行时，你可能需要减少这个值来避免资源冲突。
设计方法
当你设计包的并行时，你需要确定在包中的部分操作或是全部操作都运行在并行环境中。当确定了缓存的大小后，你还要考虑系统资源，并行将是最佳的选择。
在一个包中从源数据库中读取数据，汇总数据并将数据分为4个部分，然后将聚合的数据集加载到不同的目的表，在这各种操作中要考虑使用并行时我们要考虑不同设计方法的折衷。

注意: 这些信息是在Unisys研究中心使用了用于研究64位性能的Unisys ES7000服务器所收集的。更多关于这个案例研究的信息，请访问http://www.unisys.com/eprise/main/admin/corporate/doc/ELTSQL.pdf!href(http://www.unisys.com/eprise/main/admin/corporate/doc/ELTSQL.pdf)获取ETL性能白皮书。在AMD 64位多核平台上的类似白皮书，请查看AMD的网站来获取更新信息 http://www.amd.com/us-en/!href(http://www.amd.com/us-en/)。

·         在目标操作上使用并行-在图3中显示这种设计方法，数据从数据源中被读入，传递到通过分组操作生成4个不同的数据集的聚合转换中，然后将数据加载到4个目的表中。在这个设计中只有一个并行的操作就是从聚合的数据中向4个目的表中加载数据。从数据源中分解和聚合计算操作无法使用并行操作。


图3: 在目标操作上使用并行

如果你使用的机器具有多个CPU，那么这种方法将不能使你有效的利用CPU。当你的服务器有内存限制时并且如果你有多个源自于自身的聚合转换时，这种方法是最好的。聚合转换时用最低的粒度来创建聚合并且派生出所有相关的聚合。例如，如果你有2个聚合：(1)以年聚合销售数据；（2）以年和地理方式聚合销售数据，聚合转换将自动创建以年和地理方式的汇总，并且从中派生出年的汇总。

·         部分并行操作 -图4中显示了这种设计方法，数据从一个数据源中读入，然后传递到一个多播的转换中创建4种同样的结果集并传递到4个不同的聚合转换，最后加载到不同的4个目标表。


图4: 部分并行操作

不管你怎么想的，在这种场景中只有在加载数据到目标表这个操作是并行的。从数据源中读取数据，完成多播，聚合数据每一个操作都是在同样的执行树中，所以共享同样的内存和线程。
如果在这个场景中，你想使用并行运行聚合，你可以在Multicast后引入Union All转换来创建新的执行树。记住Union All是一个部分模块转换，将会创建一个新的执行树。当你引入Union All后，数据将被复制到额外的缓存中，但是你可以获得额外的线程来使用并行完成聚合。
·         在所有操作中都使用并行 -图5中显示了这种设计方法，有4个独立的操作集合，每个操作集合都会从数据源中读取数据，聚合数据和加在数据不同的目的数据源中。


图5 –在所有操作中都使用并行

在这个场景中，所有的操作都是在并行下完成的；数据源抽取，聚合，目标数据库的插入。如果你的服务器没有内存的限制，并且有多块CPU，这种方法可以提供最佳的性能解决方案；然而你在处理每个操作和4次读取同样的数据集时，也许有一些资源上的浪费。
·         优化最慢的操作 -做为统一并行的选择，你也许会考虑使用图6种的设计方法，在你的包中运行最慢的组件上利用并行。在这种设计方法中，在4个聚合中有1个被认为是最慢的聚合，被独立到一个分开的数据流中。


图6: 优化最慢的操作
为了在新的数据流中提供好的性能，聚合通过基于一个键的范围进行条件分割成2个部分。每个聚合计算完成后，通过Union All转换将数据和并。结果数据被加载到目的数据源。
这种混合的设计方法演示了如何在不浪费机器资源的情况下对特殊的操作中应用并行获取最佳性的方法。
评估性能
成功进行性能优化的最重要的一个概念是如何测量和监视性能。当你对你的SSIS包做出性能调整时，你需要一套机制测量是否需要对你的数据包进行修改。
排错
性能排错的一个主要技术是在你的包中独立执行不同的部分找到执行最慢的操作。当你隔离执行不同操作时，你可以跟踪创建性能基线。为了隔离SSIS操作，要考虑下面的步骤。
1.      确定整个包地执行速度 -当你执行你的包时，全部执行速度就是从开始到结束时间的总和。
全部执行速度= 源读取速度+ 转换速度+ 写入目的速度
例如，如果你执行1个包，从开始到结束花费了5分钟，整个的执行速度就是5分钟。
2.      隔离源和转换速度 –你能通过下列步骤找到SSIS从源读取数据和完成转换的速度。
a.      创建你的原始包的副本。
b.      删除目的数据源。如果有多个目的数据源，一次隔离一个。
c.      使用RowCount转换代替原有的目的数据源。
d.      测量从数据源通过转换到RowCount的执行性能。
测量结果是源和转换的速度。如果这个操作太慢并且你还有很多资源(例如CPU)，考虑应用上面描述的一些技术（例如分区或引入新的执行树）来增加数据吞吐量。
当你排措时，你将在你的包的不同位置上使用RowCount转换来隔离性能的瓶颈。RowCount转换只是对从管道中传递的数据进行简单的计数。这不会带来其他的需要测量的性能开销。
例如，当完成这些步骤时，你可以找到从源读取数据并完成转换花费了4分钟。和整个执行速度5分钟比较，80%的执行时间花费在了读取数据和转换数据上。通过简单的转化，你可以计算出写入目的的速度。
3.      计算目的时间 –一旦你知道了整个的执行速度和累积的源和转换速度，你可以像下面一样计算出向目的加载数据的时间：
写入目的速度 = 全部执行速度 – (累计得源读取和转换速度)
例如，通过你在步骤1和步骤2中的测量，你可以像下面的方法计算写入目的的速度：
写入目的速度= 5 分钟 – (4 分钟) = 1 分钟
4.      隔离源读取速度–在步骤2中你测量了累积的源读取和转换速度。因为这是一个累积的数量，你不知道花在读取数据和花在转换数据上的确切时间。为了找到从数据源中读取数据的速度，可以按照下列的步骤。
e.      创建你的原始包的副本。
f.       删除所有的转换和目的写入。
g.      使用RowCount转换代替转换和写入。
h.      测量从源读取到RowCount的执行性能。
这个结果就是源读取的速度。这是理论上你的数据流工作的最快速度。如果这个速度太慢，你将需要着重于关心优化数据适配器来让它更快地返回数据。例如，通过这种处理，你可能找到花费了15秒用于从文件数据源中读取数据。当和全部执行时间5分钟相比，你了解到读取数据花费了整个执行时间的6%。现在你可以简单的计算出实际上转换数据所花费的时间。
5.      计算转换速度 - 通过隔离源读取速度和累计源读取和转换的时间，你可以像下面这样计算出所有转换的速度：
转换速度 = (累计源读取和转换速度) – 源读取速度
例如，通过我们在步骤1-3中的测量，你可以计算出转换速度：
转换速度 = 4 分钟 – (15 秒) = 3.75 分钟
在表2中你可以找到主要的速度参数的汇总。
表 2 – 性能汇总


6.      隔离个别的转换 –如果你需要确定个别转换的性能做更进一步的排错，你可以按照下列操作。
a.      创建你在步骤4隔离源和转换时使用的包副本。
b.      删除一个转换。
c.      不影响其它的转换和目的写入，使用RowCount转换代替删除的转换。
d.      测量执行性能。
e.      用执行世间和原有的源读取和转换速度比较。差距就是着这个转换的性能。
例如，假设60%多的执行时间花费在转换中，你要找到那个转换耗费了最多的时间。你删除了一个Lookup转换并找到了累积源写入和转换速度。一个为4分钟，一个为2.5分钟。比较这2个场景，你推断出你的Lookup转换花费了1.5分钟。表3中显示了隔离Lookup的性能汇总。

表3 –隔离Lookup性能汇总


基于这些信息你调整了Lookup转换的缓存并将性能从1.5分钟提高到30秒。通过这些，在表4中展示了你将执行时间提高了20%。
表4 – 优化后的性能汇总


通过这个例子演示了在一个简单场景中如何隔离包的执行，你可以应用这些排错的原则到更复杂的包并能快速的识别那个组件是需要调整的。
可视的性能收集
当你改变并增强了你的设计，你还希望利用监视和日志记录包的执行情况。
·         SSIS 日志–SSIS允许通过不同的日志方法例如XML，SQL Server或者文本文件记录任务和包的执行。日志允许你查看包执行时间的性能和跟踪机器资源改变和数据量增加后的性能情况。SSIS提供了丰富的日志支持，当全部开启时会有昂贵的开销。先查看事件日志并只记录必需的事件信息。
·         SSIS 性能计数器–SSIS提供了一些性能计数器，你可以使用这些可视化的知道当包执行时多少资源被利用了。例如，你可以查看当包执行时读取的行数和正在使用的缓存数量。一个非常有用的特殊性能计数器叫做Buffers Spooled。当在包执行时Microsoft Windows®用尽了物理内存或处理执行包时用尽了虚拟内存时，SSIS开始将缓存转换到文件。一旦发生，性能会降得非常低，因此监视这个设置是一个好的想法来确认对你的操作是否有足够的内存。
·         SQL Server Profiler –当你从SQL Server中抽取数据和加载数据时，你可以使用SQL Server Profiler查看在SQL Server后台的操作和查询计划。当你监视了数据库的活动，你可以找到在SQL Server RDBMS中优化性能的机会，例如修改索引等。
总 结
性能优化是一项在设计选择和资源可用性上的持续平衡操作。为了帮助你管理这个平衡操作，SSIS提供了一套可扩展的数据架构，使你可以构建高性能的数据整合解决方案。通过理解SSIS性能架构如何平衡内存和CPU，你可以利用各种性能优化地方法做出个好的设计选择来最大化你的系统资源利用率。你可以正确的理解当你的解决方案在未来增长放大的需求。
更多信息在：
http://www.microsoft.com/sql/!href(http://www.microsoft.com/sql/)
!href(mailto: sqlfback@microsoft.com?subject=Feedback: Integration Services: Performance Tuning Techniques)

作者: Elizabeth Vitt, Intellimentum and Hitachi Corporation
投稿者: Donald Farmer, Microsoft Corporation; Ashvini Sharma, Microsoft Corporation; Stacia Misner, Hitachi Consulting

关于作者
Elizabeth Vitt, Intellimentum
Elizabeth Vitt 在商业智能上有10年的商业开发，项目管理，顾问和培训经验。在零售，制造业，金融服务等行业中都有BI的实施经验。她也是专门从事数据仓库，ETL和OLAP设计的培训师。Vitt女士还是Microsoft 商业智能产品的Microsoft官方课程作者，并在MSPress出版了 Business Intelligence: Making Better Decisions Faster 。在SQL Server 2005发布前，Vitt女士已经成功地为一些客户实施了SQL Server 2005。
Hitachi Consulting
Hitachi Consulting, 是Hitachi, Ltd. (NYSE: HIT)的全球顾问公司，在Global 2000公司中跨多个行业提供业务和IT解决方案中是公认的领先者。Hitachi Consulting积累了10年的业务处理，水平行业经验和领先的技术，可以更好的理解每个公司独特的业务需求。从业务策略的开发和应用程序的部署，Hitachi的顾问可以帮助客户快速的认识可度量的业务价值并完成预期的投资回报率。
Hitachi Consulting 是在商业智能方面的微软金牌合作伙伴，还为Microsoft SQL Server 2005 商业智能培需课程提供课程和讲师。Hitachi Consulting也是一个有经验的系统集成商，并成功的参与了为在Microsoft Technology Adoption Program (TAP)计划的公司实施SQL Server 2005 BI的工作。
Hitachi Consulting 提供了以客户为中心的合作，通过每一次合作传递知识。
更多信息，请访问  www.hitachiconsulting.com!href(http://www.hitachiconsulting.com). Hitachi Consulting – Inspiring your next success®

版权声明
本文档中的信息（包括 URL 及其他 Internet 网站参考资料）可能随时变更，恕不另行通知。使用本文档的全部风险或因此导致的后果均由用户自行承担。
本文档仅供参考，Microsoft 对本文档中的信息不提供任何明示或暗示的保证。
用户必须遵守所有适用的著作权法。在不限制著作权法所保障的权利下，未经 Microsoft Corporation 书面许可，不得将本文档的任何部分复制、存储或引入检索系统，或以任何形式、手段 (电子、机械、影印、录音等等) 或基于任何目，转发本文任何部分。
Microsoft 可能拥有本文档主体的涉及的专利、专利使用、商标、著作权或其他知识产权。除非在Microsoft书面许可协议中明确提到，否则本文档并不向您提供其中的任何专利、商标、版权或其他知识产权。
除非注解，否则这里描述的样例公司、企业、产品、域名称、电子邮件地址、徽标、人员、地点和事件纯属虚构，不要有意或推断，将其与真实的公司、企业、产品、域名称、电子邮件地址、徽标、人员、地点或事件相联系。
Ó 2005 Microsoft Corporation.  保留所有权利.
Microsoft, Excel, SharePoint, Visual Basic, Visual C++, Visual C#, Visual J#, Visual Studio, 和 Windows 均为Microsoft Corporation 在美国和/或其他国家的注册商标或商标。
此处提到的实际公司名称和产品名称可能使其所有者的商标。