根据常理，这些高级建议放在最后，并且是在系统级上的建议。还有其他的适用于数据仓库调优的高级建议，可以依据你的软硬件资源存在的问题去寻找相应的帮助。
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 Data Buffer 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都能够运行的相当不错。
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 Data Buffer 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都能够运行的相当不错。
993
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
