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