Hirdetés
 

Speed up ABAP

PDF
Nyomtatás
speedup01.jpg

A programozás minden esetben a változók esetleg tömbök deklarálásával majd azok feltöltésével kezdődik. Akkor beszélhetünk igazi munkáról amikor már függvényekkel, ciklusokkal és objektumokkal is operálunk az adatbázisban. Nincs ez másképp az ABAP nyelvben sem. De vajon honnan tudjuk, hogy a megfelelő, leggyorsabb és a legoptimálisabb megoldásokat alkalmazzuk? A mai fejezetben megismerhetünk jó néhány praktikát amik segítségünkre lehetnek a hatékonyabb programozásban.

 

Performancia tuning

A teljesítmény növelésben sokat segít az ST05 (trace requests), SE30 (ABAP runtime analysis) és a Code Inspector.

a) Az ST05 tranzakcióban elemezhetjük a programok és tranzakciók adatbázis hozzáféréseit, tevékenységeit és jelentéseit. A művelet végén a Trace list-ben részletes nyomozati adatokat kapunk az elemzett adathalmazról.

speedup01_2.jpg

SQL trace: lehetővé teszi a tranzakciók és riportok adatbázis hozzáférésének a nyomon követését.
Enqueue trace: lehetővé teszi a tranzakciók zárt rendszerének a követését.
RFC trace: információt ad a távoli függvényhívásokról az egyes példák között.
Buffer trace: memória vizsgálat.

A következő blogban részletes leírás található az trace-k alkalmazásáról:
http://anu-sapdiary.blogspot.com/2008/02/st05-performance-trace-overview.html

 

b) Az SE30 tranzakcióban a programokat, tranzakciókat illetve a hozzájuk tartozó változók futásidejét tudjuk mérni. Programozóként gyakran találkozhatunk azzal a problémával, hogy a programunk futásidő hibára hivatkozva megszakad. Ez a vizsgálat nagyban segít kideríteni a hiba okát.

speedup01_2.jpg

Ebben a bejegyzésben többet is olvashatunk a futásidő hiba analízisről:
http://www.big4guy.com/index.php/2009/09/30/abap_runtime_analysis_how_to_perform_aba

c) A Code Inspector egy olyan eszköz ami vizsgálja a statikus ABAP kódolás és a DDIC objektumok (ezek olyan adatkönyvtár objektumok amelyek a szerveren tárolódnak, felhasználók hozzák őket létre Y vagy Z betűs megkülönböztetéssel - user exits) más szempont szerinti funkcionális helyességét, a teljesítményt, a biztonságot és a megbízhatóságot. Továbbá a fejlesztőnek segít betartani a standard programozási szabályokat és irányelveket. A Code Inspektor különféle lehetőségeket kínál az objektum halmazok meghatározásához, és összekapcsolja a több közös ellenőrzéseket az úgynevezett check variants-t.
A 'felügyelő' használható egyetlen objektum ellenőrzésére a Development Workbench-ben, a transzport objektumok ellenőrzésére a Transport Organize-ban és az objektum beállítások ellenőrzésében az SCI tranzakcióban.

További hasznos anyagok olvashatók a Code Inspector-ról a következő linken:
http://wiki.sdn.sap.com/wiki/display/ABAP/Code+Inspector

 

ABAP kódok optimalizálása

1. Adatbázis

- használjunk a WHERE ciklust a SELECT utasításban, hogy korlátozzuk az adatok mennyiségét
- tervezzünk a lekérdezésben minél több indexelt mezőt, a WHERE ciklusban lehetőleg balról jobbra használjuk a műveletet
- alkalmazzuk a FOR ALL ENTRIES-t a SELECT-ben, hogy egy lépésben tudjuk a megfelelő rekordokat letölteni
- kerüljük a beágyazott SELECT utasítást és magát a SELECT-t a LOOP-on belül, a legjobb megoldás a JOIN vagy a FOR ALL ENTRIES. A FOR ALL ENTRIES-t használjuk akkor amikor a belső tábla már rendelkezésre áll vagy már csak néhány feldolgozás van hátra. Akkor próbáljuk a JOIN-t ha már az egymás utáni SELECT-k megfelelőek.
- kerüljük a SELCET*, a SELECT egyedül csak a szükséges mezőket szelektálja a táblából
- tartalom ellenőrzésre használjuk a SELECT UP TO 1 ROWS-t és ne a SELECT COUNT-t, és ne kombináljuk a COUNT-t UP TO 1 ROW-al
- ne eszközöljünk az ORDER BY-t a SELECT utasításban ha eltérő indexeket használunk (helyette rendezzük az alap belső táblákat), mert ez egyedülállóan további munkát adhat az adatbázis rendszernek miközben több ABAP szerver is lehet
- az indexelésnek a teljesítmény javí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ória felhasználja tárolás számára, és az index meglehetősen nagy méreteiből adódóan ki tudja szolgálni az óriási tranzakció táblákat igényeit is. Amikor beszúrunk egy új bejegyzést a táblába, minden index frissül, több index több idő alatt frissül.
- ugyan azon Select többszöri Végrehajtást kerüljük a programban
- ne használjunk JOIN ciklust, ha a megfelelő standard view-nak nincs a teljesítményre gyakorolt hatása

Rövid példa a LOOP szintakszisra:

speedup01_6.jpg

2. Tábla buffer

- definiáljunk egy táblát bufferként (SE11-ben) ami segíthet a teljesítmény javításban, de ezt a megoldást nagyon körültekintően kell alkalmaznunk. A táblák bufferelése a bufferből vezérli az adat olvasást, és nem a táblából. A tábla buffer szinkron rendszeresen történik, csak valamely változás esetén 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. Tábla buffer 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 ugyan az 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, majd továbbítani fogja az igényt az adtabázisnak. A Code Inspector jelezni fog, hogy mely parancsok kerülik ki a buffert.

3. Belső táblák

- gyakran praktikusan válogatott táblákat használunk belső működéshez, ebben az esetben az egymásba ágyazott hurkok rendben működnek
- ha kétségeink vannak akkor az SE30 tranzakcióban ellenőrizni tudjuk a programkódot
- eszközöljünk READ TABLE BINARY SEARCH-t amik 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.

Egyszerű ismertető a BINARY SEARCH keresésre:

speedup01_6.jpg

Példa a sorted belső tábla olvasásra:

speedup01_6.jpg

4. További ötlet

PERFORM: Szubrutin íráskor mindig gondoskodjunk a paraméter típusokról. Ez csökkenti annak a veszélyét amikor a rendszer saját maga határozza meg a paraméterek típusát.

Mi a különbség a SELECT SINGLE és a SELECT ... UP TO 1 ROWS között?

- SELECT SINGLE és a SELECT UP TO n ROWS parancsok adják vissza a megfelelő sort vagy sorokat adott feltételeknek megfelelően. Lehet, hogy nem áll magában, ha több egyező sora van a feltételnek.
- hogy ellenőrizni tudjuk, hogy létezik-e a rekord jobb ha a SELECT SINGLE-t használjuk a SELECT ... UP TO 1 ROWS helyett, mivel a parancs kevesebb memóriát használ és jobb a teljesítménye is
- az Oracle adatbázisos rendszerek a SELECT SINGLE parancsot át tudják alakítani SELECT ... UP TO 1 ROWS-ra, így pontosan ugyan az lesz a funkcionalitás
- egyetlen különbség az az volna, hogy az ABAP szintakszis megakadályozza az ORDER BY használatát a SELECT SINGLE-l, de lehetőség van a SELECT ... UP TO 1 ROWS alkalmazására. Így ha több rekord is visszatér a lekérdezésben és számunkra csak a legnagyobb kell, akkor ne éljünk a SELECT SINGLE paranccsal hanem helyette a SELECT ... UP TO 1 ROWS, WHERE, ORDER BY-l operáljunk.

Melyik eszköz jobb a JOINS vagy a SELECT ... FOR ALL ENTRIES?

A FOR ALL ENTRIES műveletnek szüksége van először egy leellenőrzött teszt program futásra és egy SQL trace elemzésre. Bizonyos opciók által meghatározott BASIS ugyan úgy elő tudja idézni a FOR ALL ENTRIES végrehajtását mint egy 'OR' feltétel. Ez azt jelenti, hogy a táblának a FOR ALL ENTRIES-t használva három rekordja van, az SQL trace megmutatja, hogy mely hármat nyerte ki végrehajtáskor. Ebben az esetben a FOR ALL ENTRIES használata eredménytelen. Azonban az SQL trace mutat egy SQL utasítást, ami előnyös mivel ebben az esetben a FOR ALL ENTRIES valóban úgy hajtotta végre mint ha 'IN' lenne.
A JOINS-t öt csatlakozásig érdemes használni. Ha JOIN-t alkalmaztunk a mezőkben és ha ezek kulcs mezőt alkotnak minden egyes táblában, akkor csökkentik a program futást és növelik a teljesítményt. Tehát ha a JOIN két tábla között van ahol a JOINING KEY-ek kulcs mezők, a JOIN ajánlott a FOR ALL ENTRIES fölé.

Pár soros precedens a JOIN-ba beágyazott FOR ALL ENTRIES-re:

speedup01_6.jpg

A szerző a veszprémi Mérnök Informatika szakon végezett, majd egy multinál az SAP-val dolgozott key user-ként az MM,SD és XI modulokban, ahol a fő feladata a folyamatok felállítása és meglévők optimalizálása volt. 2010-től egy középvállalatnál dolgozik ugyancsak key user-ként a AM, MM, PM, PP, SD, WM területeken. Jelenleg egy SAP ugrade előkészítésén dolgozik.

További cikkek a szerzőtől


Nincs hozzászólása.
A téma megvitatása a fórumon. (0 hozzászólás)