Kódoptimalizálás
Mint minden nyelvben fontosak bizonyos előre megadott irányok a kód szintaktikailag helyes, és fordítási valamint futási időben
optimális implementálásában. ABAP nyelvben sincs ez másként. Elsősorban a nagy mennyiségű adatok kezelésénél lehet alkalmazni
az alábbi lehetőségeket annak érdekében, hogy minél kevesebb beolvasást, adatbáziskapcsolatot terheljenek le a programjaink.
Adatbázis
- Használjuk a WHERE ciklust a SELECT utasításban, hogy korlátozzuk az adatok mennyiségét.
- Tervezzünk a lekérdezésbe minél több indexelt mezőt, illetve a WHERE ciklusban lehetőleg balról jobbra használjuk a műveletet.
- Alkalmazzuk a FOR ALL ENTRIES-t a SELECT utasításban, hogy egy lépésben tudjuk letölteni a megfelelő rekordokat.
- Kerüljük a beágyazott SELECT utasítást és magát a SELECT-t a LOOP-on belül, ennek kikerülése érdekében alkalmazzuk a JOIN vagy a FOR ALL ENTRIES utasítások valamelyikét.
- Mellőzzük a SELECT * utasítást, a SELECT egyedül csak a szükséges mezőket szelektálja a táblából, felesleges adatokat ne szedjünk ki az adatbázisból.
- A tartalom ellenőrzésre használjuk a SELECT UP TO 1 ROWS-t és ne a SELECT COUNT-t, és kerüljük a COUNT-t és az UP TO 1 ROW utasítások kombinációját..
- Ne használjuk az ORDER BY-t a SELECT utasításban, ha eltérő indexeket használunk - helyette rendezzük az alap belső táblákat - az további munkát adhat az adatbázis rendszernek miközben több ABAP szerver is párhuzamos műveleteket végezhet.
- Az indexelésnek a teljesítményjavításban van fontos szerepe. Az index meggyorsítja a teljesítményt, de valós időben összefűz két általános dolgot, a memóriát és a beszúrt/hozzáfűzött teljesítményt. Amikor az INDEX létrejön, a memóriát felhasználja tárolás szempontból, és az index meglehetősen nagy méreteiből adódóan, ki tudja szolgálni az óriási tranzakció-táblák igényeit is. Amikor beszúrunk egy új bejegyzést a táblába, minden index frissül, ebből adódóan több index több idő alatt frissül.
- Ugyan azon SELECT többszöri végrehajtását kerüljük a programban. Ne használjunk JOIN ciklust, ha a megfelelő standard view-nak nincs teljesítményre gyakorolt hatása.
Példakód egy optimális loop szintakszisra:
LOOP AT itab1.
LOOP AT itab2 where f1 = itab1-f1.
...
ENDLOOP.
ENDLOOP.
Natív SQL utasítások
Lehetőség van adatbázisfüggő SQL utasítás megadására és futtatására a nyelvben.
Ezeknek az utasításoknak a végrehajtása közvetlenül az adatbázisban történik.
Előnyei:
- Nem csak az ABAP Dictionary-ban deklarált táblák elérhetőek. (pl.: sys vagy system user táblái Oracle adatbázis esetén.)
- Adatbázis-függő jellegzetességek kihasználhatósága.
- EXEC és ENDEXEC között a szintaktikai ellenőrző nem fut le, ellenben a nem natív utasításokkal, ahol van szintaktikai ellenőrzés fordításkor.
- Adatbázis-függő SQL kódok nem hordozhatóak különböző adatbázis-kezelő rendszerek között.
- Mandant-függő táblák kezelését a programozónak kell megoldania.
- Adatbázis-migráció esetén a programot karban kell tartani.
DATA: P1 TYPE ZELTE_OSZT_AZON,
P2 TYPE ZELTE_OSZT_NEVE,
P3 LIKE SY-MANDT.
WRITE: sy-dbsys.
P3 = SY-MANDT.
P1 = 23.
EXEC SQL.
SELECT OSZT_AZON, OSZT_NEV INTO :P1, :P2
FROM ZELTE_OSZT
WHERE MANDT = :P3 AND OSZT_AZON = :P1
ENDEXEC.
WRITE: / P1, P2, P3.
P2 TYPE ZELTE_OSZT_NEVE,
P3 LIKE SY-MANDT.
WRITE: sy-dbsys.
P3 = SY-MANDT.
P1 = 23.
EXEC SQL.
SELECT OSZT_AZON, OSZT_NEV INTO :P1, :P2
FROM ZELTE_OSZT
WHERE MANDT = :P3 AND OSZT_AZON = :P1
ENDEXEC.
WRITE: / P1, P2, P3.
Tábla buffer
- Definiáljunk egy táblát bufferként, (SE11-ben) ami segíthet a teljesítményjavításban, de ezt a megoldást nagyon körültekintően alkalmazzuk. A táblák bufferelése a bufferből vezérli az adatok olvasását, és nem a táblából. A tábla buffer szinkronizációja rendszeresen történik, csak valamilyen változást követően módosul. Ha ez a tábla egy tranzakció-tábla akkor kockáztatjuk azt, hogy az adat meg fog változni valamely adott szelekciós kritérium alapján, ezért az alkalmazás táblák nem alkalmasak a tábla bufferelésre. A tábla bufferelése ilyen esetekben nem ajánlott.
- Tábla bufferelés műveletét alkalmazzuk konfigurációs adatra vagy esetenként Master Data-re. Akkor felmerülhet a kérdés, hogy mikor használjunk egy táblát bufferelésre? Ha a buffer feltétel nem ugyanaz, mint amit a kódban használunk, akkor nem jelent problémát.
- Ne alkalmazzunk komplex SELECT-t a bufferelt táblákban, mert az SAP nem tudja értelmezni ezt a kérést, továbbítani fogja az igényt az adtabázisnak. A Code Inspector jelezni fog, hogy mely parancsok kerülik ki a buffert.
Belső tábla
- Gyakran praktikusan válogatott táblákat használunk belső működéshez, ennek következtében az egymásba ágyazott hurkok rendben működnek.
- Ha kétségeink vannak a táblahasználat helyességéről, akkor az SE30 tranzakcióban ellenőrizni tudjuk a programkódot.
- Eszközöljünk READ TABLE BINARY SEARCH-t, amely utasítások felgyorsítják az óriási táblákban a keresést.
- Ügyeljünk arra, hogy a bináris keresés előtt rendezzük a belső táblákat. Ez egy általános szabály, de ha biztosak vagyunk abban, hogy az adat a belső táblában kevesebb, mint ötvenszer a sorok száma, akkor nincs szükségünk SORT-ra és a BINARY SEARCH-re, mivel ezzel még nem érjük el a teljesítőképesség felső határát.
Példakód a bináris keresésre:
SORT itab2 BY f1.LOOP at itab1.
* f1 az itab1 tábla akármelyik mezője
READ TABLE itab2 WITH KEY f1 = itab1 - BINARY SEARCH.
IF SY-SUBRC = 0.
idx = SY-TABIX.
LOOP AT itab2 FROM idx.
IF itab2-f1 <> itab1-f1.
EXIT.
ENDIF.
...
ENDLOOP.
ENDIF.
ENDLOOP.
Példakód a FOR ALL ENTRIES utasítás alkalmazására:
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 duplicated 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.