Externe Prozesse
SAP-System als Empfänger
Wenn Sie ein Support Package erneut einspielen müssen, weil Fehler aufgetreten sind oder das Einspielen eines SPAM-Update notwendig ist , dann setzen Sie dessen Status zurück. Zurücksetzen bedeutet nicht, daß das System auf dem alten Stand ist. Beachten Sie, daß Ihr System inkonsistent ist, wenn Sie den Status zurücksetzen, nachdem schon Objekte importiert wurden (zB nach dem Schritt DDIC_IMPORT und folgenden). Ein Zurücksetzen des Status sollte dann nur zur Fehlerbehebung dienen, und Sie sollten das Einspielen sobald wie möglich wiederholen. Vorgehensweise Um den Status eines Support Package bzw. einer Queue zurückzusetzen, wählen Sie Zusätze Status zurücksetzen. Ergebnis Nach der Aktualisierung des Status werden die entsprechenden Einträge im Cofile und in der Protokolldatei gelöscht. Das Support Package muß dann noch einmal vollständig eingespielt werden. Die Transaktion SPAM beginnt das Einspielen dann mit dem Schritt CHECK_REQUIREMENTS [Seite 26].
Es gibt folgende Gründe, die zum Abbruch dieses Schrittes führen können: CANNOT_GET_OBJECT_LIST: Die Objektliste zu einem Support Package konnte nicht gefunden werden, weil das Support Package nicht existiert. CANNOT_CHECK_LOCKS: Es wurde ein Fehler beim Ermitteln der Sperren eines Objektes in der Queue ausgelöst. OBJECTS_LOCKED_IN_REQUESTS: Es wurden Objekte gefunden, die sich in noch nicht freigegebenen Aufträgen befinden. Geben Sie diese Aufträge frei, bevor Sie mit dem Einspielen fortsetzen. SCHEDULE_RDDIMPDP In diesem Schritt wird der Transportdämon (Programm RDDIMPDP) eingeplant. Es gibt folgende Gründe, die zum Abbruch dieses Schrittes führen können: CANNOT_SCHEDULE_RDDIMPDP: Der Job RDDIMPDP konnte nicht eingeplant werden. Rufen Sie die Transaktion SM37 (Selektion von Jobs) auf, tragen Sie die folgenden Parameter ein und wählen Sie Weiter: Jobname RDDIMPDP Benutzername Start nach Ereignis SAP_TRIGGER_RDDIMPDP Wählen Sie den abgebrochenen Job aus und zeigen Sie das Jobprotokoll an.
Die SAP-Basis ist das Fundament eines jeden SAP-Systems. Viele nützliche Informationen dazu finden Sie auf dieser Seite: www.sap-corner.de.
Dokumentation und Einweisung
Einen CPU- oder Hauptspeicherengpass können Sie nach folgenden Kriterien diagnostizieren: Beobachten Sie eine hohe CPU-Auslastung oder hohe Paging-Raten im Stundenmittel? Als grobe Richtwerte geben wir an, dass die Gefahr eines Hardwareengpasses besteht, wenn die mittlere freie CPU-Kapazität (CPU idle) im Stundenmittel unter 20 % sinkt bzw. die Paging-Rate pro Stunde auf über 20 % des physischen Hauptspeichers ansteigt. Vergleichen Sie dazu auch Abschnitt 2.2.1, »Analyse eines Hardwareengpasses (CPU und Hauptspeicher)«. Prüfen Sie in einem zweiten Schritt, ob die hohe CPU-Auslastung bzw. die hohe Paging-Rate tatsächlich negativen Einfluss auf die Antwortzeit des SAP-Systems hat. Besteht der Verdacht eines Hardwareengpasses auf einem Applikationsserver, ist dies am sichersten anhand der Processing-Zeit festzustellen: Ist diese deutlich größer als die CPU-Zeit (als Richtwert Processing-Zeit > 2 × CPU-Zeit), ist dies ein Indiz dafür, dass die Workprozesse auf die CPU warten müssen. (Beachten Sie aber, dass eine erhöhte Processing- Zeit auch andere Ursachen haben kann, siehe auch Abschnitt 3.3, »Workload-Analyse«.) Zudem können erhöhte Lade-, Roll- und Dispatcher- Wartezeiten auftreten. Vermuten Sie, dass ein Hardwareengpass auf dem Datenbankserver auftritt, analysieren Sie die Datenbankzeit: Ist sie erhöht? Vergleichen Sie dazu z. B. die Datenbankzeiten im Tagesprofil zu Zeiten hoher und niedriger Last. Besteht der Verdacht auf einen Hauptspeicherengpass, vergleichen Sie, ob der virtuell allokierte Speicher deutlich größer als der physisch vorhandene Hauptspeicher ist. Sofern der virtuell allokierte Speicher kleiner ist als 1,5 × der physische Hauptspeicher, sollte ein Hauptspeicherengpass kein Thema sein (siehe auch Abschnitt 2.4.3, »Anzeige des allokierten Speichers«).
Die kontinuierliche Systemüberwachung prüft, ob alle Komponenten verfügbar sind und performant arbeiten. Ist dies nicht der Fall, wird ein Alarm ausgelöst. Die kontinuierliche Überwachung kann über die zentrale Monitoring-Architektur automatisiert werden. Zur kontinuierlichen Systemüberwachung verwenden Sie den zentralen Überwachungsmonitor (Transaktionscode RZ20) im CCMS. Dabei definieren Sie ein SAP-System als zentrales Monitoring-System, in dem dann die Fehlermeldungen aus allen SAP-Komponenten einlaufen. Bisher sind in den zentralen Überwachungsmonitor die Daten über die ABAP-Instanzen, die Java-Server, Datenbanken, Betriebssysteme sowie über weitere SAP-Komponenten wie den SAP liveCache eingebunden. Weitere Data Supplier werden auch für Nicht-SAP-Komponenten angeboten. Seit SAP NetWeaver ’04 ist der zentrale Überwachungsmonitor auch in die Oberfläche des zentralen SAP NetWeaver Administrators eingebunden, kann also auch über diesen genutzt werden.
Etliche Aufgaben der SAP Basis können mit "Shortcut for SAP Systems" einfacher und schneller erledigt werden.
Der andere Block nennt sich dann Orphan Block und ist quasi eine kleine „tote“ Abzweigung der Blockchain.
So viele Informationen... wie kann man die aufheben, so dass man sie bei Bedarf wiederfindet? Dafür eignet sich Scribble Papers ganz hervorragend.
Konkret sind dies die Änderung der BW-Modelle (siehe Kapitel 14, »Optimierung von Anfragen an SAP Business Warehouse«), die Anpassung der Kundenprogramme oder auch die Migration nach SAP S/4HANA, dem SAP-Produkt, bei dem die SAP-Programme das Potenzial von SAP HANA voll ausschöpfen.