Beim Einspielen von SAP Support Packages bricht die SPAM ab oder der Client verliert die Verbindung zum SAP System.

Das Fehlerbild ist dann abhängig davon, in welcher Phase dies geschehen ist. Mir ist es gerade im Main Import passiert.

Meldet man sich nun wieder am SAP System an, wird man von einer Vielzahl Dumps freundlich begrüßt

Ein Aufruf der SPAM führt ebenfalls zu Dumps (Laufzeitfehler: SYNTAX_ERROR).

Das SLOG (usr/sap/trans/log/SLOG.SID) sah so aus:

STOP MAIN IMPORT <SID> I 20110915141958 SAPUSER <HOST> 20110915123207347

ERROR: stopping on error 12 during MAIN IMPORT

HALT 20110915141958

ERROR: uncaught internal error: ORA-03114: not connected to ORACLE

ERROR: EXIT(16) -> process ID is: 18929

STOP imp all <SID> 0016 20110915141958 SAPUSER <HOST> 20110915123207347

START MAIN IMPORT <SID> I 20110915144329 <SID>adm <HOST> 20110915144329001bdd

START MAIN IMPORT <SID> I 20110915144355 <SID>adm <HOST> 20110915144355001c4a

ERROR SAPKB70207 <SID> I 0012 20110915144630 SAPUSER <SID>adm <HOST> 20110915144355001c4a

STOP MAIN IMPORT <SID> I 20110915144632 <SID>adm <HOST> 20110915144355001c4a

ERROR: stopping on error 12 during MAIN IMPORT

In diesem Fall muss man das Einspielen der Support Packages von Hand über das Betriebssystem vornehmen:

tp R3I all <SID> pf=/usr/sap/trans/bin/TP_DOMAIN_<SID>.PFL tag=spam -Dclientcascade=yes -Dstoponerror=8 -Drepeatonerror=8 -Dsourcesystems= -Dtransdir=/usr/sap/trans

Mit diesem Befehl wird dann die komplette Queue neu importiert.

Bricht der Befehl ab, sollte man ihn zuerst noch einmal wiederholen.

Anschließend kann man die SPAM wieder aufrufen und die Nacharbeiten des Imports ausführen lassen, in dem man die Queue dort wieder einspielt.

Ist der Abbruch nur bei einem Paket passiert, kann man sich auch erst den Buffer anzeigen lassen:

tp showbuffer <SID> pf=/usr/sap/trans/bin/TP_DOMAIN_SCD.PFL tag=spam

und anschließend eben jenes Packet von Hand einspielen:
tp R3I SAPKB70207 <SID> pf=/usr/sap/trans/bin/TP_DOMAIN_<SID>.PFL tag=spam –Dclientcascade=yes -Dstoponerror=8 -Drepeatonerror=8 -Dsourcesystems= -Dtransdir=/usr/sap/trans

Für ein SAP NetWeaver Portal soll SSO eingerichtet werden. Die Userverwaltung (UME) ist dabei an einen ABAP Stack angebunden.

Auf Basis des SPNEGO CONFIGURATION GUIDE der SAP wurde SPNEGO konfiguriert.

Dabei ist zu beachten, dass es ab Netweaver 7.01 SP8 ein neueres SPNEGO-Modul gibt
(https://service.sap.com/sap/support/notes/1457499 ).
Nach dem Deployen des neuen Login Modul gab es folgenden Fehler:

Could not validate SPNEGO token. [EXCEPTION]
java.lang.Exception: Checksum error
at com.sap.security.spnego.krb5.crypto.DesCrypto.decrypt (DesCrypto.java:43)
at com.sap.security.spnego.krb5.KrbEncryptedData.decrypt (KrbEncryptedData.java:81)
at com.sap.security.spnego.krb5.KrbApReq.decrypt(KrbApReq.java:67)
at com.sap.security.spnego.SPNEGOLoginModule.parseAndValidateSPNEGOToken(SPNEGOLoginModule.java:234)
at com.sap.security.spnego.SPNEGOLoginModule.processAuthorizationHeader (SPNEGOLoginModule.java:385)
at com.sap.security.spnego.SPNEGOLoginModule.login (SPNEGOLoginModule.java:102)

…

Dieser Fehler taucht auf Grund eines ungültigen Keytab Files auf. Dieses kann man dann nach dem SAP Hinweis 1568553 neu anlegen.

Wichtig ist noch, dass die Einstellung für das SPNEGO Modul im Visual Admin ( unter ticket authentication) richtig vorgenommen wurde:

Visual Admin – Server – Services – Security Provider

“ticket component”

” SPNEGOLoginModule” muss auf REQUISITE und nicht auf SUFFICIENT eingestellt sein.

Wenn man sich mit dem SYSTEM Account an eine Oracle DB anmeldet, bekommt man einen ORA-28011. Die Anmeldung funktioniert dann zwar, aber oft wird diese “Fehler” Meldung von Skripten nicht abgefangen, sondern diese brechen ab.

Zuerst schauen wir uns an, zu welchem Profil der Benutzer gehört:

SQL> select username, profile from dba_users;

USERNAME PROFILE

—————————— ——————————

SAPR3 SAPUPROF

SYS DEFAULT

DBSNMP DEFAULT

OUTLN DEFAULT

OPS$ORAF3D DEFAULT

OPS$F3DADM DEFAULT

DIP DEFAULT

SYSTEM DEFAULT

ORACLE_OCM DEFAULT

APPQOSSYS DEFAULT

10 rows selected.

SQL>

Nun schauen wir uns die Beschränkungen für alle User mit dem Profile “DEFAULT” an:

select LIMIT, RESOURCE_NAME from dba_profiles

where  PROFILE = ‚DEFAULT’

and RESOURCE_NAME in

(‘PASSWORD_GRACE_TIME’,'PASSWORD_LIFE_TIME’, ‘PASSWORD_REUSE_MAX’,'PASSWORD_REUSE_TIME’);

LIMIT RESOURCE_NAME

—————————————- ——————————–

180 PASSWORD_LIFE_TIME

UNLIMITED PASSWORD_REUSE_TIME

UNLIMITED PASSWORD_REUSE_MAX

UNLIMITED PASSWORD_GRACE_TIME

Und hier sehen wir auch schon das Problem, die Life_Time steht auf 180. Mit dem Kommando:

select ptime,sysdate, floor(sysdate- ptime) from sys.user$ where name= ‚SYSTEM’ kann man herausfinden, wann das Kennwort zum letzten Mal geändert worden ist.

Nun gibt es zwei Lösungsmöglichkeiten, entweder verändert man die PASSWORD_LIFE_TIME:

alter profile default limit PASSWORD_LIFE_TIME unlimited;

oder man ändert im SQL mit password einfach das Kennwort des Benutzers.

sapevent bekommt keine Verbindung zum SAP System 
Der Upgrade eines BW 70 auf EHP1 ist in den Phasen TABIM_UPG und XPRAS_UPG stehen geblieben.

Leider wurde im Installationstool (hier EHPI) kein Fehler angezeigt, aber die entsprechenden Phasen sind nicht zum Ende gekommen.

Das Programm sapevent versucht über RFC einen Batchjob im SAP(Schatteninstanz) zu starten, dies bricht jedoch mit der Fehlermeldung ab:

received 4 bytes from MSG_SERVER Received opcode MS_DUMP_INFO from msg_server, reply MSOP_ACCESS_DENIED
MsOpReceiveReceived opcode MS_DUMP_INFO failed, reason MSOP_ACCESS_DENIED
MsDump : failed MSOP_ACCESS_DENIED (5)
*** ERROR ***: Get message server parameters, rc = 5″

Dann warte der Upgrade Prozess einige Zeit und versucht es erneut und so weiter und so weiter…

Die Fehlermeldung findet man in der Datei dev_evt im tmp Verzeichnis der Installation, bzw. man kann das sapevent Tool auch manuell mit der Option -t starten, dann wird die Trace Datei im aktuellen Verzeichnis erstellt.

Zu dem Fehler kommt es, weil der sapevent die Profildatei DEFAULT.PFL zur Ermittlung des Ports für den Message Server liest.
In meinem aktuellen Fall wird dieser Port aber durch einen Eintrag im Instanzen Profil überschrieben (rdisp/msserv_internal).
Das heißt, das SAP System laust auf “rdisp/msserv_internal” und sapevent spricht den Message Server Port aus dem Default Profil an und kann so keinen Connect zu dem SAP System bekommen.
Zur Lösung habe ich den Parameter im DEFAULT Profil korrigiert.