如何在informatica中提高mapping的性能.pdfVIP

  1. 1、本文档共10页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
如何在informatica中提高mapping的性能.pdf

我如何在informatica 中提高mapping 的性能 Mapping 的调优 何时调优mapping 在开发过程中最好的调优时间是,在系统测试完成之后。集中于mapping 一级的调优应当在 目标和源系统的数据库的调优完成之后。 用Session 日志来确定源,目标或者转化过程中存在着性能的瓶颈。 Session 的日志中含有线程的摘要记录: MASTER PETL_24018 Thread [READER_1_1_1] created for the read stage of partition point [SQ_test_all_text_data] has completed: Total Run Time = [11.703201] secs, Total Idle Time = [9.560945] secs, Busy Percentage = [18.304876]. MASTER PETL_24019 Thread [TRANSF_1_1_1_1]created for the transformation stage of partition point [SQ_test_all_text_data]has completed: Total Run Time = [11.764368]secs, Total Idle Time = [0.000000]secs, Busy Percentage = [100.000000]. MASTER PETL_24022 Thread [WRITER_1_1_1] created for the write stage of partition point(s) [test_all_text_data1] has completed: Total Run Time = [11.778229] secs, Total Idle Time = [8.889816] secs, Busy Percentage = [24.523321]. 如果一个线程忙碌达到100%,其他的线程有一个明显的较低的值。那么有着高忙碌率的那个 线程就是一个瓶颈。如上例子所示,这个session 有一个转化的界限。 确认目标的瓶颈: 最通常的性能的瓶颈会发生在Informatica Server 向目标数据库写的时候。你可以通过配 置一个session 写向一个平面文件,来确认一个目标的瓶颈。如果当你写向一个平面文件的时 候,session 的性能得到极大的,那么你就有一个目标的瓶颈。 考虑通过完成以下手段来提高性能: * 删除 indexes 和 key constraints. * 提高checkpoint 的间隔. * 用bulk loading. * 用external loading. * 增加数据库网络包的大小 * 优化目标数据库 确认数据源的瓶颈: 如果 session 是从关系数据库中读取数据,你可以用一个过滤的转换、一个读的测试的 mapping 或一个数据库的查询来确认数据源的瓶颈: * 过滤的转换-测量给定数量的数据的处理时间,然后在 mapping 中在每个 source qualifier后加上一个总是false的filter transformation来确保没有数据通过ilter transformation.如果新的session 运行时和原来消耗的时间一样,那么你就有一个数据源 的瓶颈。 * 读的测试 session.比较用一个 session 处理给定数量的数据的时间与复制这样一个 session 并把source qualifier后面的所有转化都去掉同时把source qualifier连接 到平面文件的目标上,如果新的session 消耗的时间还是那么多,那么在数据源上有瓶颈。 *从 session 的日志中提取一个查询,并在一个查询的工具中运行。测算返回第一条记录和所 有记录的时间。如果有明显的不同,那么你就有可能需要解决数据源的瓶颈 考虑通过完成以下手段来提高性能: * 对查询调优 * 用条件过滤 * 增加数据库网络包的大小 * 用IPC协议连接 Oracle 数据库 你也可以确认mapping 的瓶颈,通过性能计数器。 Readfromdisk 和 Writetodisk 计数器: 如果一个 session 有 Aggregator, Rank, 或者说 Joiner transformations,那么检查每个Transformation_readfromd

文档评论(0)

ziyouzizai + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档