Betriebsarten für die Ressourcenkonfiguration einrichten

Wie in der Abbildung „Konzept der Betriebsarten" dargestellt, können die Anforderungen der Benutzer am SAP-System im Laufe des Tages variieren. Tagsüber arbeiten viele Dialogbenutzer im System. Sie möchten vom System mit hoher Performance bedient werden. Deshalb sollten den Benutzern zu dieser Zeit viele Dialog-Workprozesse zur Verfügung stehen. In der Nacht werden jedoch nur wenige dieser Dialog-Workprozesse verwendet, da weniger Benutzer arbeiten. Dadurch werden die Systemressourcen für die Verarbeitung von Hintergrundjobs freigegeben.

Die Art und Anzahl der Workprozesse pro Instanz wird durch Profilparameter in den Profilen festgelegt. Die Verteilung der Workprozesse in den Profilen ist für schnelle Dialogantwortzeiten optimiert, d.h. es gibt in der Regel viele Dialog-Workprozesse und eine geringe Anzahl von Hintergrund-Workprozessen. Das bedeutet, dass während der Nacht Systemressourcen wie der Hauptspeicher oder die CPU weiterhin an die Dialog-Workprozesse gebunden sind und von den Hintergrundprozessen nicht voll ausgelastet werden können. Es wäre daher sehr praktisch, wenn das System verschiedene Arten und Anzahl von Workprozessen an die unterschiedlichen Anforderungen im System anpassen könnte. Dies kann durch das Konzept der Betriebsarten erreicht werden.

Wie in der Abbildung „Anpassen von Instanzen an die Lastverteilung" dargestellt, können Sie über die Betriebsarten die Art und Verteilung der Workprozesse an die unterschiedliche Lastverteilung während des Tages anpassen. Zusätzlich kann die Verteilung der Workprozesse auch an einmalig auftretende betriebliche Anforderungen angepasst werden. Durch Definition von Betriebsarten können Sie nicht nur die konfigurierbare Anzahl der in den Profilen definierten Workprozesse verändern, sondern auch die Art und die Aufteilung der einzelnen Workprozesstypen innerhalb dieser konfigurierbaren Anzahl an Workprozessen. Das Umschalten zwischen den Workprozesstypen erfolgt dabei dynamisch während der Laufzeit des SAP-Systems. Über einen festgelegten Zeitplan wird das Umschalten angestoßen. Dabei wird ein belegter Workprozess nicht sofort abgebrochen, sondern für die Umschaltung vorgemerkt. Dadurch kann es unter Umständen zu gewissen Verzögerungen kommen. Diese Typänderung wird im Systemlog erfasst.

Beim Umschalten der Betriebsarten müssen weder die Instanz noch die betroffenen Workprozesse neu gestartet werden. Dadurch bleibt bei einer Betriebsartenumschaltung die Qualität des Puffers des SAP-Systems erhalten, und der Workprozess schließt die Verarbeitung des aktuellen Requests ab. Die einzelnen Workprozesse behalten also nach der Umschaltung ihre Prozess-ID, was in der Prozessübersicht (SM50) zu sehen ist.

In einem SAP-System kann es aus verschiedenen Gründen zu Deadlocks kommen. Daher können Workprozesse reserviert werden, damit sich das System von Deadlocks befreien kann. Daher werden sie als reservierte Prozesse bezeichnet, die auch als Standby- oder eingeschränkte Workprozesse bezeichnet werden.

Reservierte Workprozesse sind immer vom Typ „Dialog". Sie können über den Parameter rdisp/wp_no_restricted definiert werden. Der Standardwert des Parameters ist o.

Reservierte Workprozesse werden während des Systemstarts gestartet und laufen im System, das Systemressourcen belegt. Sie werden jedoch nicht im Normalbetrieb verwendet, auch wenn alle Dialog-Workprozesse belegt sind und weitere Requests in der Dialog-Queue auf die Verarbeitung warten. Um mögliche Deadlocks zu vermeiden, werden diese reservierten Dialog-Workprozesse nur verwendet, wenn sich alle normalen Dialog-Workprozesse im Status Halten befinden. Sie können ihn in der Transaktion SM50 überwachen.

Wenn alle Dialog-Workprozesse gehalten werden, beginnen die reservierten Workprozesse mit der Arbeit und versuchen, den Deadlock aufzulösen. Nachdem mindestens einer der Dialog-Workprozesse nicht mehr auf Halten steht, werden die reservierten Workprozesse wieder reserviert und funktionieren nicht mehr.

Dynamische Workprozesse ermöglichen zum einen eine Art Adaptive Computing, zum anderen aber auch die automatische Umgehung von Deadlocks im SAP-System – zumindest innerhalb bestimmter Grenzen. Dynamische Workprozesse können als Zusatz zur CCMS-Betriebsartumschaltung gesehen werden (weil sie den Workprozesstyp ändern).

Dynamische Workprozesse werden im Normalbetrieb nicht verwendet. Sie werden durch den ABAP-Dispatcher gestartet, sobald sie benötigt werden, und es kann sich um Workprozesse jeglichen Typs handeln. Wenn die dynamischen Workprozesse nicht mehr benötigt werden, werden sie wieder gestoppt und belegen dann keine weiteren Systemressourcen. Im Gegensatz zu den eingeschränkten Workprozessen werden die dynamischen Workprozesse gestartet, wenn alle Workprozesse aller Typen (nicht nur der Dialog) den Status Halten haben. Sie können es in der Transaktion SM50 sehen. Dies geschieht, um Deadlocks zu vermeiden. Es dauert jedoch einige Zeit, bis dynamische Workprozesse gestartet und verfügbar werden. Das ist es, was Sie beachten müssen.

Die Anzahl der dynamischen Workprozesse kann nur indirekt definiert werden. Der Profilparameter rdisp/wp_max_no gibt die Gesamtzahl aller Workprozesse inklusive der dynamischen Workprozesse an.

Ab Kernel 7.42 ist für den Profilparameter rdisp/wp_max_no folgende Formel definiert:

$(RDISP/WP_NO_DIA) + $(RDISP/WP_NO_VB) + $(RDISP/WP_NO_VB2) + $(RDISP/WP_NO_ENQ) + $(RDISP/WP_NO_BTC) + $(RDISP/WP_NO_SPO) + MAX( $(RDISP/WP_NO_5)

Die Kernel-Standardformel ist eine Summe aller konfigurierten Workprozesse und definiert die Standardanzahl von 5 Workprozessen, die dynamisch gestartet werden sollen.

Das bedeutet: Jede Instanz hat fünf dynamische Workprozesse, solange keine beschränkten (Standby-)Workprozesse konfiguriert sind. Wenn beschränkte Workprozesse konfiguriert sind, gibt es entsprechend weniger dynamische Workprozesse (oder keine).

Sie können die Formel jedoch übersteuern.

Die Zahl der konfigurierbaren Workprozesse wird mit dem Parameter rdisp/configurable_wp_no festgelegt. Ab Kernel 7.42 ist für den Parameter folgende Formel definiert:

MAX( $(RDISP/WP_MAX_NO) - 5, $(RDISP/WP_NO_DIA) + $(RDISP/WP_NO_VB) + $(RDISP/WP_NO_ENQ) + $(RDISP/WP_NO_BTC) + $(RDISP/WNO_ENQ) + $(RDISP/WP_NO_BTC) + $(RDISP/WNO_O)

Den Parameter rdisp/configurable_wp_no sollten Sie nicht ändern.

Wie in der Abbildung „Betriebsarten einrichten" dargestellt, werden die Betriebsarten in mehreren Schritten eingerichtet.

In der Transaktion RZ04 können Sie eine normale Betriebsart und eine Ausnahmeoperationsart definieren.

Eine normale Betriebsart bedeutet, dass die Workprozesskonfiguration für eine Instanz für Zeiträume innerhalb eines 24-Stunden-Zeitraums definiert ist. Hier werden keine Lücken akzeptiert. Diese Konfiguration gilt für jeden einzelnen Tag.

Sie müssen einen Fahrplan für den Normalbetrieb definieren, bevor ein Umschalten der Betriebsarten erfolgen kann. Die im Instanzprofil festgelegte Konfiguration bleibt aktiv.

Ein Ausnahmevorgang bedeutet, dass für einen sehr bestimmten Zeitraum eine andere Workprozesskonfiguration erforderlich ist, z.B. wenn Aktivitäten wie der Import von Transporten oder eine Mandantenkopie geplant sind. Sie können eine Ausnahmebetriebsart für einen bestimmten Tag definieren, an dem die geplante Aktivität stattfinden wird. Der Ausnahmebetrieb kann nur als einmaliges Ereignis definiert werden. Nach Ablauf der Zeitspanne wechselt das System zurück in den normalen Betriebsmodus.

Beim Umschalten der Betriebsarten werden die Workprozesse automatisch neu verteilt, ohne die Instanzen anzuhalten und neu zu starten. Es werden nur die Workprozesstypen geändert. Beispielsweise kann ein Workprozess, der als Dialogprozess verwendet wird, für die Verwendung als Hintergrundprozess umgeschaltet werden.

Der neue Prozesstyp wird erst aktiviert, wenn der Prozess frei ist. Dies bedeutet, dass ein Prozess möglicherweise nicht sofort gewechselt wird. Stattdessen wird ein Prozess so eingestellt, dass er gewechselt wird, wenn es als nächstes möglich ist. Wenn beispielsweise alle Hintergrundprozesse, die auf Dialogprozesse umgestellt werden sollen, noch Jobs haben, werden die Prozesse nach Abschluss der Jobs einzeln gewechselt. Die Verarbeitung wird nicht unterbrochen. Während der Betriebsartenumschaltung wird der normale Systembetrieb unterbrechungsfrei fortgesetzt.

Die Betriebsartenumschaltung erfolgt automatisch gemäß der Konfiguration in der Zeittabelle (Transaktion SM63). Wenn Sie einen Normalbetrieb eingerichtet haben, wird der Wechsel jeden Tag innerhalb eines 24-Stunden-Zyklus wiederholt. Wenn Sie die Ausnahmebetriebsart konfiguriert haben, wird die Umschaltung automatisch für den konfigurierten Zeitraum an dem von Ihnen definierten Datum durchgeführt.

Sie können die Betriebsarten auch manuell in der Systemsteuerung (Transaktion RZ03) umschalten. Dies ist unabhängig von der Zeittabelle jederzeit möglich. Sie müssen jedoch immer sicherstellen, dass eine manuelle Betriebsartenumschaltung den Systembetrieb nicht unterbricht, z.B. weil zu wenige Dialogprozesse zur Verfügung stehen.

Sie können die Betriebsart entweder für alle Instanzen umschalten, indem Sie Steuerung → Betriebsart wechseln → Alle Server wählen, oder für eine ausgewählte Instanz, indem Sie Steuerung → Betriebsart wechseln → Ausgewählte Server wählen.

Sie können die Betriebsartenumschaltung auch zuerst simulieren, indem Sie Steuerung → Betriebsart wechseln → Simulation wählen. Dabei prüft das System, welche Instanzen umgeschaltet werden können.

Sie können eine Betriebsartenumschaltung auch über ein ABAP-Programm über einen Funktionsbaustein (RZL_PERFORM_BA_SWITCH) anstoßen.

Weitere Informationen finden Sie in der offiziellen Dokumentation auf dem SAP Help Portal: https://help.sap.com/docs/ABAP_PLATFORM_NEW/b17bd20044a44edb9aa7830ee52ffac3/04520e506567031de10000000a44538d.html

Wie bereits in dieser Lektion beschrieben, gibt es zwei spezielle Arten von Workprozessen: reservierte und dynamische Workprozesse. Die Anzahl dieser speziellen Workprozesse im System wird durch Profilparameter festgelegt.

Mit der Betriebsartenumschaltung können Sie die Anzahl der konfigurierbaren Workprozesse anpassen, ohne die Profilparameter zu ändern. Wenn Sie beim Einrichten von Betriebsarten und beim Durchführen der Verteilung von Workprozessen nicht alle konfigurierbaren Workprozesse den verschiedenen Workprozesstypen zuordnen, werden die verbleibenden Workprozesse zu dynamischen Workprozessen.

Die Abbildung „Betriebsartenumschaltung mit dynamischen Workprozessen" zeigt, dass Sie folgendes Szenario erhalten, wenn Sie zwei Dialog-Workprozesse und einen Verbuchungs-Workprozess reduzieren und die Batch-Workprozesse (Hintergrund-Workprozesse) für die Betriebsart Nacht um 1 erhöhen:

In Betriebsart: Nacht schaltet der eine reduzierte Dialog-Workprozess einen Batch-Workprozess um. Der andere reduzierte Dialog-Workprozess und der Verbuchungs-Workprozess werden gestoppt, da sie zu dynamischen Workprozessen geworden sind, da nicht alle konfigurierbaren Workprozesse den verschiedenen Typen zugeordnet wurden. Bei einem erneuten Wechsel der Betriebsart Tag wird der erhöhte Batch-Workprozess wieder zu einem Dialog-Workprozess und die beiden dynamischen Workprozesse zu einem Dialog- und Verbuchungs-Workprozess.

Die Betriebsartenumschaltung und die Zuordnung der Workprozesse werden in der Transaktion RZ04 definiert. Die Abbildung „Workprozess-Allokation bei Betriebsartenumschaltung" zeigt das Nacht- und Tagesszenario für die Instanzen des SAP-Systems S4Q. In der Betriebsart Nacht wird die Anzahl der Dialog-Workprozesse reduziert und die Anzahl der Hintergrund-Workprozesse erhöht. Die Gesamtanzahl aller aktiven Workprozesse wird durch die Spalte Summe angezeigt. Die Anzahl aller konfigurierbaren Workprozesse wird in der Spalte Kon angezeigt. Die Spalte Max gibt an, wie viele Workprozesse dynamisch gestartet werden können. Der Standardwert ist 5 mehr als alle konfigurierbaren Workprozesse. Die konfigurierbare und die maximale Anzahl der Workprozesse können nicht geändert werden.

Wenn die Zahl in der Spalte Summe kleiner ist als in der Spalte Kon, bedeutet dies, dass nicht alle konfigurierbaren Workprozesse den verschiedenen Workprozesstypen zugeordnet sind. Alle Workprozesse, die nicht allokiert wurden, werden zusätzlich zum Standardwert 5 zu dynamischen Workprozessen.

Sie können die Workprozesszuordnung nicht beliebig ändern.

Die Abbildung „Prozessübersicht beim Moduswechsel mit dynamischen Workprozessen" zeigt die Auswirkungen des gesetzten Profilparameterwerts und die Betriebsartenumschaltung zwischen Tag und Nacht. Die Workprozesse, die auf dynamische Workprozesse umgestellt und damit gestoppt wurden, sind in der Transaktion SM50 nicht sichtbar. Dort finden Sie entsprechende Lücken in der Workprozess-Nummerierung.

In der Transaktion RZ03 können Sie auch die Instanzen und die Betriebsarten überwachen.

Dort stehen Ihnen folgende Funktionen zur Verfügung:

• Überprüfen des Status aller Instanzen und der Betriebsarten

• Schalten Sie eine Betriebsart manuell um.

• Zeigen Sie eine Übersicht der verteilten Workprozesse an.

• Wechseln zum Alert-Monitor

Sie können eine detaillierte Analyse des Status der einzelnen Instanzen anzeigen, indem Sie die Instanz markieren und → Monitoring-Statusdetails wählen.

Dort erhalten Sie detaillierte Informationen über die Instanz und die aktuelle Workprozesskonfiguration aus der aktiven Betriebsart.

Über Monitoring → Alert-Monitor können Sie in die Transaktion RZ20 wechseln und die Alerts überwachen.

Wie in der Abbildung „Profilkonsistenzprüfungen" dargestellt, können Inkonsistenzen im SAP-System das Umschalten zwischen Betriebsarten verhindern. Derartige Inkonsistenzen können auftreten, wenn die Anzahl der Workprozesse an verschiedenen Stellen im System unterschiedlich definiert ist: in den Instanzprofilen auf Betriebssystemebene, im Instanzprofil in der Datenbank und in der Definition der Betriebsarten selbst.

Wird zum Beispiel die Anzahl der Workprozesse in den Profilen geändert, so kann das System nach einem Neustart der Instanz nicht mehr die Betriebsarten umschalten. Daher muss die Konfiguration der Betriebsarten in den Profilen angepasst werden, nachdem die Workprozessaufteilung geändert wurde.