ABAP性能和优化

 

哪些工具能够用于性能优化？

ST05-性能追踪。包含SQL追踪加RFC，队列和缓存追踪。SQL追踪主要用于测量程序中select语句的性能。

SE30-运行时分析。用于测量应用的性能。

SAT是过期的SE30的替代品。提供了和SE30相同的功能和额外的一些特性。

ST12事务（ST-A/PI软件组件的一部分）是ST05和SAT的结合。这是个很是强大的性能分析工具，由SAP提供支持。

Code Inspectior（SCI）是最好的静态性能分析工具之一。有不少选项能够用于找到一般的错误和可能的性能瓶颈。

优化ABAP代码的步骤

1，数据库

a. 在select语句中使用使用where子句来限制数据检索的体积。很重要！（译注：工做中见到过有人写select * from marc这种语句. 致使在生产系统中直接由于内存不足dump）

b. 设计查询，使其尽量多地在where中使用索引字段。

c. 在select语句中使用inner（或者某些状况下使用outer）join语句以实现一次性查询获得匹配的数据。

d. 避免使用嵌套的select语句，以及loop中的select语句，使用join或者for all entries in会更好。若是已经有内表可使用，或者在某些处理结束以后，可使用for all entries in。若是select后面正好还有选择的话，使用join。

e. 访问缓存时避免使用into corresponding fields of table。相反，应该使用最适合程序的（字段）。

f. 避免使用select * ，应该只查询须要的字段。

g. 不要在select语句中使用order by，若是它和用到的索引不一样的话（正确的作法是排序内表）。由于这会增长不少额外的工做。数据库系统只有一个，而ABAP服务器有好多。（译注：不肯定这种观点在HANA平台中是否依旧适用。能够参考一篇在SCN上的问答，ABAP7.51版本的文档中已经删除了这个限制相关的描述：ABAP Development : SAP HANA ORDER BY or SORT internal table）

h. 索引。在为了改善性能而建立索引前，须要深思熟虑。索引能够提升查询性能，可是也会带来两个间接的负担：存储空间和写入性能。在大事务表中建立索引时，用于存储索引的空间和索引的体积是很是巨大的！当在数据库表中插入一条新的记录的时候，全部索引都须要更新。索引越多，花费的时间也就越多。数据越多，索引也就越大，更新索引所需的时间也就越大。

i. 避免屡次运行相同的select（一样的select, 一样的参数）。在你的abap代码中缓存相关信息。

j. 若是有不影响性能的标准的视图，避免使用join语句。

2，表缓存

a. 将表定义为“缓冲过的”（SE11）能够提升性能，可是要当心地使用它。表的缓存会致使程序从缓存中而不是表中读取数据。缓存和表是周期性同步的，只有极少状况下、某些东西改变的时候才会同步。若是是事务表，数据在不一样的选择条件下会改变，所以这类表是不适合缓存的。不建议在这种状况下使用缓存。应该为配置表和某些主数据表启用缓存。

b. 避免对缓存表使用复杂的查询，由于SAP可能解释不了这个请求，而且也许会把它传递给数据库——code inspector能够说明哪些命令会绕过缓存。

3，内表

a. 尽量使用哈希表，其次是排序表。标准表是最后的选择。

b. 若是要修改内表的话，对于大工做区，应使用assign而不是loop into

c. 有疑问的时候，运行SE30，以此检查代码

d. 若是不得不用标准表，而且要read读取其中的行的话，使用binary search来提升搜索速度。

4，杂项

a. perform：写子程序的时候，老是提供全部参数的类型。这减小了系统根据形参肯定参数类型的开销。这也提升了程序的健壮性。

select single和select ... up to 1 rows的区别是什么？

• select single和select up to 1 rows返回第一条匹配给定条件的记录。它可能不是惟一的，给定条件有可能匹配多条记录。
• 对于oracle数据库而言，select single会被转换为select ... up to 1 rows，所以，它们是同样的。只不过ABAP的语法不容许将order by和select single放在一块儿用，可是容许其和select...up to 1 rows一块儿用。所以，若是你想得到最高/最低的一条记录，是不能够用select single的，只能用select ... up to 1 rows where ... order by.

join和for all entries in哪一个性能好？

绝大多数场景下，inner join比for all entries in要好，应当被首先采用。只有当可能出现性能问题的时候才要用for all entries in，要仔细地测量更换为for all entries in先后的性能变化以验证是否真的有提高。

须要首先在一个测试程序上运行for all entries in并运行sql追踪以观察其效果。某些由BASIS设定的选项可使for all entries in做为“OR”条件运行。这意味着若是使用for all entries in筛选的表有3条数据

，SQL追踪会显示3个SQL在执行。在这种状况下，使用for all entries in没意义。然而若是SQL追踪显示一条SQL语句，这时for all entries in是有用的，由于它实际上被看成一个in列表来执行。

比起for all entries in，更加推荐使用join。join链接的表的数量并无实际的限制；不过太复杂的句子会难以维护，若是join里面有什么问题，也比较难以解决。若是join是使用两个表的键来链接的话，会减小程序负担，提升性能。

在某些场景下，你会须要之内表做为条件。此时，你可能没别的选择，只能用for all entries in了。

下面是使用了join的代码：

 

SELECT A~VBELN A~KUNNR A~KUNAG B~NAME1
INTO TABLE I_LIKP
FROM LIKP AS A
  INNER JOIN KNA1 AS B
    ON A~KUNNR = B~KUNNR.
* For with limited data using for all entries:
* Minimize entries in I_likp by deleting duplicate kunnr.
LOOP AT I_LIKP INTO W_LIKP.
  W_LIKP2-KUNAG = W_LIKP-KUNAG.
  APPEND W_LIKP2 TO I_LIKP2.
ENDLOOP.
SORT I_LIKP2 BY KUNNR.
DELETE ADJACENT DUPLICATES FROM I_LIKP2 COMPARING KUNNR.
* GET DATA FROM kna1
IF NOT I_LIKP2[] IS INITIAL.
  SELECT KUNNR NAME1
    INTO TABLE I_KNA1
    FROM KNA1
    FOR ALL ENTRIES IN I_LIKP2
    WHERE KUNNR = I_LIKP2-KUNNR.
ENDIF.

 

使用collect语句来在内表中求和

使用collect，而不是自定义逻辑来求和。对哈希表使用collect会很高效。

（译注：在使用HANA数据的状况下，利用Open SQL中的SUM关键字来求和彷佛是更好的选择）

避免嵌套循环

例如：

LOOP AT ITAB1.

  LOOP AT ITAB2 WHERE F1 = ITAB1-F1.

    ....

  ENDLOOP.

  ENDLOOP.

在生成环境下，这样的代码可能会很慢甚至超时dump。

咱们可使用附加关键字binary search来改善性能。更好的是——使用哈希表或者排序表。

SORT ITAB2 BY F1.
LOOP AT ITAB1.
  READ TABLE ITAB2 WITH KEY F1 = ITAB1- BINARY SEARCH. "f1 is any field of itab1
  IF SY-SUBRC = 0.
    IDX = SY-TABIX.
    LOOP AT ITAB2 FROM IDX.
      IF ITAB2-F1 <> ITAB1-F1.
        EXIT.
      ENDIF.
      ....
    ENDLOOP.
  ENDIF.
ENDLOOP.

若是你有一个排序表，内表能够这样读取：

TYPES: BEGIN OF ITAB,
F1 TYPE MARA-MATNR,
....
*NOT ONLY THE KEYFIELD !!
END OF ITAB.
DATA: ITAB2 TYPE SORTED TABLE OF ITAB WITH UNIQUE KEY F1.
LOOP AT ITAB1.
  LOOP AT IATB2 WHERE F1 = ITAB1. "f1 is any field of itab1
  ....
  ENDLOOP.
ENDLOOP.

CDS视图性能分析 

能够参看该文：使用PlanViz进行ABAP CDS性能分析

 

本文连接：http://www.cnblogs.com/hhelibeb/p/7043998.html

原文标题：ABAP Performance and Tuning

参考文章：ABAP on HANA – from analysis to optimization

                  Analysing Performance problems on HANA