SAP Basis Sie möchten mehr über die verschiedenen SAP Module erfahren? - SAP Corner

Direkt zum Seiteninhalt
Sie möchten mehr über die verschiedenen SAP Module erfahren?
RÜCKFÜHRUNG VON MODIFIKATIONEN IN DEN SAP-STANDARD
Die Support Packages wurden erfolgreich in ein System (Test- oder Entwicklungssystem) eingespielt. Sie haben den Modifikationsabgleich durchgeführt. Vorgehensweise Laden Sie die Support Packages in das nächste System (Qualitäts- oder Produktivsystem). Dabei müssen Sie die folgenden Fälle unterscheiden: Ihre Systeme haben ein gemeinsames Transportverzeichnis: Releasestand 3.x: Falls die *.ATT-Dateien nicht vorhanden sind, führen Sie RSEPSDOL im Quellsystem aus und dann RSEPSUPL im Zielsystem. Wenn die *.ATT-Dateien vorhanden sind, führen Sie nur RSEPSUPL im Zielsystem aus. Releasestand 4.x: Wählen Sie SPAM Support Package Hochladen im Zielsystem. Ihre Systeme haben kein gemeinsames Transportverzeichnis: Releasestand 3.x: Führen Sie RSEPSDOL im Quellsystem aus, um die *.ATT-Dateien zu erzeugen, falls sie noch nicht vorhanden sind. Übertragen Sie mit ftp alle Dateien mit der Extension *.PAT im Binärmodus und alle mit der Extension *.ATT im ASCII-Modus aus dem Verzeichnis /usr/sap/trans/EPS/in (UNIX und AS/400) bzw. :\usr\sap\trans\EPS\in (Windows NT) des Quellsystems in das Transportverzeichnis des Zielsystems. Führen Sie RSEPSUPL im Zielsystem aus. Releasestand 4.x: Übertragen Sie mit ftp im Binärmodus alle Dateien mit der Extension *.PAT aus dem Verzeichnis /usr/sap/trans/EPS/in (UNIX und AS/400) bzw. :\usr\sap\trans\EPS\in (Windows NT) des Quellsystems in das Transportverzeichnis des Zielsystems. Wählen Sie SPAM Support Package Hochladen im Zielsystem. Spielen Sie die Support Packages wie gewohnt ein. Importieren Sie den Modifikationsabgleich-Transport. Schritte der SPAM Der SAP Patch Manager informiert Sie in der Statuszeile über den Schritt, der gerade ausgeführt wird. Wenn Sie wissen möchten, welche Schritte für welches Szenario ausgeführt werden, dann führen Sie das Programm RSSPAM10 aus.

Ein wichtiger Bereich der SAP Security ist die Analyse der kundeneigenen SAP-Programme, die klassisch in der proprietären SAP-Sprache ABAP geschrieben werden. Auch hier können, wie in allen Programmiersprachen, Sicherheitslücken programmiert werden – sei es nun bewusst oder unbewusst. Die Muster der Sicherheitslücken im ABAP-Code unterscheiden sich dabei allerdings von denen in Java-Stacks oder Windows-Programmen. Das Ziel bei diesen herkömmlichen Programmen ist es meistens, durch gezielte Falscheingaben das Programm entweder zum Absturz zu bringen (Buffer Overflow) oder künstlich eigenen Code zur Ausführung zu bringen (Code Injection). Beides ist in ABAP nicht möglich, da ein Absturz eines Prozesses nichts anderes bewirkt als das Erzeugen eines Eintrages in der Log-Datenbank (Dump ST22) und ein anschließendes Beenden des Reports mit Rückkehr an den Menüstartpunkt. Eine direkte Manipulation wie in anderen Hochsprachen oder Servern ist also nicht möglich. Allerdings gibt es andere Manipulationsmöglichkeiten.
Datenbank-Management
Der Begriff Prozessor bezeichnet bekanntlich die zentrale Verarbeitungseinheit (Central Processing Unit, CPU) eines Rechners, die in der Lage ist, Programme auszuführen. Dabei unterscheidet man zwischen Einkernprozessoren und Mehrkernprozessoren. Mehrkernprozessoren verfügen über mehrere vollständig ausgebaute Verarbeitungseinheiten (Kerne) auf einem Chip. Die einzelnen Kerne teilen sich lediglich den Bus, sind also als vollwertige CPUs anzusehen. Mehrfädige Prozessorkerne (Multi-Threaded-CPUs) verfügen über eine CPU, melden sich aber als mehrere CPUs am Betriebssystem an. Damit bilden sich für diese Kerne mehrere Warteschlangen, aus, zwischen denen der Kern hin- und herschaltet. Um diesen Wechsel zu optimieren, besitzt jeder Thread einen eigenen Registersatz, einschließlich Stack Pointer und Program Counter, damit kann ohne zusätzliche Prozessorzyklen zwischen den Threads geschaltet werden. Diese hardwareseitigen Threads sollten Sie jedoch nicht mit den Threads verwechseln, die die Anwendungsprozesse erzeugen (User- oder Software-Threads). Innerhalb eines Prozesses der Datenbank, des ABAP-, Java- oder TREX-Servers können mehrere (Software-)Threads erzeugt werden, die vom Betriebssystem in Zeitscheiben ausgeführt werden. Den Wechsel zwischen den (Software-)Threads bezeichnet man als Kontextwechsel. Unter diesem Gesichtspunkt kann man also sagen, dass zusätzliche (Hardware-)Threads Kontextwechsel zwischen (Software-)Threads begünstigen und damit den vorhandenen Kern besser auslasten helfen, allerdings von der Leistungssteigerung nicht ganz an einen zusätzlichen Kern heranreichen.

Anhand von sieben Fragen, die Sie in diesem Abschnitt und in Abschnitt 3.4.2, »Spezielles Performanceproblem analysieren«, finden, können Sie Performanceprobleme weiter eingrenzen. Richtwerte und Beispiele helfen Ihnen dabei, diese Fragen zu beantworten. Beachten Sie aber bitte, dass nicht immer eine Ja-Nein-Entscheidung möglich ist.

Für Administratoren steht im Bereich der SAP Basis ein nützliches Produkt - "Shortcut for SAP Systems" - zur Verfügung.

Anschließend gelangen Sie auf einen Bildschirm mit den statistischen Sätzen, die den Selektionskriterien entsprechen.

Auf www.sap-corner.de finden Sie ebenfalls viele nützliche Informationen zum Thema SAP Basis.

Diese Benutzer verwenden die SAPKomponente ständig und regelmäßig.
SAP Corner
Zurück zum Seiteninhalt