Setting Up Operation Modes for Resource Configuration

As the figure Concept of Operations Modes illustrates, the demands of users on the SAP system may vary over the course of the day. During the day, a large number of dialog users are working in the system. They want to be served with high performance by the system. Therefore, a large number of dialog work processes should be available for users during the day. During the night, however, only a small number of these dialog work processes are used, because less users are working. This frees the system resources to process background jobs.

The type and number of work processes for each instance is defined by profile parameters in the profiles. The distribution of work processes in the profiles is optimized for fast dialog response times, meaning, there are usually many dialog work processes and a small number of background work processes. This means that during the night, system resources, such as the main memory or the CPU, are still tied to the dialog work processes and cannot be fully utilized by the background processes. It would therefore be very practical, if the system could adjust different types and numbers of work processes to the different demands in the system. This can be achieved through the concept of operation modes.

As the figure Adjusting Instances to the Load Distribution shows, by using the operation modes, you can adjust the type and distribution of the work processes to the varying load distribution during the day. You can also adjust the distribution of the work processes to business requirements that only occur once. By defining operation modes, you can change not only the configurable number of work processes defined in the profiles, but also the type and distribution of the individual work process types within this configurable number. The switch between the work process types is performed dynamically during the runtime of the SAP system. The switch is triggered using a defined schedule. A reserved work process is not immediately terminated, but instead marked for switching. This means that certain delays may occur. This type change is recorded in the system log.

During the switch of the operation modes, neither the instance nor the affected work processes need to be restarted. As a result, the quality of the buffer of the SAP system is retained during an operation mode switch, and the work process finishes processing the current request. The individual work processes retain their process ID after the switch. You can observe this in the process overview (SM50).

In an SAP system, deadlocks can occur due to various reasons. Therefore, work processes can be reserved so that the system can free itself from deadlocks. That is why they are called reserved processes, also known as standby or restricted work processes.

The reserved work processes are always of type dialog. They can be defined via the rdisp/wp_no_restricted parameter. The default value of the parameter is o.

Reserved work processes are started during the system start and run in the system occupying system resources. However, they are not used in normal operation, even if all dialog work processes are occupied and further requests are waiting in the dialog queue to be processed. To avoid possible deadlocks, these reserved dialog work processes are used only when all normal dialog work processes are in Hold status. You can monitor it in transaction SM50.

When all dialog work processes are hold, the reserved work processes start working and try to resolve the deadlock. After at least one of the dialog work processes is not on Hold any longer, the reserved work processes become reserved again and are no longer working.

Dynamic work processes enable a kind of adaptive computing on the one hand, and on the other hand, enable the SAP system to free itself from deadlocks – at least within certain boundaries. Dynamic work processes can be seen as a supplement to CCMS operation mode switching (changing the work process type).

Dynamic work processes are not used in normal operation. The ABAP dispatcher starts them when they are needed and they can have any type. When the dynamic work processes are no longer needed, they are stopped again and no longer occupy any system resources. Unlike the restricted work processes, the dynamic work processes are started when all work processes of all types (not only dialog) have the status Hold. You can see it in transaction SM50. This is done to avoid deadlocks. However, it takes some time for dynamic work processes to start and become available. This is what you have to consider.

The number of dynamic work processes can only be defined indirectly. The profile parameter rdisp/wp_max_no specifies the total number of all work processes, including the dynamic work processes.

As of kernel 7.42, the profile parameter rdisp/wp_max_no is set to the following formula:

$(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_RESTRICTED), 5

The kernel default formula is a sum of all configured work processes and it defines the standard number of 5 work processes to be started dynamically.

This means each instance has five dynamic work processes, as long as no restricted, or standby, work processes are configured. If restricted work processes are configured, then there are fewer (or no) dynamic work processes, accordingly.

However, you can override the formula.

The number of configurable work processes is specified with the rdisp/configurable_wp_no parameter. As of kernel 7.42, the parameter is set to the following formula:

MAX( $(RDISP/WP_MAX_NO) - 5, $(RDISP/WP_NO_DIA) + $(RDISP/WP_NO_VB) + $(RDISP/WP_NO_VB2) + $(RDISP/WP_NO_ENQ) + $(RDISP/WP_NO_BTC) + $(RDISP/WP_NO_SPO) )

You should not change the rdisp/configurable_wp_no parameter.

As shown in the figure Setting Up Operation Modes, the operation modes are set up in a number of steps.

In transaction RZ04, you can define a normal and an exception operation mode.

A normal operation mode means that work process configuration for an instance is defined for time periods within a 24-hours time frame. No gaps are accepted here. This configuration is valid for each single day.

You must define a timetable for normal operation before a switch of operation modes can take place. The configuration in the instance profile remains active.

An exceptional operation means that for a very specific time period a different work process configuration is required, for example, when there is activity planned like import of transports or a client copy. You can define an exceptional operation mode for a specific day when the planned activity is going to happen. The exception operation can only be defined as a unique event. After the time period is over, the system switches back to the normal operation mode.

When operation modes are switched, the work processes are redistributed automatically without stopping and restarting the instances. Only the work process types are changed. For example, a work process used as a dialog process can be switched for use as a background process.

The new process type is not activated until the process is free. This means that a process might not be switched immediately. Instead, a process is set to be switched when next possible. For example, if all background processes to be switched to dialog processes still have jobs, the processes are switched one by one when the jobs are completed. Processing is not interrupted. Normal system operation continues uninterrupted during the operation mode switch.

The operation mode switch is performed automatically according to the configuration in he time table (transaction SM63. If you have set up a normal operation, the switch is repeated within a 24-hour cycle every day. If you have configured the exceptional operation mode, the switch is performed automatically for the configured period of time on the date that you have defined.

You can also switch the operation modes manually in the Control Panel (transaction RZ03). You can do this at any time regardless the time table. However, you must always ensure that a manual operation mode switch does not interrupt system operation, for example, because there are too few dialog processes available.

You can switch the operation mode either for all instances by choosing Control → Switch operation mode → All servers, or for a selected instance by choosing Control → Switch operation mode → Selected servers.

You can also simulate the operation mode-switching first by choosing Control → Switch operation mode → Simulation. The system then checks which instances can be switched.

You can also trigger an operation mode switch via an ABAP program using a function module (RZL_PERFORM_BA_SWITCH).

For more information, please check the official documentation on the SAP Help Portal: https://help.sap.com/docs/ABAP_PLATFORM_NEW/b17bd20044a44edb9aa7830ee52ffac3/04520e506567031de10000000a44538d.html

As already described in this lesson, there are two special types of work processes: reserved and dynamic work processes. The number of those special work processes in the system is defined by profile parameters.

Operation mode switching enables you to adjust the number configurable work processes without changing the profile parameters. When setting up operation modes and performing the distribution of work processes, if you do not allocate all configurable work processes to the different work process types, the remaining work processes become dynamic work processes.

The figure Operation Mode Switching with Dynamic Work Processes shows that if you reduce 2 dialog work processes and 1 update work process, and increase the batch (background) work processes by 1 for the Operation Mode: Night, you get the following scenario:

In Operation Mode: Night the one reduced dialog work process switches a batch work process. The other reduced dialog work process and the update work process are stopped, because they have become dynamic work processes, since not all the configurable work processes were allocated to the different types. When Operation Mode: Day is switched again, the increased batch work process becomes a dialog work process again, and the two dynamic work processes become an dialog and a update work process.

Operation mode switching and allocation of the work processes are defined in transaction RZ04. The figure Work Process Allocation During Operation Mode Switching shows the Night and Day scenario for the instances of SAP system S4Q. In Night operation mode, the number of dialog work processes is reduced and the number of background work processes is increased. The total number of all active work processes is indicated by the Sum column. The number of all configurable work process is shown in the Con column. The Max column indicates how many work process can be started dynamically. The default value is 5 more than all configurable work processes. The configurable and maximum number of work processes cannot be changed.

If the number in the Sum column is less than in the Con column, it means that not all configurable work processes are allocated to the different work process types. All the work processes that have not been allocated become dynamic work processes in addition to the default 5.

You cannot arbitrarily change the work process distribution.

The figure Process Overview During Mode Switching with Dynamic Work Processes shows the impact of set profile parameter value and the operation mode switching between day and night. The work processes that have been switched to dynamic work processes, and therefore were stopped, are not visible in transaction SM50. There, you will find corresponding gaps in the work process numbering.

In transaction RZ03, you can also monitor the instances and the operation modes.

There, you can use the following functions:

• Check the status of all instances and of the operation modes.

• Manually switch an operation mode.

• Display an overview of the distributed work processes.

• Switch to the alert monitor.

You can display a detailed analysis of the status of the individual instances by selecting the instance and choosing Monitoring → Status details.

There you can see detailed information about the instance and the current work process configuration from the active operation mode.

By choosing Monitoring → Alert Monitor, you can switch to the transaction RZ20 and monitor the alerts.

As the figure Profile Consistency Checks shows, inconsistencies in the SAP system may prevent you from switching between operation modes. Such inconsistencies can occur if the number of work processes is defined differently in different places in the system, namely the instance profiles at operating system level, the instance profile in the database, and the definition of the operation modes themselves.

If, for example, the number of work processes in the profiles is changed, the system can no longer switch operation modes until after a restart of the instance. You must therefore adjust the configuration of the operation modes after any change to the work process distribution in the profiles.