Live-Online oder Präsenz
Analyse von Hardware, Datenbank und ABAP-Applikationsserver
Das sogenannte Service Level Management (SLM) dient der langfristigen Überwachung und Optimierung. Es wird bereits von vielen IT-Organisationen zum Management der Beziehungen zwischen den einzelnen Service-providern und dem Geschäftsprozessinhaber eingesetzt. Als Service Level Management bezeichnet man eine strukturierte, proaktive Methode, die das Ziel hat, den Benutzern einer IT-Anwendung ein adäquates Serviceniveau zu garantieren – in Übereinstimmung mit den betriebswirtschaftlichen Zielen des Auftraggebers und bei optimalen Kosten. Diese Methode beinhaltet klar definierte, überprüfbare Ziele und eine klare Kommunikation zwischen den Geschäftsprozessinhabern und den Betreibern einer Lösung (dies können für Server, Datenbanken, Netzwerke etc. mehrere interne oder externe Betreiber sein). Das Service Level Management besteht zunächst aus einem Service Level Agreement, in dem die oben zu erreichenden Ziele im Hinblick auf Verfügbarkeit, Performance, Korrektheit und Sicherheit definiert werden und auch festgelegt wird, wie das Erreichen dieser Ziele gemessen und kommuniziert werden soll. Das Service Level Reporting berichtet über die Zielerreichung in einem festgelegten Zeitraum. Primäres Ziel des Service Level Reportings ist es also, festzustellen, ob die festgelegten Betriebsziele erreicht wurden, und mögliches Optimierungspotenzial aufzuzeigen.
Im SAP-Benchmark für die Anwendung SD werden Kundenaufträge, Lieferungen und Fakturen im Dialogbetrieb erstellt. In Ihrem SAP-System könnten z. B. nur Kundenaufträge im Dialogbetrieb erzeugt werden, Lieferungen und Fakturen dagegen im Hintergrundbetrieb durch sogenannte Lieferschein- und Fakturasammelgänge. Würden Sie ein Lastprofil für dieses Beispielsystem erstellen und mit dem Profil des SAP-Standard-Benchmarks vergleichen, würde sich am Verhältnis von Datenbank- und Verbuchungslast nichts ändern. Der mit Dialog gekennzeichnete Anteil würde sich dagegen in einen Dialog- und einen Hintergrundteil aufspalten.
Sizing durch den Hardwarepartner
Ein CPU-Engpass kann durch externe Prozesse verursacht werden. Finden Sie in der Prozessübersicht externe Prozesse (d. h. Prozesse, die nicht direkt zum SAP-System gehören) mit einem hohen CPU-Konsum, die zu einem CPU-Engpass führen, sollten Sie prüfen, ob diese für den Betrieb Ihres Systems notwendig sind oder ob sie abgeschaltet oder auf einen anderen Rechner verlagert werden können. Beispiele für externe Prozesse sind: Verwaltungssoftware, Virenscanner, Backup, externe Systeme, Bildschirmschoner (!) etc..
Nachdem Ihr Nutzer die benötigten Rechte für den SQL-Editor besitzt, gehen Sie wie folgt vor: Rufen Sie die Transaktion "DBACOCKPIT" auf. Öffnen Sie die folgende Ordnerstruktur in der Datenbankadministration: Performance -> Additional Functions -> SQL Command Editor Geben Sie Ihre erste Query in die Eingabeabfrage ein. Anschließend klicken Sie auf Ausführen oder drücken alternativ auf F8 Ansicht des DBA Cockpits Aufruf der Eingabeabfrage und Absetzen der ersten SQL Abfrage Ansicht der Ergebnisse einer Query zur Abfrage der Nutzer eines Systems.
Für Administratoren steht im Bereich der SAP Basis ein nützliches Produkt - "Shortcut for SAP Systems" - zur Verfügung.
Ich empfehle Ihnen, dass Sie den Hintergrundjob PFCG_TIME_DEPENDENCY mit dem Report RHAUTUPD_NEW einplanen.
Das Verständnis für die Struktur und Funktionsweise des Systems ist insbesondere für die IT-Administration wichtig. Nicht umsonst ist „SAP Basis Administrator“ ein eigenes Berufsfeld. Auf der Seite www.sap-corner.de finden Sie nützliche Informationen zu diesem Thema.
Im Kontext der SAP-Basis kann als Beispiel die Bereitstellung eines SAP-Applikationsservers für ein beliebiges SAP-System herangezogen werden.