SWF_ADM_SUSPEND Restart von suspendierten Callbacks
Kenntnisse oder Erfahrungen in der Administration von Server-Hardware und Speichertechnologien
Um die Auslastung des ICMs zu überwachen, rufen Sie den ICM-Monitor (Transaktionscode SMICM) auf: Werkzeuge > Administration > Monitor > Systemüberwachung > ICM Monitor. Im Eingangsbildschirm des Monitors erkennen Sie den Status der einzelnen Threads des ICMs. Im oberen Teil des Bildschirms finden Sie statistische Informationen über den Status der Threads (in der Zeile Erzeugte Threads), der Verbindungen (Zeile Benutzte Verbindungen) und der Queue (Zeile Benutzte Queue-Einträge). Einen Engpass im ICM erkennen Sie, wenn für mindestens einen dieser drei Parameter der Wert peak gleich dem Wert maximal ist.
Der erste Input bei der Durchführung einer Performanceanalyse sind die Aussagen der Benutzer. Der Workload-Monitor hilft Ihnen, die subjektiven Beobachtungen der Benutzer zu verifizieren und das gemeldete Problem weiter einzugrenzen.
Kundeneigene Entwicklungen
Wenn die mittleren Datenbankzeiten (Mittlere DB-Zeit) für die verschiedenen Rechner sehr unterschiedlich sind, ist dies ein Indiz für ein Netzwerkproblem: Denn bei symmetrisch konfigurierten Applikationsservern und unter der Voraussetzung, dass die Benutzer auf den Applikationsservern im Mittel die gleichen Transaktionen ausführen, ist nicht einzusehen, warum die Datenbank den einen Applikationsserver langsamer bedienen sollte als den anderen, es sei denn, es besteht ein Problem beim Netzwerktransfer. Diese Analyse gilt natürlich nur für symmetrisch benutzte Rechner. Bei Hintergrund- oder Verbuchungsservern oder bei Servern, auf denen hauptsächlich Reporting läuft, wird die mittlere Datenbankzeit natürlich höher liegen als bei Dialogservern.
Anhand der Workload-Analyse diagnostizieren Sie ein allgemeines Performanceproblem. Anhand des Vergleichs der Workload-Daten für unterschiedliche Tage grenzen Sie das Problem auf einen bestimmten Zeitraum ein. Auffällig sind in diesem Zeitraum hohe Datenbankzeiten, insbesondere für logische Änderungen. Bei näherer Analyse der Fehlerprotokolldatei der Datenbank stellt sich heraus, dass nachts ein Archiver Stuck aufgetreten ist. Ein Archiver Stuck tritt bei einer Oracle-Datenbank auf, wenn das Archive-Verzeichnis für Redo-Log-Dateien voll ist. Somit kann keine Redo- Information mehr geschrieben werden; die Datenbank und damit auch die SAP-Instanzen bleiben stehen. Nachdem das Problem behoben worden ist, setzen Datenbank und SAP-Instanzen ihre Arbeit ohne Fehler fort. Morgens wird das Problem vom Datenbankadministrator behoben. Im Tagesmittel führt der Archiver Stuck an diesem Tag zu erhöhten Datenbankzeiten (insbesondere für logische Änderungen). Diese suggerieren bei der Analyse des Workload-Monitors eine schlechte Datenbankperformance, obwohl diese in Wirklichkeit gut ist, nachdem das Problem behoben wurde.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
Dies wird über den Parameter rstr/accept_remote_trace konfiguriert, der auf true gesetzt sein muss.
Anhand der Anzahl der Transaktionsschritte können Sie abschätzen, wie oft die Transaktion ausgeführt wurde, wenn Sie wissen, wie viele Transaktionsschritte (Bildwechsel) ein Sachbearbeiter im Mittel pro Vorgang benötigt.