Hirdetés
 

Top 10 ABAP dump - harmadik rész

PDF
Nyomtatás
dump1.jpgElérkeztünk a TOP 10 ABAP dump sorozat utolsó cikkéhez.
Ebben a fejezetben olvashatunk program hibákról, felhasználónévvel és belépéssel kapcsolatos problémákról, SAP patch-ekről, kernel-ekről és SAP RFC-ről. Mivel a finisben nagyon sok érdekes dologról lesz szó nem is húzom tovább az időt, vágjunk bele.

saptopdump_04.pngA negyedik dump a LOAD_PROGRAM_LOST. Ezzel a hibával, akkor találkozunk, mikor kettő vagy több adott program verzió töltődik be adott időpontban a bufferbe. Ez akkor történik meg, mikor a programot megváltoztatja egy felhasználó, mialatt ugyan ezt a programot egy másik felhasználó használja. Ha egy user megnyitja a programot, hogy ellenőrizze a problémát és R/3 kísérletet tesz a létrehozott verzió megnyitására a bufferből, és akkor látja, hogy a verzió nem érvényes és próbálja kicserélni az érvényesre, de az elmentett program hiányzik a PXA (processzor memória) bufferből, ezért dobja a LOAD_PROGRAM_LOST hibát. A nem elégséges PXA memória kombinációjának az eredménye pluszban meg kell változtatni a programokat, amelyeket jelenleg használunk. Egy futó program nem tud két különböző verzióval működni. Ennél a megoldásnál, ha a PXA memória elég nagy lenne, akkor a felhasználó a hetekig nem használt alkalmazások változásait nem látna a tranzakció újraindítása nélkül.
A másik megoldás esetében szükségünk van a SAMT tranzakció futtatására. Ezzel a lépéssel újra tudjuk kreálni a programot vagy programokat, amiket a dump kilistázott. Az érintett alkalmazás serveren parancssor mezőbe írjuk be azt, hogy $SYNC. Fontos, hogy másik alkalmazás szervereken nem fog futni a parancs.

topdump1_icon1.jpg

SAP Note 5451 - LOAD_PROGRAM_LOST

Mielőtt végrehajtunk egy ABAP programot ellenőrizzük, hogy az elmentett program elmentődött-e a program bufferben (PXA). Állíthatunk be bizonyos zárakat az elmentett programokban, amiknek következményeként nem fognak az elmentett programok kiürülni a bufferből. Mivel a program buffer mérete korlátozott, a program zárakat nem lehet hosszabb ideig fenntartani, ezért a korábban beállított zárak felszabadulnak. Ha a rendszer intenzíven működik az alkalmazás szerveren az elmentett programok elhagyhatják a puffert egy rövid időre. Ha mi megváltoztatjuk a programot az alkalmazás folytatása előtt, az adatbázis észleli, hogy a program változott és újra el tudunk menteni.
Nagyon fontos, hogy egyetlen egy befejezett programot se változtassunk meg.

topdump1_icon1.jpg

SAP Note 24824 - Inconsistencies in a Program Load

A következő hibaüzenetekkel találkozhatunk programgeneráláskor és futáskor:

- Runtime error DBIF_REPO_PART_ALREADY_EXISTS
- A-Messages: "A: Database error: No entry found for specific key"
- Runtime error LOAD_ZERO_SIZE
- Runtime error DBIF_REPO_PART_NOT_FOUND
- Runtime error GEN_SAPDEXT_CALLED
- Runtime error GEN_SAPDEXT_CALLED

Az első négy hibaüzenet a következő dolgokra utalhat. Az ABAP/4 elmentett programok négy táblában találhatóak meg az adatbázisban: D010LINF, D010L, D010Q és D010Y.
- D010L tartalmazza az aktuális ABAP/4 elmentéseket
- D010Q and D010Y tartalmazzák a sorszámhivatkozásokat vagy a generált program tábla szimbólumait
- D010LINF tartalmazza a mentések generált információit

A probléma egy újramentéssel megoldódhat. Ha ez sem segít, akkor SQL parancsok segítségével olvassuk ki a táblákból a programokat:

SELECT PROG FROM D010LINF WHERE PROG = '<progname>';
SELECT PROG FROM D010L WHERE PROG = '<progname>';
SELECT PROG FROM D010Q WHERE PROG = '<progname>';
SELECT PROG FROM D010Y WHERE PROG = '<progname>';

Ha a rendszer nem tudja a négy táblából kiolvasni a programokat, akkor töröljük a táblákból a mentési specifikus rekordokat:

DELETE FROM D010LINF WHERE PROG = '<program_name>';
DELETE FROM D010L WHERE PROG = '<progname>';
DELETE FROM D010Q WHERE PROG = '<progname>';
DELETE FROM D010Y WHERE PROG = '<progname>';
COMMIT;

A 4.6 SAP verzióban a D010Y tábla már nem használt és a SELECT from Table parancs sem használható a D010Y táblában.

Az utolsó hibaüzenet arra is utalhat, hogy az adatbázis hiba történt a végrehajtás során. Kevés volt a szabad terület a program mentéskor. Ez estben magában az elmentett programban nincs hiba. Adatbázisban kell keresni a probléma forrását.

A 3.0E verzióban ezekkel az üzenetekkel nem találkozhatunk.

saptopdump_04.pngAz ötödik dump a CALL_FUNCTION_SIGNON_INCOMPL.
Ez tipikusan RFC-hívás probléma, mikor hibás vagy rossz a belépési adat.

 

 

topdump1_icon1.jpg

SAP Note 171805 - Determining RFC client when sign-on problems occur

Rendszer hiba és ABAP runtime error is adódhat rossz RFC bejelentkezéssel. Ellenőrizzük az RFC bejelentkezési adatait. A következő információk fontosak lehetnek, de attól függnek, hogy az RFC hívás külső program vagy pedig SAP tranzakció:
- hívó program IP címe
- a hívó program host neve vagy SAP tranzakció
- R/3 felhasználó neve
- funkció modul hívásai
- hívó program bejelentkezési adatai
- külső program neve vagy R/3 művelet, amely teljesítette az RFC hívást

topdump1_icon1.jpg

SAP Note 684788 - Possible reason for CALL_FUNCTION_SIGNON_INCOMPL

A felhasználó név tartalmaz egy üres karaktert (pl. sap user). Ekkor mindenképp törölni kell a felhasználó nevet és a jövőben kerüljük el az ilyesfajta neveket. Azt ajánlom, hogy felhasználónévnek adjuk a user keresztnevének első betűjét és a családnevet, pl. Kiss Bálint -> bkiss.

topdump1_icon1.jpg

SAP Note 901256 - Rabax "CALL_FUNCTION_SIGNON_INCOMPL"

Használjunk dinamikus belépést az SAP-ban. A felhasználó nevünket látni fogjuk az SAP képernyőkön, és a felhasználó ellenőrizheti a belépéseit a logon_screen=1 funkció használatával.


saptopdump_04.pngA hatodik dump volna az RFC_NO_AUTHORITY. Ez a hiba többnyire a SAPSYS felhasználóknál jelentkezik. Ez a user belső felhasználó, ő nem rendelkezik felhasználói azonosítóval az R/3 rendszerben. Ugyanakkor minden rendszerhiba és ABAP program ezen a felhasználói azonosítón keresztül fut. A 4.0-s verzióban az auth/rfc_authority_check paramétere alapértelmezettként 1-re van állítva. Ez azt jelenti, hogy mindaddig az érték nem nulla, amíg minden RFC bejövő hívás jelölve van.
Ilyenkor vagy azt tesszük, hogy kikapacsoljuk a RFC authority Check-t (Az auth/rfc_authority_check értékét nullára állítjuk és utána újraindítjuk a szervert. Ami azt jelenti, hogy az RFC kérelmek engedélyezés ellenőrzései tiltva van.) Vagy pedig adjunk minden felhasználónak teljes RFC jogosultságot, akik csatlakozni akarnak RFC-vel a rendszerhez. Az SM59-ben mindenképp ellenőrizzük azokat a felhasználói azonosítókat, akik RFC-n keresztül kommunikálnak. Majd győződjünk meg arról, hogy a felhasználók megfelelő engedélyekkel rendelkeznek-e.

topdump1_icon1.jpg

SAP Note 171805 - Determining RFC client when sign-on problems

Az ötös pontban részletesen olvashatunk erről a dump-ról. (Sokszor előfordul, hogy egy SAP Note több dump-hoz ad segítséget.)

 

topdump1_icon1.jpg

SAP Note 93254 - RFC short dump RFC_NO_AUTHORITY

Ha az auth/rfc_authority_check paraméter értéke egyre van állítva, akkor a rendszer automatikusan elvégzi az RFC engedély ellenőrzést. Ha jogosultság nem létezik, akkor runtime error lép fel. Az AUTHORITY_CHECK_RFC modullal ellenőrizzük a jogosultságokat. Az RFC jogosultság ellenőrzéskor minden funkciós modulban ellenőrzésre kerülnek az RFC jogosultságok. A S_RFC objektummal történik az engedélyezés.

Az engedélyezési objektum a következő három területet tartalmazza:
- RFC_TYPE: RFC objektum típusa védett, terület értéke: FUGR
- RFC_NAME: RFC objektum neve védett, ez a mező a csoportok neveit tartalmazza, maximum 18 karakter lehet
- ACTVT: tevékenység, maximum 16 karakter lehet

Ha az RFC jogosultágai aktívak (auth/rfc_authority_check = 1;),
- akkor először ellenőrizzük az RFC által meghívott funkcionális csoportok jogosultságait
- deaktiváljuk az RFC jogosultságokat (auth/rfc_authority_check = 0), majd indítsuk újra a servert az új beállítással. És ellenőrizzük a profil paraméter használatot a RZ10-s tranzakcióban. Ha E értéke nulla, akkor nem éri el az alapértelmezett egyet. Ezt a hibát az RZ11-s tranzakcióban tudjuk javítani:
o lépjünk be az RZ11-be
o lépjünk be az auth/rfc_authority_check paraméterbe és válasszuk a Display-t
o az INT-n adjuk meg az OK kódot
o válasszuk a Display <-> Change
o erősítsük meg a kérelmet
o a Paramter Type módosítsuk Integer value-ról Character string-re
o mentsük a változásokat
o lépjünk ki a tranzakcióból


saptopdump_04.pngA hetedik dump a SYSTEM_NO_TASK_STORAGE. Az SAP verziónkhoz a megfelelő utolsó patch-t telepítsük. Az utolsó patch segíteni fog a problémánkon. Ez a dump egy ismert probléma és a 32 bites operációs rendszer korlátaihoz kapcsolódik. Hosszú távú megoldásokat kell használni a 64 bites Windows esetében. Az okokat mindig a régi verziójú SAP-ban kell keresni. Az SAP mindig a legfrissebb verziókat ajánlja.
Ellenőrizzük az SAP beállításainkat, majd nézzük meg, hogy vannak-e korlátozások a SAP-ban. Ha nincsenek további esetek ugyan azon a hoszton, akkor lehetővé kell tenni EM/TOTAL_SIZE_MB paraméter értékének a növekedését 4096 MB RAM-ig.

topdump1_icon1.jpg

SAP note 445533 - Lots of extended memory on AIX (64-bit)

12 GB-s memóriát tartalmazó szerverek esetében a következő konfigurációkat használjuk:
- ES/TABLE = SHM_SEGS - bekapcsoltuk az Extended Memory alternatív végrehajtását
- ES/SHM_SEG_SIZE = 256 - szegmens értékét 256 MB-ra állítottuk
- EM/TOTAL_SIZE_MB = 16384 - szükség esetén 16 GB-ra lehet emelni az Extended Memory-t
- em/global_area_MB = 250 - egzakt formula
- ztta/roll_extension = 2000000000 - körülbelül 2 GB Extended Memory áll rendelkezésre a felhasználói környezetben
- ztta/roll_area = 3000000 - csökkenti a roll memóriafogyasztást a háttérben futó jobok esetében
- ztta/roll_first = 1 - csökkenti a roll memóriafogyasztást a dialóg folyamatokban

topdump1_icon1.jpg

SAP note 153641 - Swap space requirement for R/3 64-bit kernel

A swap terület beállítása a teljes címtartományban nem elegendő az R/3 számára. A 64 bites rendszernek különösen nagy helyigényre van szüksége a címzéshez. Legalább 20 GB-s területet konfiguráljunk a 64 bites rendszernek. A 64 bites platformok szinte nulla adminisztrációs memória gazdálkodása teljesíteni tudta a virtuális címtartomány puffer területének az értékeit. Ez az annyit tesz, hogy a Customizing problémák elkerülték az egyedi tárolású területeket valamint a tranzakció megszűnés okozta drága állásidőt.

saptopdump_04.pngA nyolcadik dump a CALL_FUNCTION_NOT_FOUND. Ez a hiba annak köszönhető, hogy a program meghívott funkciója nem található a könyvtárban. A kért funkció modul nem látható a TFDIR táblában. Ugyan ezt a hibát kaphatjuk, akkor is, ha a TFDIR bufferelt verziója hibákat tartalmaz. A hiba ellenőrzését a funkció modulban is végezzük el.

 

topdump1_icon1.jpg

SAP Note 98458 - SAPMSSY1, CALL_FUNCTION_NOT_FOUND

A CALL_FUNCTION_NOT_FOUND funkció modul hívását az RFC-én keresztül próbálhatjuk. Az SM37-ben hozzuk létre a SERVERNAME_OF_LOCATION_GET funkciós modult. Majd győződjünk meg arról, hogy a modul képes-e RFC kapcsolatra és hogy aktív-e. Ez a modul létrehozott egy saptest fájlt a rendszerben, ami tartalmazza a hívórendszer információit. Ezek a rekordok nagyon hasznos információkat tartalmaznak (verzió, IP címek, rendszer), amiknek a segítségével ellenőrizni tudjuk, hogy egy ilyen rendszer létezik-e a rendszer infrastruktúrában. Ezt követően kikapcsolhatjuk a vonalat a SERVERNAME_OF_LOCATION_GET modullal, hogy a rendszer ne írja folyamatosan a fájlt. Ha ez sikerült, akkor törölhető a modul, és a vizsgálati jelentés után megszűnik a probléma.
Ha ez az eljárás nem sikerül, akkor az SM50 tranzakcióban láthatjuk a taskhandler-t, ABAP/4 processzort és a megfelelő folyamat párbeszédeit.

saptopdump_04.pngA kilencedik dump a CALL_FUNCTION_SINGLE_LOGIN_REJ. Ezzel a hibával általában akkor találkozunk, mikor nincs megfelelő belépési jogosultságunk a rendszerhez. Ez a dump négy hibaüzenettel jelentkezik:
0 - érvényes biztonsági azonosító hibás bejelentkezése
1 - a hívó rendszer biztonsági azonosítója érvénytelen
2 - a felhasználó nem rendelkezik RFC engedéllyel (S_RFCACL jogosultsági objektum), vagy pedig egyik DDIC vagy SAP védett azonosítóval jelentkeztünk be
3 - a bejelentkezési adatok időbélyege érvénytelen

topdump1_icon1.jpg

SAP Note 128447 - Trusted/Trusting Systems

Amikor létrehozunk egy trusted/trusting kapcsolatot egy trusted rendszer és egy trusting rendszer között a célállomás: TRUSTING_SYSTEM@S00 automatikusan generálódik a C00 rendszerben. Ehhez szükségünk van adminisztratív feladatokra és nem lehet használni vagy törölni a produktív forgatókönyvben. Ehhez minden esetben használjuk az SM59-s tranzakciót. Ha nem határozzuk meg a belépési adatokat az S00_TRUSTED rendszerben a C00 trusted rendszerhez a trusting S00 rendszert, akkor a rendszer kísérletet fog tenni az S00 rendszer belépéséhez azon felhasználóval, amely belépett a C00 rendszerbe, ez a helyzet áll fenn miden RFC híváskor. Ha a trusting rendszer kliense vagy nyelve nem felel meg a trusted rendszernek, akkor definiálnunk kell a klienst és a nyelvet a szcenárióban.
Ha belépéskor ugyan azt a felhasználónevet használjuk, akkor a S_RFCACL jogosultsági objektumban az RFC_EQUSER mezőt Y-ra (YES) kell állítani minden felhasználónál a trusting rendszerben.

saptopdump_04.pngAz utolsó dump a SYSTEM_CORE_DUMPED. Ez a hiba általában összefüggésben van az R/3 rendszer kernellel. Az utolsó kernel patchel frissítsünk minden esetben. De a Kernel coredump-nak (coredump - memóriamentés) a részletes elemzése nélkül nem tudunk következtetni a valódi okra. Azt ajánlom, hogy ebben az esetben vegyük fel a kapcsolatot az SAP-val.

 

topdump1_icon1.jpg

SAP Note 19466 - Downloading SAP kernel patches

Az SAP számára minden esetben a http://service.sap.com/patches -ről töltsük le a szükséges patcheket.
Először keressük meg a megfelelő kernel verziót, majd válasszunk operációs rendszert, és utolsó lépésben keressük meg a megfelelő adatbázis kernel patch specifikációt. Fontos, hogy a kernelt teljesen frissítsük, töltsük le a patcheket mind a két könyvtárból.
Patchek esetében figyeljünk a fájl nevére, rövid szöveges részre, a patch szintre és olvassuk el az Info linken a megjegyzéseket.

Telepítés lépései:
- miután megtaláltuk a megfelelő patchet, másoljuk azt egy ideiglenes könyvtárba
- majd csomagoljuk ki
- lépjünk ki az SAP-ból
- készítsünk egy másolatot a kernel könyvtárról
o UNIX: /usr/sap/<SAPSID>/sys/exe/ru
o NT: <drive>:\usr\sap\<SAPSID>\sys\exe\run
Ha 4.6D SAP verziót (64 bit, non-Unicode) vagy 6.20 illetve ennél nagyobb verziót használunk, akkor:
o NT: <drive>:\usr\sap<SAPSID>sys\exe\nuc\<platform> (Non-Unicode)
o NT: <drive>:\usr\sap<SAPSID>sys\exe\uc\<platform> (Unicode)
- így mindig van mód hiba esetén a régi kernel visszamentésére
- másoljuk vagy tegyük át a kicsomagolatlan programokat a SAP kernel könyvtárba

 

Ezzel a rövid résszel a sorozatunk végére is értünk. Mivel nagyon régen volt már az első, ezért röviden összefoglalom, hogy mikről is esett szó.
Az első anyagban részletesen kitárgyaltuk, hogy az egyes SAP verziókhoz milyen bites szervereket válasszunk. Emellett jó pár fontos további paraméterek is a terítékre került.

Második fejezetben csakis a memóriakezelést taglaltuk. Jó pár konkrét példára kész megoldást is elővezettünk.
Utolsó blokkunk elég masszívra sikerült. Kalandoztunk program hibák, felhasználói gondok és sok más nehézségek között is.


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)