我们有37个Informatica会话，其中大多数会话平均有大约25个表。很少会话有1个表作为源和目标。我们的来源是Oracle，目标是Greenplum数据库。我们正在使用安装在Oracle上的Powerexchange 10.1来获取我们的Changed记录。
我们注意到，对于拥有更多表的会话，需要更多时间来获取数据并在目标中进行更新。添加更多表会不会延迟处理？在那种情况下如何调整以尽可能快地获取记录？
答案 0 :(得分：0)
我们运行19个CDC映射，每个映射有17到90个表，并且最近在性能方面取得了突破。表的数量不是我们，电力中心和电力交换的最重要的限制因素。我们的源代码是z / OS上的DB2，但这可能并不重要...... 这就是我们所做的：
1）我们将DTM缓冲区块大小增加到256KB，DTM缓冲区大小增加到1GB或更多，“复杂”映射需要很多缓冲区块。
2）我们将连接属性更改为： - 实时刷新延迟= 86000（最大设置） - 会话中的提交大小设置得非常高（允许上述设置成为决定因素） - OUW计数= -1（与上述相同的原因） - 每次提交的最大行数= 0 - 每次提交的最小行数= 0
3）我们将会话属性“恢复策略”设置为“失败任务并继续工作流程”并实现我们自己的解决方案，以便在每次工作流启动时从头开始创建“重新启动令牌文件”。 只略微偏离主题：我们实现这个的方式是使用一个额外的表（我们称之为SYNC表），只包含一行。通过非常可靠的预定流程（一个小型CICS程序），该源每10分钟在源上更新一次。每个工作流将此表的内容写入目标数据库，并在映射中添加一个额外的列，其中包含$$ PMWorkflowName的内容。除了workflowname列之外，还会将两个DTL__Restart1和* 2列写入目标。 在工作流启动期间，我们在实际CDC会话之前运行一个小的可重用会话，该会话从目标端的SYNC表读取当前工作流的记录，并从头开始创建RESTART文件。 [请注意，您最终会在目标中最多10分钟（从工作流程开始时间）开始。我们接受并在所有映射中将它们聚合在一起]
尝试修改这些组合并告诉您的体验。我们现在每个映射的10分钟间隔的最大吞吐量为10-100万行。我们的目标是Netezza（来自IBM的PDA）
我可以告诉你另一件事： 每次触发提交时（使用上述设置每86秒），电源中心将清空所有写入缓冲区，而不是一个大提交范围内的所有表。如果其中任何一个被另一个进程锁定，你可能最终会在编写器端进行大量级联锁定，这会使CDC看起来很慢。