Weitere Hinweise zum DBACOCKPIT
OUTSOURCING DER BETREUUNG VON NON-SAP-PRODUKTEN
Welche Argumente sprechen nun dafür, mehr oder weniger Workprozesse zu konfigurieren? Das Argument für eine hohe Workprozess-Anzahl ist klar: Wenn Benutzer auf Workprozesse in der Queue des SAP-Dispatchers warten müssen, ist die Versuchung groß, ihnen mehr Workprozesse zur Verfügung zu stellen und dann zu hoffen, dass mehr Benutzer gleichzeitig arbeiten können. Dies ist dann der Fall, wenn Workprozesse durch Wartesituationen blockiert werden, die keine CPU-Leistung kosten, z. B. wenn Workprozesse in den PRIV-Modus gehen oder häufig durch Sperrsituationen auf der Datenbank blockiert sind. Auf der anderen Seite ist das »Aufdrehen« der Anzahl der Workprozesse fragwürdig, denn offensichtlich ist es langfristig sinnvoller, das tatsächliche Performanceproblem zu lösen, nämlich die Wartesituationen zu beseitigen. Das Hinzufügen von Workprozessen kann also nur Symptome abmildern, in der Regel das Performanceproblem jedoch nicht wirklich lösen.
Benutzerkontexte werden im SAP Roll Memory, im SAP Extended Memory oder im SAP Heap Memory abgelegt. Diese Aufteilung hat historische Gründe und stammt aus einer Zeit, in der der Adressraum und insbesondere der Shared Memory beschränkte Ressourcen waren.
Virtualisierungslösungen
Das Einstiegsbild gibt einen kurzen Überblick über den Status der zuletzt eingespielten Queue. Bei unvollständig eingespielten Support Packages wird der letzte (abgebrochene) Schritt der SPAM angezeigt. System: Überprüfen Sie die korrekte Funktion der Transporttools mit Hilfsmittel Transport-Tool prüfen. Stellen Sie sicher, daß genügend Platz (Größe der OCS-Dateien multipliziert mit 2) im Transportverzeichnis (siehe R/3-Profilparameter DIR_TRANS mit der Transaktion AL11 oder der Transaktion SE38 und dem Report RSPARAM) vorhanden ist. Achten Sie darauf, daß vor allem in den Unterverzeichnissen trans/EPS/in und trans/data genügend Platz zur Verfügung steht. Verwenden Sie den neuesten SPAM-Update. Überprüfen Sie, ob der im SAPNet - R/3 Frontend bzw. im SAPNet - Web Frontend angebotene SPAM-Update neuer ist als der in Ihrem System vorhandene. Sie sehen die Version des in Ihrem System vorhandenen SPAM-Update in der Titelleiste des SPAMBildes. Wir empfehlen, immer zuerst den neuesten SPAM-Update einzuspielen [Seite 14], um Probleme beim Einspielen zu vermeiden. Das Einspielen eines SPAM-Update erfolgt analog zum Einspielen von Support Packages. Es dürfen keine unvollständig eingespielten Support Packages in Ihrem System sein. Markieren Sie dazu in der SPAM unter Verzeichnis den Punkt Abgebrochene Supp. Packages und wählen Sie Anzeigen. Es dürfen keine Support Packages angezeigt werden. Die Statusanzeige sollte eine grüne Ampel zeigen. Falls das nicht der Fall ist, sehen Sie sich die detaillierten Status- und Protokollinformationen aller im System befindlichen Support Packages an. Wählen Sie dazu Springen Status bzw. Springen Protokoll. Aktivitäten Support Package laden [Seite 15] Queue definieren [Seite 17] Queue einspielen [Seite 20] Falls nötig: Modifikationen abgleichen [Seite 22] Protokolle überprüfen [Seite 23] Queue bestätigen [Seite 24].
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.
Um eine optimale Performance zu erreichen, sollte das Kopieren der Daten beim Kontextwechsel auf ein Minimum beschränkt bleiben, mit anderen Worten, es soll möglichst wenig SAP Roll Memory benutzt werden. Daher wird für alle Betriebssysteme empfohlen, ztta/roll_first = 1 zu setzen. Was passiert nun, wenn der SAP Extended Memory voll belegt ist? In diesem Fall sind zwei Szenarien möglich, die beide nicht performanceoptimal sind: Da der SAP Extended Memory voll belegt ist, werden Benutzerkontexte bis zu einer Größe von ztta/roll_area im lokalen Roll-Bereich abgelegt. Bei jedem Kontextwechsel müssen damit unter Umständen mehrmals Daten in der Größe von mehreren Megabyte kopiert (gerollt) werden; dies führt typischerweise zu Wartesituationen in der Roll-Verwaltung, insbesondere wenn der Roll-Puffer voll ist und Daten in die Roll-Datei geschrieben werden müssen. Erfahrungen zeigen, dass bei großen Applikationsservern mit mehr als 100 Benutzern die Performance in diesen Fällen schlagartig und drastisch einbricht. Um in dieser Situation Abhilfe zu schaffen, kann man den lokalen RollBereich (ztta/roll_area) reduzieren. Wenn der SAP Extended Memory voll belegt ist, wird nur noch wenig Roll Memory verwendet, und die Menge der beim Kontextwechsel zu kopierenden Daten reduziert sich. Stattdessen werden die Kontextdaten im SAP Heap Memory abgelegt – dies hat zur Folge, dass die Workprozesse gar nicht mehr rollen, sondern in den PRIV-Modus gehen, d. h. einem Benutzer zwischen den Transaktionsschritten exklusiv zugeordnet bleiben. Befinden sich zu viele Workprozesse gleichzeitig im PRIV-Modus, stehen dem Dispatcher nicht genügend freie Workprozesse zur Verfügung. Es kann daher zu hohen Dispatcher-Wartezeiten und damit ebenfalls zum Einbruch der Performance kommen.
Tools wie z.B. "Shortcut for SAP Systems" sind bei der Basisadministration extrem nützlich.
Damit einhergehend wird der Anteil administrativer Tätigkeit und somit der Anteil des Betriebs der eignen Systemlandschaft reduziert.
So viele Informationen... wie kann man die aufheben, so dass man sie bei Bedarf wiederfindet? Scribble Papers ist ein "Zettelkasten", mit dem das sehr einfach möglich ist.
Dieses Szenario umfasst auch die Unterstützung für SAP-Business-Objects-Anwendungen.