INFORMATICA调优要点（高级）

  接下来的这些条目是INFORMATICA 的高级调优建议。请极其谨慎地处理，每次试用一条建议。在没有试着使用初级和中级建议来提高INFORMATICA 的性能以前，不要尝试使用如下的高级建议。这些建议的实施可能需要系统管理员（SA）、数据库管理员（DBA）以及网络管理员之类的专家级人物的配合才可以，所以要细心。高级调优最重要的方面就是能够精确的查明瓶颈是什么，并且有能力定位这些瓶颈是如何引起的。

  根据常理，这些高级建议放在最后，并且是在系统级上的建议。还有其他的适用于数据仓库调优的高级建议，可以依据你的软硬件资源存在的问题去寻找相应的帮助。

  1、将MAPPING 分解。保留一个数据目标。如果必要每个数据目标保留一个数据源。为什么要这么做呢？在一个MAPPING 中减少数据目标的个数会大幅度的提高运行的速度。基本的情况是这样的：每个MAPPING/TARGET 对应一个SESSION。每个SESSION 都会建立它自己的数据库连接。因为对每个目标表建立一个单独的数据库连接，数据库管理器（DBMS）能将插入、更新和删除等操作需求并行地处理。在一个SESSION 中进行一个特定目的的操作也是很有帮助的（例如不在把以数据驱动地操作和直接插入操作混合地插入到同一个数据目标中）。如果实际情况运行， 每个SESSION 可以被放置到标记为“CONCURRENT”的BATCH（译者注：旧版本的术语）中。如果能够这样做，MAPPING

和SESSION 的并行执行的情况就很显而易见了。关于并行处理的研究一再地表明：与直接将原本的操作单元简单地顺序执行相比，同一时刻开始的并行执行有时只需花费一半的时间。当一个MAPPING 中包含多个数据目标时，就会使得每个数据库连接去处理多个不同地数据库操作语句，有时会影响这个数据目标的性能，有时又是那个。请想一下，在这情况下，INFORMATICA（包括其他的任何工具）都很难进行BULK（并行）操作，即使在SESSION中已经设定了BULK 属性。记住，设定这个属性只是代表你的意愿，如果INFORMATICA不能在一系列连续的记录上执行BULK 操作，就会自动的变成NORMAL 的装载方式。很明显，数据在实际进入数据库以前，数据的实际情况导致了INFORMATICA 使用了内核中较低级别的代码来进行执行。

  2、对于复杂的业务逻辑，使用MAPLET。似乎MAPLET 本身并不对MAPING 的性能带来什么影响。MAPLET 的广泛应用意味着更好的、更具可管理性的业务逻辑。MAPLET也可以帮助你将MAPPING 分解。

  3、保证MAPPING 尽可能的简单。把复杂的业务逻辑（如果必需要这样处理）分解成MAPLET。如果可以避免所有的复杂的业务逻辑，这就成为性能调优的关键。下面这个公理在这里也使用（通常意义）：两点之间的路径越直接，距离越短。在这里可以解释成：数据源和数据目标中间的处理越少，数据装载的速度越快。

  4、记住所需花费的时间是由READER/TRANSFORMER/WRITER 进程所影响的。对于复杂的MAPPING，每个元素（字段）都需要被考虑，这时对于如何理解由INFORMATICA所产生的性能统计信息就变得非常的重要。换句话说，如果READER 慢，其他的线程就会受到影响，如果WRITER 线程慢，也是一样的效果。一根水管的大小只取决于它最小的截面积，一根链条的耐拉力只取决于它的最薄弱的部分。比喻虽然不是非常的贴切，但是它能够说明问题。

  5、改变网络包的大小（对于SYBASE/SQL SERVER/ORACLE 的用户）。最大的网络包的大小是数据库的设置，通常是512 字节或者是1024 字节。设置网络包的大小一般不会影响其他的用户，但是却会使INFORMATICA 充分的利用到其优点，可以在同一个网络包中传输更多、更快的传输数据。典型的最优设置是使网络包的大小在10K 到20K 之间。在ORACLE 中，需要调整Listener.ORA 和TNSNames.ORA 文件中的SDU（Service Layer DataBuffer Size）和TDU（Transport Layer Data Buffer Size）参数。SDU 和TDU 应该被设置成为相等的大小。参见INFORMATICA 的常见问题解答页面来获得更多的信息。

  6、对于本地的ORACLE 数据库，把连接设置为IPC 方式。如果PMSERVER 和ORACLE运行在同一台机器上，使用IPC 连接方式，而不要使用TCP/IP 方式。在TNSName.ORA 和Listener.ORA 文件中进行修改，然后重新启动LISTENER 服务。注意，这个协议只能在本机使用，然而使用IPC 协议所带来的性能的提高会达到2～6 倍。ORACLE 只是使用IPC 协议，该协议是UNIX SYSTEM 5 定义的。可以在UNIX SYSTEM 5 的相关使用手册中找到更多的关于IPC 的信息。

  7、改变PMSERVER 的用户在数据库中的优先级。把每个数据库连接（在SERVER MANAGER 中定义）所使用到的用户的登录优先级调高后，可以改变INFORMATICA 的任务执行时优先级。这些任务连接到数据库后，就可以超过（over-ride）其他的数据库任务的执行。如果优先级已经做了调整，这些任务的内存（在共享内存区SGA 以及服务器的其他设置中）也需要同时进行重新分配。这会明显的提高性能。再次强调，这个方法只是推荐作为最后的调优方法来使用，并且不要认为这个方法能取代数据库和MAPPING 的调优。它仅仅应该在其他方法都不再起什么作用的情况下再使用。要记住，这种方法只能是在生产主机上进行配置，并且是在INFORMATICA 所使用的LOAD 进程不会影响到其他用户的那个实例上进行配置。

  8、改变UNIX 用户的优先级。为提高速度，执行INFORMATICA 程序的UNIX 用户必须提供一个较高的优先级。UNIX 的系统管理员应该明白这样做可以改变登录UNIX 的用户的先后次序，同时给一个特定的任务以较高的执行优先级。或者，简单的以超级用户（SUPER USER）来执行INFORMATICA 的进程，这样可以保证INFORMATICA 的内部进程的优先级。这种方法的使用只能在其他方法都失效的情况下采用，或者是UNIX 主机是由INFORMATICA 程序的专用主机。

  9、避免通过网络进行数据的加载。只要有可能，就将PMSERVER 重新分配到数据库的本地主机来执行。数据库不在本地的意思是：1）REPOSITORY 是通过网络来访问的（速度慢）；2）数据源或者数据目标是通过网络来访问，同样潜在的存在速度变慢的因素。如果必须通过网络来进行数据的加载，至少应该保证REPOSITORY 是在数据库所在的主机上。另外要注意的是，尽量将PMSERVER 和数据目标所在的两台机器放在同一个子网内部，如果能够使用同一个HUB 是最好的，这样做的话可以减少在网络上在进行路由的花销。将数据库本地化能够让你建立一个本地化的数据目标——可以将进行加载的数据先导出（DUMP）到本地的文件，然后通过FTP 的方式上传到目标服务器，然后以并行（BULK）的方式加载到数据库中。在进行数据添加或者进行数据完全的更新的情况下，这样做的优点更明显。

  10、将SESSION 的共享内存设置成12MB～24MB 的大小。很多时候，我发现人们愿意给SESSION 分配更大的内存堆（希望能够提高速度）。这样做的结果是反而使得处理变慢。请参考memory layout document 来获得更多的关于这样做会怎样影响INFORMATICA的内存管理的信息，同时也能了解为什么简单的添加内存并一定能够提升处理速度。

  11、将共享的缓冲区的大小设置为128K 左右。仍然是关于内存分配的问题，请参考上述文档。在INFORMATICA 的进程里面处理记录所占用的内存块的大小是一件很有意思的事情。

  12、内存设置：上面提到的设置是针对一般情况而言的，少于10G 内存的主机可以遵循上面的建议。如果主机拥有12G 的内存，而且同时只运行1～3 个SESSION，可以考虑将SESSION 的共享内存大小设置为1～2G。需要注意，共享缓冲区的大小应该与共享内存设置的大小相适应。如果共享内存的大小设置为124MB，将缓冲区的大小设置为12MB，保持相应的比例。否则结果是更多的内存在后台进行处理，而INFORMATICA 并不能处理更多的任务。越简单的MAPPING 就越符合这个规律。MAPPING 越复杂，通过提高缓冲区或者内存大小来提高速度的可能性就越小，因为INFORMATICA 需要在大量的内存中处理单元（端口、字段、值），因此就潜在的需要在整个内存块中进行重新分配。

  13、对数据库进行快照分析。如果在服务器之间有专线（DS3/T1 等），使用快照或者高级复制的方法从源系统获取相关的数据，放到临时表中。在INFORMATICA 的进程运行前启动快照。关系型数据库管理器就是为这种数据迁移而设计的，而且对这种增量更新数据和全部更新数据的数据传输有很多的优化设置。这一点可能会被很好的利用，尤其是源数据包括1300 万条或者更多的数据，可以让INFORMATICA 从快照中读取数据，这时可以生成任何你需要的索引，在提高读取速度的同时却不影响数据源系统。是的，快照的方式仅仅在数据源和数据目标是同构数据库的情况下（也是同样类型的系统）。

  14、提高磁盘的读取速度。建设数据仓库系统的一个通常的误区是仅仅需要两个磁盘控制器和13 块磁盘就足够了。如果系统仅仅处理少于500 万条记录的数据量，或者加载的时间长度超过5 个小时，这样还算可以。我推荐至少4～6 个磁盘控制器和至少50 个磁盘，设置成RAID0+1 的方式，至少7200 转每秒。如果必要，投入一定的资金采购EMC 的存储设备。到达这样的配置，在性能上可以得到很明显的提升。

  15、采用RAID0+1 的磁盘阵列。RAID5 对于冗余很好，但是对数据仓库而言就很糟糕，尤其是在并行加载的时候。RAID0+1 方式的磁盘阵列很适合数据仓库系统，大多数人也认为它的效果和RAID5 一样的安全，尤其是现在的硬件几乎都是热切换的，而且相关的管理软件也相当的成熟。

  16、升级硬件设备。如果想得到每秒GB 级的数据处理能力，或者系统能够在4 个小时内对3400 万行数据建立10 个索引，那么只能增加CPU 的处理能力、添加内存和磁盘。4个CPU 的机器对这样的处理要求是无能为力的。我建议最少使用8 个CPU 的主机，如果必要的情况下升级到12 个CPU。这是对大型的数据仓库系统而言的，就是那种每小时处理GB 级数据的系统。4 个CPU 的主机适合于开发或者是小型的数据仓库系统（总共不超过500 万条记录的数据仓库）。然而，主要总线速度也是一个很重要的因素。我听说4 个CPU的DEC-ALPHA 系统相当于6 个CPU 的处理能力。那么什么是关键呢？磁盘转数、总线速度、内存大小以及CPU 的个数。我认为上面的顺序是从重要到非重要。在6 个CPU、8～

12G 的内存的主机和最少4 个磁盘控制器的7200 转的EMC 存储设备上，ORACLE 和SYBASE 都能够运行的相当不错。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友