zoukankan      html  css  js  c++  java
  • ABAP:SAP报表性能的优化

    大部分ABAPer都是从SAP报表及打印开始学起的,大家也都认为写个SAP报表程序是最简单不过的事了。
    但是实际情况真的如此吗?写报表时除了保证数据的准确性,您可曾考虑过报表的性能问题吗?
    由于报表程序是被最多SAP用户所访问的,所以性能差的报表很可能会引来大量的抱怨和质疑,大大降低用户满意度。
    最近做了较多性能优化方面的工作,颇有感触,在此进行归纳总结,希望对大家有所帮助,也欢迎大家讨论。
    1, 关于表连接语句(INNER JOIN, LEFT JOIN…)
    写报表的时候,表与表之间的关联是不可避免的。通常而言,表连接语句要掌握的原则有:
    (1) 将最有效的查询条件所对应的表放在第一位。换言之,让查询第一个表后所得到的结果集就尽可能小。
    比如有一张报表叫做订单状态统计表,可能查完VBAK、VBAP后还查询LIPS、VTTP等,界面上的查询条件很多。不过据了解得知,该报表主要是查看昨天创建或前几天创建的订单。那么最有效的限制条件自然是订单创建日期,以及销售组织了,而表连接的主表宜选用VBAK。
    (2) 确定了表连接的次序后,应考虑将查询条件尽量限制在靠前的表里。比如选择屏幕上有个物料号的查询条件,而我们知道订单VBAP和交货单LIPS均有物料号,那就应该视情况而定,如果表连接中VBAP更早出现,那么WHERE子句中就使用vbap~matnr IN s_matnr,反之就是lips~matnr IN s_matnr。
    (3) 两个表之间进行连接的时候,应考虑关键字段或索引字段的作用。比如查询VTTP和LIPS时,关联关系是vttp~vbeln = lips~vbeln。那么vttp在前,lips在后,就会比较快,因为根据vttp的vbeln查询lips时,vbeln是lips的关键字段,速度较快。而反过来如果lips在前,那根据lips~vbeln查询vttp会慢一些,除非vbeln是vttp的索引字段。
    2, 先构建RANGE再执行SQL语句
    有时我们所能用的查询条件不是很理想,比如查询LIKP却必须用公司代码,而非销售组织。
    此时普通做法是用LIKP与TVKO根据VKORG进行表联接,从而限制TVKO~BUKRS的值。
    还有一种有效的办法是,通过TVKO查询到当期公司代码所对应的全部销售组织,从而组建一个RANGE出来,再根据此RANGE查询LIKP。当然要注意RANGE的行项目有上限的,在ECC6中大概2万行将导致ABAP DUMP。
    提示:DATA r_vkorg TYPE RANGE OF likp-vkorg.
    SIGN = ‘I’, OPTION = ‘EQ’, LOW = ‘XXXX’ 即可往r_vkorg中放入多个单值。
    3, For All Entries与Select Single的比较
    就个人而言,笔者不是很喜欢For All Entries语句,因为它的缺点多于优点。很多人都会说,为什么呀,For All Entries不是比Select Single快么?事实到底怎样呢,让我们做个比较。
    假设我们有个内表代表销售订单的行项目,该内表有10万行。此时我们要根据LIPS的VGBEL和VGPOS,查询这些订单行项目对应的交货单行项目。
    如果用SELECT SINGLE的话写法很简单:
    LOOP AT it_vbap INTO wa_vbap.
    SELECT SINGLE vbeln posnr
    FROM lips INTO (wa_vbap-vbeln_vl, wa_vbap-posnr_vl)
    WHERE vgbel = wa_vbap-vbeln AND
    vgpos = wa_vbap-posnr AND
    vgtyp = ‘C’.
    MODIFY it_vbap FROM wa_vbap.
    ENDLOOP.
    如果用For All Entries则写法分2步:
    SELECT vbeln posnr
    FROM lips INTO TABLE it_lips
    For All Entries IN it_vbap
    WHERE vgbel = it_vbap-vbeln AND
    vgpos = it_vbap-posnr AND
    vgtyp = ‘C’. “此交货单是根据订单创建的
    LOOP AT it_vbap INTO wa_vbap.
    READ TABLE it_lips INTO wa_lips WITH KEY vgbel = wa_vbap-vbeln
    vgpos = wa_vbap-vgpos.
    IF sy-subrc = 0.
    wa_vbap-vbeln_vl = wa_lips-vbeln.
    wa_vbap-posnr_vl = wa_lips-posnr.
    MODIFY it_vbap FROM wa_vbap.
    ENDIF.
    ENDLOOP.
    对于SELECT SINGLE而言,由于LIPS有个VGB的SAP自带索引,每次查询都挺快,即便循环10万次,速度虽然快不了但也没什么大的危害。
    对于For All Entries的第一步,的确比SELECT SINGLE快些,本来10万次的SELECT SINGLE,变成了1万次的查询(如果BASIS设置了参数为10),每次查询10个订单行项目。但是第二步就很慢了, 暂估it_lips为8万行,则对于it_vbap的10万个行项目,有8万个行项目执行READ TABLE语句平均需要4万次才能搜索到it_lips的目标行,另有2万个行项目将读遍it_lips然后才发现没有对应的目标行。所以我们一共需要搜索48亿次,太慢了!
    在此针对For All Entries的使用提出几点意见:
    (1)如果是根据某数据量大的内表用For All Entries读取数据量小的配置表,比如TVAK/T006等,那不如把For All Entries直接去掉,把表里的几十条数据全部取出。
    (2)使用For All Entries时,SELECT语句后面的字段必须包含所查表关键字段。比如上面的vbeln/posnr就是lips的关键字段。如果不含关键字段,比如SELECT lfimg FROM lips For All Entries ***,那么当LIPS中两个条目关键字段不同而lfimg相同时,会被SAP自动过滤掉一条。
    (3)上面关于性能问题,应该利用BINARY SEARCH、SORTED TABLE或者HASHED TABLE来解决。详见下面第四节。
    4, 关于BINARY SEARCH/SORTED TABLE/HASHED TABLE的使用
    BINARY SEARCH即二分法查找,在保证内表按查询字段以升序排列的时候,可以采用二分法查找。二分法查找的速度很快,最大查询次数为log2n。以上面的例子来说,如果it_lips事先按vgbel和vgpos排好序,则每次查找最多不超过17次。则对于it_vbap的10万个行项目,仅100多万次就可以搞定了!
    当使用READ TABLE语法时,如果查询字段跟SORTED TABLE的排序开始字段能匹配上,则SAP将自动采用二分法查找。比如it_lips是SORTED TABLE且以vgbel和vgpos排序,则当read table以vgbel进行查找时,系统会自动采用二分法。但如果read table以vgpos和其他字段进行查找,由于vgpos并非SORTED TABLE的第一排序字段,系统将采用直线查找,速度会慢很多。总之,SORTED TABLE的排序字段次序也很关键。
    针对STANDARD TABLE排序后可以进行二分法查找,使用SORTED TABLE也可进行二分法查找,那么二者有什么区别呢?简单来说,由于SORTED TABLE自始至终都保持排序,如果需要对内部进行频繁的插入、删除操作,则不推荐使用SORTED TABLE,性能会很差。而另一方面,如果我们要用的是类似LOOP AT it_lips WHERE vgbel = ** 的语法(而非READ TABLE)时,对于STANDARD TABLE就无法采用二分法查找,或者说会很麻烦。而对于SORTED TABLE,系统会自动采用二分法优化查找过程。
    至于HASHED TABLE,笔者用得也不太多。查看SAP的标准代码,貌似用得也没很多。理论上HASHED TABLE可以比SORTED TABLE更快些,但需要耗用更大的存储空间。当某程序采用了二分法查找之后,如果效果还不是很理想,建议可以用HASHED TABLE试试。
    5, 将循环内的重复性工作进行缓冲
    有时我们的内表数据量很大,但又不得不在每次循环的时候,都进行类似的一些操作,比如调用函数FI_PERIOD_DETERMINE获取某日期对应的会计年度和期间,调用函数MD_CONVERT_MATERIAL_UNIT进行单位转换,等等。每个函数的调用背后都要执行一系列的读表以及运算工作,程序的效率明显下降了。所以我们得想出有效的办法。
    比如针对FI_PERIOD_DETERMINE的调用,可以改用循环前对函数G_PERIODS_OF_YEAR_GET的调用。根据公司代码BUKRS读取T001-PERIV,然后调用G_PERIODS_OF_YEAR_GET获取某会计年度每个会计期间对应的起始日期和结束日期。这样在循环内部,只要根据上面的结果即可算出某日期对应的会计年度和期间了。
    又比如针对MD_CONVERT_MATERIAL_UNIT的调用。相信对于it_vbap的10万个行项目,物料号重复的有很多。所以可以先汇总物料号,然后一次性读取表MARM以存储换算关系。有了MARM的换算关系,循环中大量的单位换算就可以自己算了,如果无法换算的再考虑调用函数MD_CONVERT_MATERIAL_UNIT。(函数MD_CONVERT_MATERIAL_UNIT除了读取MARM的换算关系,还会考虑同一维度单位间的换算关系比如G和KG的关系,所以其功能更强大。)
    6, 关于字段的增强以及TABLE INDEX的创建
    这里提到字段的增强,主要是性能方面相关的。假设我们需要基于系统所有的billing document做个动作,比如将其导出到金税系统。至少有两种方案:第一是新建一个表,专门记录已经导出到金税的开票凭证;第二是在系统标准的开票凭证抬头表vbrk中新增一个字段,记录是否已导出到金税。
    用户在处理业务的时候肯定会反复查询“未导出到金税”的所有开票凭证。那么第一种方案下,我们需要先查询VBRK表(比如得到1万条记录),然后针对自建表的记录(比如得到9800条记录)做个减法,最后得到200条记录的结果集。而第二种方案就快多了,查询VBRK的时候判断新字段=“未导出”即可。
    随着业务的持续,VBRK表的条目将越来越多,而“未导出”的条目则会维持在一个较为平稳的数字上,为了有效区分历史数据和现用数据,可添加TABLE INDEX,提高报表的查询速度。很多SAP标准表都自带了一些索引,这些索引大都比较实用。
    创建索引需要注意以下几点:
    (1)索引会占用额外的数据库空间,还会降低插入/修改的速度(虽然可提高查询速度),所以需要考虑实用性,肯定不是越多越好。如果表中已有类似的索引,则不推荐新建。而对于容量大的、被多个程序访问的表加索引就更要谨慎了,比如VBFA、MSEG、FAGLFLEXA、LIPS、VBAP、EDIDC、STXH等等。
    (2)创建索引时应注意字段的先后次序,MANDT是必须的而且都要放在第一位。字段的先后次序取决于实际业务需要。另外索引的字段不宜太多,字段越多占用的数据库空间就越多,对于插入/修改的影响也更大。
    7, 选用一些替代表/替代字段(VBFA, SHP_IDX_)
    曾做过一些类似于“未拣配交货单”、“未发货过账交货单”的报表,刚开始用的是LIKP、VBUK等表,速度并不理想。后来调试了标准程序VL06O,发现其用的表是SHP_IDX_PICK、SHP_IDX_GDSI等。原来系统在创建交货单的时候,也会更新这些临时表。当拣配完成,该条目就从SHP_IDX_PICK中删除。所以表SHP_IDX_PICK的条目数始终不多,查询速度很快。
    同样的,当我们在多个表中进行查询时,可能不同的限制条件都能达到同样的结果集,但效率差异就很大,所以选用有效的字段非常关键。比如需要查询某销售组织某天已发货的销售订单,我们可以将VBAP与LIPS联查。此时查询条件VBAK-LIFSK=SPACE或VBAP-ABGRU=SPACE并不影响查询结果,但它们可以在第一时间就排除大量无关的订单,对于性能的提升帮助很大。
    8,考虑企业的特点及数据量状况
    做优化不是简单的技术活,既要考虑报表的实际需求,也要考虑企业的业务状况。比如采用零售模式的企业客户量很大(KNA1表条目多),批发模式的企业客户量较小;食品饮料行业的物料号一般不多,而机械行业的物料号则往往多而繁杂;零售业的订单量很大、时间性很强,所以最有效的查询条件往往就是组织编码+日期,部分行业则可能订单量小但价值高。只有充分考虑到企业的业务特点,才能更有效地提高报表性能。
  • 相关阅读:
    Redis
    多线程相关
    selenium操作浏览器的基本方法
    selenium之 webdriver与三大浏览器版本映射表(更新至v2.29)
    selenium安装及官方文档
    Python(3)_python对Json进行操作
    python类中的self参数和cls参数
    python3中shuffle函数
    Python3中assert断言
    python2和python3中range的区别
  • 原文地址:https://www.cnblogs.com/ruingy/p/3463246.html
Copyright © 2011-2022 走看看