代码之家  ›  专栏  ›  技术社区  ›  Raghav Rao

具有完全相同会话属性的两个映射的行为完全不同,逻辑略有变化

  •  0
  • Raghav Rao  · 技术社区  · 6 年前

    我是Informatica开发者。 我在Informatica有一张地图,上面写着:

    Original Mapping :
    
    AS400(DB2SQ)->EXP->RTR->AGG1->MPLT->TGT1(SQL Server) Pipeline 1.
           |             |->AGG2->TGT2(SQL Server)
           |             |
           |             |->TGT3(SQL Server)
           ->AGG3->EXP->TGT4(FlatFile)           Pipeline 2.
    

    大量记录正在通过管道1。我被要求优化流程。下面是我的建议。

    1. 在管道1中。删除agg1和agg2,并将聚合逻辑推送到数据库,这是我的建议,因为流是增量的,增量记录被加载到临时表中,所以希望性能更好。
    2. 删除目标数据tgt3,因为它不是必需的。

    这就是我的优化映射现在的样子:

    Optimized Mapping(What i thought) :
    
    AS400(DB2SQ)->EXP->RTR->MPLT->TGT1(SQL Server) Pipeline 1.
           |             |->TGT2(SQL Server)
           |
           ->AGG3->EXP->TGT4(FlatFile)           Pipeline 2.
    

    为了研究源性能优化,我替换了所有目标的会话属性,改为写入文件。我想看看我是否可以在任何方面优化我的资源。

    但令我惊讶的是,当我同时执行这两个会话(在单独的工作流中,并且一个接一个地单独执行)时,我发现优化会话的sq吞吐量比原始会话慢得多。

    优化后的解决方案中的所有内容都完全相同,因为我在删除两个聚合器和一个目标之前复制了原始映射/会话。

    请注意:我正在开发的环境已经启用了版本控制,它与此有什么关系吗?

    我试图交叉检查这个倍数,但找不到答案。

    1 回复  |  直到 6 年前
        1
  •  0
  •   Sasmit Kumar Bhitiria    6 年前

    如果您查看会话登录的详细信息,您可以更好地识别它。此外,您还可以在源数据库中运行查询并检查所用的时间。您还可以使用下推优化(即源端下推优化)来优化源端的性能。但在此之前,请检查源数据库是否一切正常,并且不需要花费太多时间。还可以修改优化查询并查看性能。

    如果仍然没有成功,那么您可以在sq中查找会话分区并检查性能。