Ansicht
Dokumentation
03924 - LTO 3583 in AS/400 Three Tiers Envoirement via SAN
BAL_S_LOG - Application Log: Log header data General Data in Customer MasterThis documentation is copyright by SAP AG.
LTO 3583 in AS/400 Three Tiers Envoirement via SAN
Hi Werner,what you are there describing sounds really strange. I think this might
realy be an hardware issue. Is everything running via 1GB-Ethernet or is
there 100MB Ethernet somewhere in between ? We had this at another customer,
that the switch was very slow when changing packets from GB to 100MB.
But in your configuration, you should definitely apply the note 450351 with
the tool-version 01.01 as described there.
Regards
Volker
----------
R/3-Hinweis Nr. 450351 16.11.2001 Seite 1
________________________________________________________________________
Nummer 0450351
Version 0004 vom 16.11.2001
Status Für Kunden freigegeben
Gesetzt von Volker Gueldenpfennig am 16.11.2001
Sprache DE
Kurztext iSeries: Performance-Probleme in 3-Tier-Systemen
Verantwortlich Volker Gueldenpfennig
Komponente BC-DB-DB4 DB2 für AS/400
________________________________________________________________________
Langtext
Symptom
o Sie stellen in einem 3-Tier-System eine schlechte Performance
fest, die einhergeht mit hoher CPU-Last auf dem DB-Server, obwohl
dieser eigentlich ausreichend oder großzügig dimensioniert ist.
o Sie sehen Jobs mit dem Namen QXDARECVR oder APIAnnnnnn, die
ständig einen hohen CPU-Anteil benutzen, obwohl das SAP-System
kaum benutzt wird oder speziell der zugeordnete Workprozeß derzeit
nicht arbeitet.
o Sie installieren ein 3-Tier-System mit TCP/IP über
QXDARECVR-Datenbank-Schattenprozesse und möchten vorsorglich
verhindern, daß Ihnen oben genannte Probleme entstehen.
Weitere Begriffe
AS/400, Opoticonnect, TCP/IP, 2-Tier, 3-Tier, Performance, QXDARECVR,
Loop
Ursache und Voraussetzungen
o Durch die Konzeption bedingt, beenden sich aus verschiedenen
Gründen SAP-Workprozesse mehrmals (z.B. durch Timeouts im Dialog).
Dann ist es manchmal nicht möglich, den entsprechenden
DB-Schattenprozeß mit zu beenden. Dadurch bleibt dieser aktiv und
verbraucht weiterhin Ressourcen, ohne noch an einen Workprozeß
gekoppelt zu sein. Das Fehlen des Workprozesses wird erst erkannt,
wenn der aktuelle SQL-Befehl beendet ist, was teilweise sehr lange
dauern kann.
o Es könnte sich prinzipiell auch um einen Loop in den
QXDARECVR-Jobs handeln. Ein Loop wurde mit den folgenden PTFs
beseitigt, die unbedingt installiert sein sollten:
- V4R5M0: SF66628
- V5R1M0: SI01928
Lösung
Prüfen Sie bitte, ob die oben genannten PTFs installiert sind. Sollte
dies nicht der Fall sein, sollte dies erst nachgeholt werden.
Weiterhin sollte auf jeden Fall das CHKXDA-Tool eingesetzt werden, um
Seite 2
die durch beendete Workprozesse evtl. noch laufenden DB-Schattenprozesse
zu beenden.
Die aktuelle Version des CHKXDA-Tools ist derzeit Version 01.01
Wenn Sie eine kleinere Version einsetzen, sollten Sie auf die neueste
Version aktualisieren. Dies kann einfach mit dem folgenden Befehl
durchgeführt werden: (Dabei gehen keine notwendigen Daten verloren)
RSTLIB SAVLIB(CHKXDA) DEV(*SAVF) SAVF(CHKXDA) MBROPT(*ALL)
ALWOBJDIF(*ALL)
Die Änderungen in den verschiedenen Versionen können Sie sich dann wie
folgt ansehen:
DSPF FILE(CHKXDA/QCLSRC) MBR(VERSION)
Die Bibliothek CHKXDA befindet sich auf SAPSERVx im Verzeichnis
general/R3server/patches/COMMON/OS400/ und heißt: CHKXDA
Sie kann folgendermaßen auf die AS/400 geladen werden:
crtsavf CHKXDA
ftp sapservx
bin
cd general/R3server/patches/COMMON/OS400/
get CHKXDA CHKXDA (r
quit
Nun kann das SAVF mit dem Befehl RSTLIB in das System zurückgespielt
werden kann.
Dieses Tool wird mit dem folgenden Befehl aufgerufen:
CALL CHKXDA/CHKXDASM
Danach wird der Job CHKXDAJOBS im Batch gestartet. Normalerweise läuft
dieser Job im Subsystem QCTL. Er wartet dann 30 Sekunden und überprüft
das System erneut auf doppelte QXDARECVR Jobs.
Für Opticonnect (mit Jobs APIAnnnnnn) ist dieses Problem bisher nicht
bekannt. Sollte es auch hier ein ähnliches Problem geben, kann das Tool
CHKXDA auch dahingehend erweitert werden.
Das Tool sollte auf dem DB-Server immer gestartet sein. Dies muß mit
einem Benutzer geschehen, der DSPJOBLOG und ENDJOB ausführen darf.
In dem Datenbereich CHKXDA/DELAY kann in Sekunden die Wartezeit zwischen
den Überprüfungen verändert werden, wenn diese angepaßt werden soll.
Hier ist der Standardwert 30 Sekunden. Unabhängig von dieser Einstellung
wird in dem Job CHKXDAJOBS auch häufig DLY-59 erscheinen. Dies ist für
die Datenkonsistenz unbedingt notwendig und kann nicht verringert
werden.
In dem Datenbereich CHKXDA/JOBQ kann die Jobwarteschlange angegeben
werden, die in dem Startprogramm CHKXDASM verwendet wird. Hier ist der
Standardwert QCTL.
In der Tabelle XDAJOBS sind alle derzeit aktiven QXDARECVR Jobs
enthalten. Der aktuelle Inhalt kann wie folgt angesehen werden:
RUNQRY QRYFILE((CHKXDA/XDAJOBS))
Darin läßt sich dann sehr gut erkennen, welche QXDARECVR Jobs zu welchen
Workprozessen auf welchem Applikations-Server gehören. Zeilen, die bei
WP-Number den Wert *NONE enthalten, sind keine DB-Schattenprozesse für
Workprozesse sondern andere DB-Jobs. Sollten von dem Überwachungsjob
CHKXDAJOBS in dieser Tabelle für einen Workprozeß auf demselben
Applikations-Server mehrere QXDARECVR Jobs gefunden werden, wird der
QXDARECVR-Job mit der kleineren Jobnummer (=> der ältere) automatisch
beendet, da er nicht mehr mit einem aktiven Workprozeß verbunden ist.
Reparaturen im Coding
________________________________________________________________________
Seite 3
Gültige Releases
Hinweis ist releaseunabhängig
Weitere Komponenten
BC-OP-AS4 IBM AS/400 (inkl. IBM JVM auf OS/400)
________________________________________________________________________
Gültige Plattformen
OP-System OS/400
________________________________________________________________________
[Non-text portions of this message have been removed]
Durban Tours - Südafrika Safari
General Material Data BAL_S_LOG - Application Log: Log header data
This documentation is copyright by SAP AG.
Length: 6596 Date: 20240418 Time: 154113 sap01-206 ( 2 ms )
