Informatica 中的性能调优：完整教程
大卫卡特
Informatica中的性能调优是什么？
在 Informatica 中，性能调优是指找到限制会话运行速度的组件，消除该限制，然后对下一个成为最慢组件的组件重复此操作。会话的运行速度始终取决于其最慢的层，因此，对从未出现问题的转换进行调优不会带来任何可衡量的性能提升。
Informatica 指出了五个可能出现瓶颈的地方，并建议按固定顺序检查它们。
| 下单 | 层 | 典型原因 |
| 1 | Target | 写入速度慢、检查点间隔短、数据库网络数据包大小小 |
| 2 | 来源 | 查询速度慢、缺少索引、读取了不必要的列 |
| 3 | 地图绘制 | 昂贵或位置不佳的转换，过大的缓存 |
| 4 | 时间 | Buffer 内存、提交间隔、分区、加载类型 |
| 5 | 系统 | 集成服务机器上的 CPU 饱和度、I/O 等待和分页问题 |
这样的顺序是经过深思熟虑的。如果目标层无法足够快地吸收数据行，就会使所有上游层看起来都很慢，因此会首先检查它。完整的方法记录在……中。 PowerCenter 性能调优指南.
如何识别性能瓶颈
猜测哪一层速度慢比直接测量更浪费时间。以上列出的五层结构可以用四种方法进行测量。
- 运行测试会话。 配置副本 会议 向平面文件目标写入数据。如果会话速度明显提升，则说明该目标文件是瓶颈所在。反过来，从平面文件源读取数据，则可以找出源端的瓶颈。
- 分析帖子统计数据。 数据转换管理器运行一个读取线程、一个或多个转换线程和一个写入线程。会话日志中繁忙时间最长的线程直接指向要处理的图层：读取线程指向源图层，转换线程指向映射图层。ping为目标公司撰稿。
- 分析性能细节。 启用会话性能数据收集并读取计数器。查找缓存中出现大量错误行或大量行表明映射存在问题。ping 这不是数据库问题，而是数据库问题。
- 监控系统。 Operating 系统工具显示 CPU 使用率、I/O 等待和页面调度情况，以及 工作流监控器 资源视图显示，机器已达到处理能力极限。
一旦确定了负责层，以下各节中的转换层建议就值得应用了。这些章节按管道顺序排列，从数据进入的点开始。 地图ping 达到聚合的程度。
源限定符转换
源限定符未读取的每一行，其他转换都不需要处理，这使其成为整个映射中最经济高效的地方。ping 为了省时间。
- 仅从源中提取所需的列。大多数情况下，源表中的所有列都不是必需的，因此只需删除不必要的列即可提取所需的字段。
- 避免在子句中使用 order by 子句 源限定符 SQL 覆盖。ORDER BY 子句需要额外的处理，避免使用它可以提高性能。
过滤转换
过滤遵循相同的原则，只是步骤略有不同：在映射最早到达的位置丢弃不需要的行。ping 拥有足够的信息来识别他们。
- 绝大部分储备使用 滤波器变换 尽早进入地图内部ping如果能在地图绘制初期就丢弃不需要的数据，ping这将提高吞吐量。
- 使用源限定符筛选数据。您还可以使用源限定符 SQL 覆盖来筛选记录，而无需使用筛选转换。
细木工改造
在典型的地图中，连接是第一个真正昂贵的操作。ping因为必须先缓存主数据源，然后才能将详细行与之匹配。
- 如果可能，请始终优先在数据库中执行连接操作，因为数据库连接比在 Informatica 中创建的连接操作速度更快。 连接器转换.
- 如果可能，在加入之前对数据进行排序，因为它会减少加入期间执行的磁盘 I/O。
- 创建行数较少的主表。
第三点最容易被忽略。集成服务会缓存主数据源，因此将较小的表指定为主表可以保持缓存较小。
查找转换
查找操作要么按行查询数据库一次，要么在内存中建立缓存，这两种方法都有利于使用更小、索引更好的查找源。
- 在 A 中为该列创建索引 查找表 该字段用于查找条件。由于需要查询查找表来查找匹配的数据，因此添加索引可以提高性能。
- 如果可能的话，在数据库中使用连接而不是查找转换。由于数据库连接速度更快，因此性能将会提高。
- 从查找表中删除不必要的列，只保留所需的列。这将降低从数据库获取额外列的开销。
聚合器转换
An 聚合 它在对行进行分组的同时将数据保存在缓存中，因此任何减少到达它的数据的量都会减少它所需的缓存。
- 在聚合数据之前先进行数据筛选。如果您在映射中使用筛选转换，ping然后，在使用聚合器之前对数据进行筛选，这样可以减少不必要的聚合操作。
- 限制聚合转换中使用的端口数量。这将减少聚合转换存储在缓存中的数据量。
Informatica 中的会话级调优
当地图ping 程序本身运行良好，其余的性能提升都来自于会话属性。这些设置值得逐一更改，每次更改后都进行一次计时运行，因为其中一些设置会以内存为代价来换取速度。
| 设置 | 它控制什么 | 何时更改 |
| DTM缓冲区大小 | 集成服务为源数据块和目标数据块分配的总内存 | 当会话处理多个分区、源或目标时，增加此值。 |
| Buffer 块大小 | 单个内存块的大小 | 对于异常大的行，增加内存使用量；对于物理内存有限的情况，减少内存使用量。 |
| 提交间隔 | 在发出提交命令之前写入了多少行 | 当写入线程花费时间等待数据库检查点时，应抛出此异常。 |
| 下推优化 | 地图的多少ping 逻辑被转换成 SQL 语句，并由数据库执行。 | 当源和目标位于同一个强大的数据库中时使用。 |
Buffer 内存分配遵循既定的计算方法，而非猜测。集成服务为每个源分区和目标分区至少分配两个块，因此会话缓冲区块的数量为（源总数 + 目标总数）乘以 2，而 DTM 缓冲区大小为该块数乘以缓冲区块大小再除以 0.9。
下推优化需要谨慎对待。它仅在数据库速度确实比集成服务机器快，且转换逻辑可以用以下方式表达时才有效： SQL无法翻译的逻辑会保留在会话中，因此增益通常小于预期。应该在启用前后进行测量，而不是默认启用。
