SAP Basis: Der Start einer SAP-Instanz

(Last Updated On: 20. Juli 2015)

Am Anfang steht immer die die sogenannte sapstartsrv.exe unter Windows bzw. die sapstart-Binary unter Unix/Linux.

2015-07-07_11h27_28

Diese Binary ist im Endeffekt nichts anderes als ein kleiner Webserver, der auf den port 5<Instanznummer>13 lauscht. Diesem Webserver können über Parameter, die der Binary übergeben werden, wichtige informationen übermittelt werden, die er letztendlich zum Starten und Verwalten der restlichen Instanzbestandteile braucht. Beispielsweise muss sapstart wissen, wo die profildateien der Instanz liegen, was ihm über den Startparameter pf=<pfad zur profildatei> mitgeteilt wird. Neben dem Instanzprofil mit namen <SAPSID>_<instanz>_<hostname> greift sapstart nocha uf die instanzübergreifende Profildatei DEFAULT.PFL und in älteren SAP-Releaseversionen noch auf ein instanzspezifisches Startprofil namens START_<instanznummer>_<hostname> zu.

2015-07-07_11h32_49

sapstart hat jetzt alle nötigen Profilparameter, die notwendig sind, um die SAP-Instanz zu starten. Wie bereits besprochen, horcht sapstart auf dem Port 5<XX>13 nach eingehenden Anfragen. Beispielsweise also nach einer Anfrage, die SAP-Instanz zu starten. Diese Anfrage kann beispielsweise über die SAP Management Console unter Windows oder auch nur über das sapstart-Skritpe unter Linux/Unix erfolgen, oder auch aus der Ferne von einem anderen Rechner aus, wenn sapstart entsprechend konfiguriert wurde.

sobald sapstart eine Anfrage erhält, die SAP-instanz zu starten, tut SapStart dies antürlich auch. Dazu sind verschiedene Schritte notwendig. Zuerst müssen wir uns überelgen, wo ein SAP-System seine Daten her nimmt. NAtürlich aus der datenbank. Ohne Datenbank funktioniert kein SAP-System. Es macht daher keinen Sinn, irgendeinen Teil des SAP-Systems zu starten, bevor nicht sichergestellt wurde, dass auf die Datenbank zugegriffen werden kann.

Deswegen ist das erste, was das SAP-System macht, in den profildateien nachzugucken, welche Datenbank verwendet wird, und zu überprüfen, ob die Datenbank-Instanz bereits läuft und falls nicht, diese zu starten.

 

2015-07-07_11h43_44

Nun wisst ihr aus meinem SAP Basis / NetWevaer-post, dass SAP bestimmte prozesse mitbringt, die mit der Datenbank kommunizieren müssen. da wäre zum einen der Enqueue-Server. Dieser kümmert sich um Sperren, die verhindern sollen, dass zwei Nutzer gleichzeitig an einem bestimmten Datenstand arbeiten und dabei unabhängig voneinander Änderungen machen, wobei derjenige, der als letzter speichert, die Änderungen des anderen einfach überschreibt. Datenbanken bieten zwar in From von Transaktionen einen rudimentären Schutz dagegen, dass Daten gleichzeitig bearbeitet und geschrieben werden können und schützen daher die Daten vor Korruption durch doppelte Schreibvorgänge, jedoch können immer noch zwei Benutzer die Daten ändern, ohne zu wissen, dass gleichzeitig jemand anderes an den selben Daten arbeiten möchte. Der Enqueue Server schützt vor diesem Dilemma. Es macht also keinen Sinn, das SAP-System mit der Datenbank kommunizieren zu lassen, bevor nicht der Enqueue-Server gestartet ist. Also startet sapstart den Eqneuueserver, der wiederum selbst auf den port 32<Instanznummer> lauscht.

2015-07-07_11h49_38

Desweiteren wissen Sie vielleicht bescheid über den sogeannnten Message Server. Das SAP System arbeitet ja intern mit sogenannten OpenSQL-Statements, spricht also einen möglichst allgemeingehaltenen SQL-Slang, um Datenbankoperationen auszulösen. Diese OpenSQL-Statements funktionieren antürlich nicht immer mit dem proprietären SQL-Slang des eingesetzten Datenbankmanagementsystems. Deswegen gibt es den Message-Server, der sich darum kümmert, dass die OpenSQL-Statements in das Native SQL der eingesetzten Datenbank übersetzt werden, bevor sie an die Datenbank geschickt werden. Also muss auch der Message Server hochgefahren sein, bevor eine SAP-instanz funktionieren kann, der seinerseits auf den port 36XX lauscht.

2015-07-07_12h04_43

Zusätzlich nuss noch das Gateway gestartet werden, damit das SAP-System gleich beim Start mit fremden Systemen oder Drittanbeiterprodukten per RFC-Verbindungen kommunizieren kann. Sonst würde das system eventuell auf Fehler laufen. Mit dem Gateway-prozess sind nun alle komponenten der Zentralinstanz am Laufen.

2015-07-07_12h43_55

Erst jetzt macht es Sinn, den eigentlichen Kernel des der Anwendungsserver-Instanz zu starten, den Dispatcher. Dieser kümmert sich um die Erstellung und Verwlatung von Workprozessen und muss dazu auf die daten aus der Datenbak zurückgreifen, wobei sich die Workprozesse innerhalb des Dispatchers dazu den Funktionalitäten von Message Server und Enqueue Server bedienen, wie wir ja schon aus dem Einführungspost in die SAP Basis erfahren haben.

2015-07-07_12h45_28

Jetzt gibt es noch ein Problem. Damit der SAP Kernel mit der Datenbank kommunizieren kann, braucht es einen Datenbank-User, mit dem sich der Kernel a der Datenbank anmelden kann, und irgendwie muss der Kernel an das Passwort für diesen Nutzer kommen. Der nutzer SAPSR3 wird bei der Installation des SAP-Systems angelegt und das Passwort ist in einer verschlüsselten Datei gespeichert, der Datei SSFS. Diese Datei ist mit einem SAP-proprietären Verfahren gesichert, sodass die Datei nicht im klartext gelesen werden kann. Die infomrationen aus der SSFS-Datei kann nur über das Tool rsecssfx gelesen werden, die in der SAP-Installation enthalten ist. natürlcih kann man aber auch mit diesem Tool keine Passwörter aus der Datei auslesen.

2015-07-07_12h46_23

nun ist es wichtig zu verstehen, dass es mehrere disp+work-prozesse auf Betriebssystemebene geben wird. Einer ist als Hintergrudnprozess eingesetzt, einer für die Verarbeitung von Dialoganfragen, einer für die Verarbeitung von Spool-Aufträgen (also Drucken) usw.

Desweiteren braucht der Dispatcher zur kommunikation mti der datenbank zusätzlich eine datenbankspezifische Bibliothek, die Datei db<datenbank>slib.dll, die je nach verwendeter Datenbank anders heißt.

Woher weiß die SAP-instanz eigentlich, wo die SSFS-datei liegt ubnd wie sie heißt? das legen Sie fest über die Umgebungsvariable RSEC_SSFS_DATAPATH

Eine letzte komponente, die ich Ihnen noch vorstellen muss, ist die sogenante SAPCPE-Komponente.

wie Sie vielleicht wissen, liegen alle wichtigen komponenten des SAP-Kernels einschließlich der disp+work.exe im Verzeichnis \usr\sap\<SID>\SYS\exe\[nuc|uc]\<Architektur>

Zunächst einmal müssen Sie verstehen, dass es unterhalb des ordners, der entweder nuc oder uc heißt, mehrere Ordner für verschiedene Architekturen geben kann. Warum ist das so? nun, es kann ja sein, dass wir mehrere dialoginstanzen betreiben, also mehrere Server, auf denen sich SAP-User anmelden können, die jedoch eine unterschiedliche Architektur haben.

Beispel: wir haben eine Datenbank, und unsere SAP-user können sich einmal auf einem Windows-Server mit Intel 64-Bit-Prozessor anmelden, nauf dem auch die ASCS-Instanz läuft, oder auf einem Linux Server mit Itanium-64-Prozessor, auf dem nur eine dialoginstanz läuft.

2015-07-07_12h58_07

Wenn Sei das SAP System auf dem Windows Server starten, werden acuh die dialoginstanzen sowohl au dem windows als auch auf dem Linux server gestartet. Dabei werden die Dateien, die unter dem oben genannten Ordner gespeichert sind, je nach architektur in das Verzeichnis \usr\sap\<SAPSID>\<instanz>\exe\ kopiert. Das heißt der Widnows Ordner kriegt in seinen exe-ordner die Dateine, die unter SYS\exe\uc\ntamd64 liegen und der linux-server kriegt die Dateien,d ie unter SYS\exe\uc\uxia64 liegen. Das hat diverse Vorteile. Denn wenn Sie jetzt beispielsweise ein Kernel-Upgrade machen und mehere Server mti der gleichen Architektur haben, dann msüsen Sei das kernel-Ugprade nur einmal in dem exe\uc\<Architektur>-Verzeichnis der jeweiligen ARchitektur durchführen und der aktualosiierte Kernel wird beim Neustart des SAP-Systems automatisch auf alle Instanzen verteilt. Und wenn die instanzen dann durchgestartet werden, werden die soeben kopierten inhalte aus dem jeweiligen <instanz>\exe-Verzeichnis in das <instanz>\work-Verzeichnis verschoben, von wo aus sie ausgeführt werden. Das passiert, damit man eventuell die Dateien im <Instanz>\exe-Verzeichnis bereits manuell austauschen kann (also ohne sapcpe, wenn man das wünscht), während die instanz noch läuft, da die ausgeführten Dateine ja unter <Instanz>\work liegen und daher vom Austausch nicht betroffen sind.

die komponente, die für den Kopiervorgang der architekturspezifischen Dateien zustndig ist, nennt sich SAPCPE. Beim Starten eines SAP-Systems springt SAPCPE an zwei Stellen ein: Einmal vor dem Start der ASCS-Instanz, dort werden die Dateien für die Zentralinstanz kopiert, und einmal vor dem Start der Primary Application Server- und Dialog-Instanzen. Dort werden dann die Dateien für diese server in das jeweilige exe-Verzeichnis kopiert.

2015-07-07_13h15_12

Jetzt haben wir alle wichtigen kompoennten beim Start einer SAP-Instanz sauber abgebildet. Ich hoffe der Beitrag war für euch informativ.

Jetzt wollen wir unser Wissen um den Systemstart einer SAP-Instanz noch ein wenig verschärfen. Das, was wir bisher als „client“ betrachtet haben, ist natürlich kein klassischer SAP-Client wie SAP Logon etc., sondern symbolisiert ein kommandozeilentool, mit dem man ein SAP-system starten kann, also eine Sitzung des Users <sid>adm auf dem Betriebssystem, auf welchem die ASCS-Instanz des Servers läuft. Jedesmal, wenn das Skript startsap (nicht zu verwechseln mit der sapstart.exe) aufgerufen wird, wird nicht nur der sobeen sehr detalliert durchleuchtete Prozhess angestoßen, sondern gleichzeitig der SAP OS Collecotr (saposcol) gestartet, den wir weiter unten noch kenenlernen werden. saposcol gibt es immer nur einmal auf einem host, egal wie viele SAP-isntanzen auf diesem System verfügbar sind. DAs Skriotp startsap startet also die sapstart.exe und saposcol

2015-07-07_16h15_38

Das Testen von sapstartsrv, ob die Datenbank bereits läuft oder nicht, passiert mti dem Programm R3trans. Läuft die Datenbank, passiert nichts weiter. Läuft die Datenbank nicht, wird versucht, diese über das Skript startdb zu starten. Desweiteren ist noch erwähnenswert, dass auch der Dispatcher Zugriff auf die profildateien braucht, da der vordergrund-Dispatcher alle anderen disp+work-prozesse öffnet und dabei die Parameter in den Profildateien heranzieht.

2015-07-07_16h23_48

Bleibt nur noch zu klären, wie die Workprozesse des Dispatchers denn nun genau eine Verbindung mit der Datenbank herstellen. Wir beleuchten dies am Beispiel einer Oracle-Datenbank.

2015-07-15_12h10_47

Der Dispatcher startet die Workprozesse (1), von denen widerum jeder einzelne versucht, auf die Datembank zuzugreifen. Wie wir bereits in meinem Post Start einer SAP-Instanz gelernt haben, guckt der disaptcher dazu in die Profildateien (2) und findet dort die Daten zum Verbinden an die Datenbank. Mitn diesne infomrationen ausgestattet, verbindet sich der jeeweilige Workprozess mit dem oracle Listener prozesss und authentifiziert  über die Verbindungsdaten in der SSFS an der Datenbank an (3). Jeder einzelne Workprozess muss sich gesondert an der Datenbank anmelden.

Der Listener startet daraufhin die Schattenprozesse auf Oracle-Seite (4). Der Listener steht ständig in Verbindung mit dem Oracle PMON-Prozess, dadurch ist dieser ständig über den Status der datenbank informiert und kann diese informationen an die Schattenprozesse weiterleiten (5).

Ist der Schattenprozess erstellt, besteht zwischen Workprozess auf SAP-Seite und Schattenprozess auf Oracle-Seite eine direkte TCP/IP-Verbindung (6) und es muss nicht mehr der Umweg über den Liitener gegangen werden. Von diesem moment an hat der Workprozess über den Schattenprozess Zugriff auf das SGA und damti auf die Datenbank an sich.

für den Zugriff an sich  laden sich Datenbank-Interface und ABAP-prozessor des SAP-workprozesses die datenbankspezifische Bibliothek db<dbms>slib.dll. Diese wiederum ist abhängig zur datenbank-proprietären Client-Software, also bei einer Oracle-Datenbank beispielsweise zum oralce Instant Client. Das heißt, damit ein SAP-Workprozess eine Verbindung zur Datenbank herstellen kann, braucht er sowohl sap-seitige als auch datenbankseitige Bibliotheken, die auf die verwendete Datenbank zugeschnitten sein müssen. Hier gezeigt am Beispeil einer Oracle-Datenbank.

2015-07-20_14h00_24

 

Zu guter letzt wollen wir uns noch ansehen, wie sich Workprozesse über verschiedene Verfahren an einer Datenbank anmelden.

Aus der Oracle Datenbank kennen Sie vielleicht den sogenannten OPS$-mechanismus. Dazu wird mit dem Präfix OPS$ der Name eines Betriebssystembenutezrs in der Oracle-Datenbank abgespeichert. Versucht sich dann jemand, über den OPS$-Mechanismus anzumelden, indem er

sqlplus /

in die kommandozeile eingibt, dann scahut Oracle, ob es einen Datenbankbenutzer OPS$<Betriebssysem-Benutzername> gibt. Gibt es einen solchen nutzer, darf man sich automatisch ohne Passworteingabe als Nutzer OPS$<Betribessystem-Benutzername> an der Oracle-Datenbank anmelden. Oracle vertraut hier sozusagen der Authentifizierung des Betriebssystems.

Bei einem SAP-System läuft der Anemldevorgang noch etwas umständlicher.

2015-07-20_17h20_00

Der Workprozess vernlasst, dass in der Datenbank in der Tabelle DBA_USERS nach dem User OPS$<SAPSID>ADM gesucht wird. im Datensatz für diesen User ist kein Passwort hinterlegt, es ist also leer. Die Anmeldedaten des OPS$<SAPSID>ADM-Users werden an den Workprozess gesendet. Mit diesen Anmeldedaten meldet sich der Workprozess an der Datenbank an und liest aus der Tabelle OPS$<SID>ADM.SAPUSER das Passwort für den User SAP<SID> aus. Diese Tabelle darf es in der datenbank nur einmal geben und sie gehört dem Benutzer OPS$<SID>ADM. Wir haben also nun das Passwort für den User, über den das SAP-System auf die Datenbank zugreift.

Sie können foglendermaßen prüfen, ob die Tabelle OPS$<SID>ADM.SAPUSER wirklcih dem Datenbanknutzer OPS$<SID>ADM gehört:

select OWNER from DBA_TABLES where TABLE_NAME='SAPUSER';

Gehört die Tabelle aus welchem Grund auch immer enmal nicht mehr dem Benutzer, müssen Sie sie neu anlegen.

drop table "<besitzer-datenbanknutzername"".SAPUSER;
creeate table "OPS$<SID>ADM".SAPUSER USERID VARCHAR2(256), PASSWD VARCHAR(256));

Die Session als Benutzer OPS$<SAPSID>ADM wird abgebaut. Nun versucht sich der Workprozess, sich als Datenbankbenutzer SAP<SID> anzumelden. Ist das Passwort aus dem Datensatz in der tabelle OPS$<SID>ADM.SAPUSER korrekt, kann sich der Workprozess als Datenbankuser SAP<SID> anmelden und nun mit der Datenbank arbeiten..Schlägt der Anemldeversuch fehl, versuch der Workprozess bei einem zweiten Versuch das Standardpasswort für diesen User, welches standardmäßig bei einer SAP-installation vergeben wird.

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.