SAP Basis

Die Aufrechterhaltung der Verfügbarkeit von kritischen Geschäftsprozessen benötigt nicht nur eine hochwertige Infrastruktur. Aufgrund der Komplexität werden hohe Anforderungen an das Management und den Betrieb der darunter liegenden SAP NetWeaver Plattform gestellt, die oft auch einfach als SAP Basis bezeichnet wird. Die wachsende Anzahl an installierten Komponenten (wie z.B. SAP BW, SCM, SRM, PI/PO) und über Schnittstellen integrierte Systeme (RFC, WebServices) erhöhen diese Anforderungen weiter.

Mehr lesen…

Blogartikel zu SAP Basis:
Externes Hosting und Funktionstrennung machen mittlerweile die Suche nach Ursachen für Performance Engpässe zu einer Aufgabe mit vielen Beteiligten. Es gibt aber durchaus einige SAP Transaktionen, mit denen man auch ohne Root-Prompt und Zugriff auf den Solution Manager Informationen über den Teil unterhalb des ABAP Stacks sammeln kann. OS07N Operating System Monitor (neu)DieOS07N (Report RSHOST1N) bietet eine schnelle Übersicht über Betriebssysteminformationen und Speicherauslastung. Vor allem aber kann man schnell zwischen den Applikationsservern hin und her springen und so sich einen guten Überblick über alle beteiligten Systeme verschaffen. Die Daten basieren auf Informationen die via CCMS und dem saposcol (Operating System Collector) eingesammelt werden.ST06 – Operating System Monitor (alt)Da vor allem die historischen Werte in der OS07N oft nicht abrufbar sind und erst konfiguriert werden müssen, leistet die ST06 weiterhin gute Dienste. Tipp: Auf den jeweiligen Applikationsserver kann man über die SM51 springen: Doppelklick auf den Applikationsserver öffnet einen neuen Modus auf dem Applikationsserver.Daily Averages – Last 30 Days erlaubt einen Überblick über die letzten 30 Tage. Über Details kann man sich dann wiederumm die Details für einen Tag auswählen.Wenn man “More information” auswählt kann man durch die verschiedenen Sichten CPU, Memory, Disk times, LAN, Filesystem statistics durchschalten.Report RSBDCOS0 – Betriebssystemkommandos ausführenMit dem Report RSBDCOS0 kann man Befehle auf Betriebssystemebene absetzen – allerdings im Kontext des SAP System-Users. Also zum Beispiel <sid>adm oder SAPService<SID>. Dort gehen dann natürlich nur Befehle die keine root/Administrator-Berechtigungen benötigen.
Bei der Aktualisierung des BI Contents (auf BI_CONT 7.06) gab es in der SAINT einen Abbruch in der Phase RS_DTRF_AFTER_IMPORT/XPRA_EXECUTION: Quellsystem <Name des Quellsystems> existiert nicht (RSAR203). Nach kurzer Suche sind wir auf Hinweis 1564964 gestoßen: Den Funktionsbaustein RSAR_LOGICAL_SYSTEM_DELETE in der SE37 mit I_LOGSYS = <zu löschendes Quellsystem> und alle anderen Parameter = ‚X’ ausführen. (Vorher beachten, ob der dort erwähnte Hinweis eingespielt worden ist)Das Problem dabei war: Wir mussten den Import in der SAINT immer wieder starten und jedes mal wurde nur genau ein Quellsystem als verwaist gemeldet. Es stellte sich aber hinterher heraus, dass verwaiste Einträge von fast einem Duzend Quellsystemen im System vorhanden waren. Die Laufzeit des Upgrades steigerte sich damit um zwei Tage, da er immer wieder nach der Bereinigung eines Systems neu gestartet werden musste.Ich habe leider keinen offiziellen Weg gefunden, um im Vorfeld verwaiste Quellsysteme zu finden. Daher habe ich versucht, der Datenbank etwas Brauchbares zu entlocken. Die Tabelle RSBASIDOC enthält die Quellsysteme, so wie man sie auch in der RSA13 sehen kann. Da in den Hinweisen die Tabelle RSOLTPSOURCE für BW 3.x als Workaround genannte wird, habe ich schließlich folgendes SQL-Statement entwickelt: select distinct logsys from  RSOLTPSOURCE where logsys not in (select slogsys from RSBASIDOC) Dieses Statement kann man z.B. auch über das DBACOCKPIT absetzen. Die Ergebnisliste wurde dann vom Anwendungssupport geprüft. Tatsächlich waren alle Treffer Quellsysteme, die schon vor einiger Zeit aus der RSA13 entfernt worden sind. Mit der Liste und dem Vorgehen aus Hinweis 1564964 konnten wir die verwaisten Quellsysteme im Vorfeld löschen und die Upgradezeit in den Folgesystemen von drei Tagen auf wenige Stunden verkleinern.
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üßtEin 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> 20110915123207347ERROR: stopping on error 12 during MAIN IMPORTHALT 20110915141958ERROR: uncaught internal error: ORA-03114: not connected to ORACLEERROR: EXIT(16) -> process ID is: 18929STOP imp all <SID> 0016 20110915141958 SAPUSER <HOST> 20110915123207347START MAIN IMPORT <SID> I 20110915144329 <SID>adm <HOST> 20110915144329001bddSTART MAIN IMPORT <SID> I 20110915144355 <SID>adm <HOST> 20110915144355001c4aERROR SAPKB70207 <SID> I 0012 20110915144630 SAPUSER <SID>adm <HOST> 20110915144355001c4aSTOP MAIN IMPORT <SID> I 20110915144632 <SID>adm <HOST> 20110915144355001c4aERROR: 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/transMit 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=spamund 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
In der Regel kommt der Betrieb der SAP Applikationsserver und der Netzwerk-/Firewall-Infrastruktur nicht aus einer Hand. Das kann die Ursachenanalyse für ein Problem erschweren. Gut wenn man als SAP Basis Mitarbeiter ein paar Werkzeuge kennt, um Applikationsprobleme von gestörten oder abgeschotteten Netzwerkverbindungen abgrenzen zu können. Telnet Hinweis: Bei neueren Windows-Installationen muss man den Telnet-Client erst nachinstallieren. Unter Linux/Unix ist es im Standardumfang enthalten.Aufruf:telnet hostname portBeispiel:telnet meinsaprouter.company.com 3299 Wird die Console schwarz und ein Cursor blinkt links oben dann ist die Verbindung erfolgreich hergestellt worden. Die Verbindung beenden kann man mit “CTRL++” und der Eingabe quit.Blockiert eine Firewall die Verbindung, dann dauert es eine Weile bis schließlich ein Timeout gemeldet wird.Wird die Verbindung aufgebaut, aber gleich darauf getrennt, ist die Wahrscheinlichkeit hoch, dass es ein saprouter/Dienst-Problem ist.Niping Mit niping kann man die Verbindung zu einem Dispatcher oder Gateway testen, inklusive der SAP Router dazwischen. Dies ist ein deutlicher Vorteil gegenüber den direkten Tools wie telnet und netcat. Tipp: Über den Report RSBDCOS0 kann man das Programm direkt auf dem Applikationsserver ohne Betriebssystemzugriff laufen lassen. Aufruf:niping -c -H HOSTNAME oder SAPROUTERSTRING -S PORT 1. Beispiel: [1]niping -c -H /H/meinsaprouter.company.com -S sapdp99[1]ReturnCode= 1-ng -c -H /H/meinsaprouter.company.com -S sapdp99Sun Aug 21 18:22:07 2011***LOG Q0I=> NiPConnect2: meinsaprouter.company.com:3299: connect (10061: WSAECONNREFUSED: Connection refused) [nixxi.cpp 3133]*** ERROR => NiPConnect2: SiPeekPendConn failed for hdl 1/sock 268(SI_ECONN_REFUSE/10061; I4; ST; meinsaprouter.company.com:3299) [nixxi.cpp 3133]*** ERROR => NiTClientLoop: NiHandle (rc=-10) [nixxtst.cpp 2529]2. Beispiel: [2]niping -c -H /H/meinsaprouter.company.com -S sapdp99[2]ReturnCode= 1-ng -c -H /H/meinsaprouter.company.com -S sapdp99Sun Aug 21 18:25:01 2011connect to server o.k.*** ERROR => NiBufIProcMsg: hdl 1 received rc=-93 (NIEROUT_INTERN) from peer [nibuf.cpp 2115]*** ERROR => NiTClientLoop: NiTReadLoop (rc=-93) [nixxtst.cpp 2529]Bei dem ersten Beispiel war der SAP Router Dienst nicht gestartet, beim zweiten Beispiel war der Zugriff erfolgreich. Die “*** ERROR” Nachrichten kann man vernachlässigen. Netcat Für andere Netzwerkdienste (z.B. Test ob der Mailserver-Port offen ist) kann man neben telnet auch netcat sehr gut einsetzen. Allerdings ist das Programm nur in der Unix/Linux-Welt im Standardumfang verfügbar. Aufruf:netcat -w5 -z -v HOSTNAME PORT-w 5 sekunden warten-z port scanning only-v verbose Beispiel:[6]netcat -w5 -z -v mail.company.com 25 2>/tmp/test_mailtest.txt[7]cat /tmp/test_mailtest.txtmail.company.com [10.0.0.1] 25 (smtp) open Durch die Parameter im Beispiel läuft netcat nicht-interaktiv und ist damit auch wieder für den SAP Report RSBDCOS0 geeignet.Sie benötigen Unterstützung bei der Umsetzung? Unser Autor Tobias Harmes ist Berater für dieses Thema. Fragen Sie ihn an über das RZ10.de Partnerprodukt Berater für SAP Basis
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.Vorgehen Zuerst schauen wir uns an, zu welchem Profil der Benutzer gehört: SQL> select username, profile from dba_users;USERNAME PROFILE—————————— ——————————SAPR3 SAPUPROFSYS DEFAULTDBSNMP DEFAULTOUTLN DEFAULTOPS$ORAF3D DEFAULTOPS$F3DADM DEFAULTDIP DEFAULTSYSTEM DEFAULTORACLE_OCM DEFAULTAPPQOSSYS DEFAULT10 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_profileswhere  PROFILE = ‚DEFAULT’and RESOURCE_NAME in(‘PASSWORD_GRACE_TIME’,’PASSWORD_LIFE_TIME’, ‘PASSWORD_REUSE_MAX’,’PASSWORD_REUSE_TIME’);LIMIT RESOURCE_NAME—————————————- ——————————–180 PASSWORD_LIFE_TIMEUNLIMITED PASSWORD_REUSE_TIMEUNLIMITED PASSWORD_REUSE_MAXUNLIMITED 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.
Anbei eine Übersicht über die wichtigen Transaktionen für den Betrieb einer Oracle Datenbank unter SAPTransaktion Name BeschreibungDBACOCKPIT Admin Cockpit Zentraler Einstieg in die Oracle Administration (DB02, DB13)DB01 Oracle Lock Monitor Anzeige von Oracle Locks, auf die gewartet werden mussDB02 Database-Performance Übersicht über Tablespace und Tabellen / Indexe der Datenbank mit Einstieg in DetailanalysenDB03 Parameteränderung der Datenbank Anzeige der Datenbankparameter inklusive ihrer ÄnderungshistorieDB12 Sicherungsprotokolle Überblick über die Historie der Datenbank und der Redo-Log SicherungenDB13 DBA Einplanungskalender Kalender um Datenbankoperationen einzuplanen, wie DB Checks oder Aktualisierung der Oracle StatistikenDB14 Protokollanzeige DBA Anzeige der Protokolle aller Operationen der BR* ToolsDB16 Datenbankprüfungen Anzeige der Fehlermeldungen und Warnungen des letzten DB ChecksDB17 Datenbankprüfbedingungen Pflege der Datenbankprüfbedingungen beim Einsatz von DB-Checks (BR*Tools)DB20 Tabellenstatistik Überblick über die Statistik einer einzelnen Tabelle und Neuanlegen, wenn nötigDB21 Konfiguration der Statistikerstellung Pflege der Statistik-Ausnahmetabelle DBSTATCDB24 Protokolle administrativer DB Operationen Statusanzeige (Ampelsystem) von DB Operationen wie Backups, Checks und StatistikläufenDB26 Datenbankparameter Anzeige und Pflege (eingeschränkt) der Oracle Parameter (detaillierter als DB03)DBCO Datenbankverbindungen Pflege von Datenbankverbindungen, die vom System genutzt werden können, z.B. bei DB26 (NICHT Verbindung Workprozesse – Schattenprozesse!)ST04N Datenbank-Performance-Monitor Überblick über Oracle Performancekennzahlen, Session Monitor, V$Tables, SGA und PGA MonitorEs sind die “alten” Transaktionen angegeben, in neuen Releasen muss teilweise noch ein “old” ergänzt werden, da der Aufruf sonst zum DBACOCKPIT führt (z.B. DB02OLD).
sapevent bekommt keine Verbindung zum SAP System Das 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 wartet 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.
Angebot anfordern
Preisliste herunterladen
Expert Session
Support