Understanding the Concept of Start and Stop Procedures

Objectives

After completing this lesson, you will be able to:
  • Explain the file system structure of AS ABAP
  • Explain the general mechanism of starting and stopping AS ABAP
  • List organizational considerations before stopping AS ABAP

File System Structure

Each instance of an SAP system requires data in the file system. This includes data that all instances can access (globally) and data that can only be accessed by an instance individually. In the file system, the data for the instances is contained in the usr/sap directory, where it is further organized in subdirectories. This structure is shown in the following figure File System Structure of an AS ABAP based SAP System (generic view).

Hint

The business data and other data is stored in the database, which has its own structure in the file system, depending on the database manufacturer, but is not covered by the usr/sap directory.

Caution

The OS-specific characteristics are not covered in the figure above. For example there is no separation of physically and logically shared directories. However, an abstraction of the underlying operating system makes only sense to a specific extent. That is the reason, why some OS-specifics are covered below.

The <SAPSID> directory contains all data that must be accessed only by this SAP system.

As shown in the figure above, the SYS directory contains information that can be accessed by all instances:

UNIX/Linux operating system
SYS directory is located in its own file system with the name sapmnt. The SYS directory is then created in the file system of each instance and contains links to the subdirectories of the sapmnt file system.
Windows operating system
SYS is usually located in the file system in which the PAS instance is located. A share with the name sapmnt is created based on the sap directory above the <SAPSID>/SYS directory. This share allows all instances to access the SYS directory.

The SYS directory contains the following subdirectories:

  • global contains information, which is relevant for the entire SAP system, but stored centrally (for example, security data like the SSFS-key or snapshots created by the SAP system).
  • profile contains profiles used to start the SAP system and their instances (for example, the default profile and the instance profiles).
  • exe contains the global kernel directory (including programs and libraries), which serves as a source for the installed instances.

Note

The global exe directory contains the subdirectory <codepage>, which itself includes a folder called <platform>. The only supported <codepage> is in the meantime uc (Unicode), but in exceptional cases still nuc (non-Unicode) for systems based on lower releases.

Hint

SAP HANA based systems only support Unicode as codepage.

Each instance has its own directory tree and the name contains the 2-digit instance number. If several instances are installed on the same host, each individual instance gets a unique instance number. The instance-specific content (PAS, AAS, ASCS) is located in the respective D<no> directories (where <no> is the instance number). The instance directories include individual work sub-folders, which themselves serve as storage location for - among several other files - log and trace files written during start and stop operations. A further important instance-specific sub-folder is the exe directory where the (replicated) kernel is stored locally. These are essential programs that are started instance-specific when the SAP system is started.

Start Process: SAP System

As an SAP system administrator, you should be familiar with the process of starting the ABAP based SAP system. It is a fundamental administrative task, which requires knowledge of the SAP system architecture including some specific release-dependent changes. Furthermore the start procedure is the basic prerequisite for any ABAP user to be able to log-on and work within the SAP system. In addition, restarts of SAP systems are required for a wide range of different maintenance tasks, whether hardware enhancements, software changes or configuration changes to the SAP system's profiles.

This lesson describes the process flow when starting an SAP system. Every SAP system uses a database and consists of instances. An SAP system based on AS ABAP usually includes an ABAP central services instance (ASCS) that offers the ABAP Enqueue Server and the ABAP Message Server, as well as a Primary Application Server (PAS) instance with an ABAP Dispatcher and ABAP Work Processes. In this case, the PAS instance does not have an ABAP Enqueue Work Process or an ABAP Message Server.

Start Process: Database

The database is the fundamental element of the entire SAP system. Working within an ABAP based SAP system always requires an up and running database.

For an SAP S/4HANA Server system, or generally speaking SAP systems running on an SAP HANA database, the database typically is started separately (manually or scripted) before the SAP system starts, regardless if it is installed on the same host or not.

Note

For most non SAP HANA based databases, the following mechanism is used:

  • If the database has not yet been started, this will be done automatically, shortly before starting the PAS and AAS instances (but only if the database is installed on the same host as the PAS or AAS instances).
  • If the database is installed on separate host/s, it has to be started separately before starting the SAP system.

PAS (Primary Application Server) and AAS (Additional Application Server) instances require an already started database, to which their ABAP work processes are able to connect when the instance is started. Thus, the database must be in an operational state before starting this type of instance (AS-based). This also applies to the formerly known "central instance" and "dialog instances" in earlier technical releases.

Within this class there is no further discussion of the dedicated database tools to start (or stop) the corresponding database. Nevertheless, databases supported by SAP can also be controlled by SAP tools like the SAP Management Console (SAP MC) via the SAP Host Agent, SAPControl or by utilities provided by the database vendor.

Hint

The start sequence is explained in more details later on in this lesson.

The requirement to ensure that the database is in operational state when starting the PAS and/or AAS instances will be covered in a following lesson within this Unit. This is of particular importance, if the database is installed on an explicit host.

Start Process: Priorities

To make the overall start procedure of an SAP system easier and provide a better transparency, SAP implemented the use of Priorities. These are assigned numbers using a parameter during installation to different types of instances.

Core principle of priorities:

The lower the number, the higher the priority. As a consequence, instances with low priority numbers are started earlier than instances with higher priority numbers.

The use of priorities allows you to start (and stop) complete SAP systems as a whole unit without the need to manually take care of a special start (or stop) sequence. The system automatically ensures the correct starting (or stopping) order of the instances.

Priority Definitions

  • Priority 1: Instances with an Enqueue but without ABAP Dispatcher (ASCS)
  • Priority 2: Instances with an Enqueue and with ABAP Dispatcher
  • Priority 3: Instances without an Enqueue (PAS/AAS)

Note

There is no co-existence of an instance with priority 1 and another instance with priority 2 in ABAP environments. It is an "or" relationship based on the technical release.

Hint

SAP provides a further special instance called Enqueue Replication Server (ERS) to achieve high availability on software level for the enqueue server, which is a single point of failure in any SAP system. This instance gets assigned priority0.5.

Hint

Normally only SAP instances get assigned a specific priority. Nevertheless, the SAP HANA database system also gets a start-up priority value during installation, which is 0.3. In this way all SAP HANA based SAP systems, which only run on SAP HANA, can be started using the priorities' mechanism.

The list of priority definitions indicates that the enqueue server (or process) plays a special role for the start (and stop) sequence. Typically the enqueue (server) is part of the ASCS instance, which runs centrally once per ABAP stack. The instance hosting the enqueue also includes the Message Server and must be started before all other instances (in earlier releases, the instance covering these services was called central instance). In comparison to the former central instance, the ASCS does not require a running database, because it does not provide work processes, which require a connection to the database.

In the figure above the mandatory instances and their priority is shown, which is important for the identification of the start sequence of an ABAP based SAP system.

The start process is performed in multiple steps using the operating system user <sid>adm (or SAPService<SID> on Windows):

  • If the SAP system includes an ASCS instance, it will be started first (priority 1). An exception would be the usage of an Enqueue Replication Server (ERS) instance. If installed and configured, the ERS instance gets started before the ASCS instance, simply caused by the higher priority (0.5) and then followed by the ASCS instance.

  • Next, the PAS instance is started together with all Additional Application Server (AAS) instances. The PAS instance and the AAS instances require a running database.

Note

The figure above does not provide information on the distribution of the different core elements of an SAP system to hosts. Nevertheless, for a successful start procedure it is not enough to rely on the assigned priorities, but guarantee that even for distributed SAP environments all elements can be accessed by the tool in use. This will be covered with some further details in another lesson.

Start Process: sapstartsrv as Instance-specific Service

Processes of an SAP instance are started by a program called sapstartsrv that runs once per instance. It is part of the SAP kernel delivered with the installation and provides a wide range of functions to handle different types of SAP instances. In addition, the sapstartsrvdaemon (UNIX/Linux) or service (Windows) gather important information needed by the administrative personnel.

The implementation of the program sapstartsrv is OS-dependent. On UNIX/Linux operating system platforms a daemon is used, whereas on Windows a service is implemented. By default a setting made during installation on all supported platforms ensures that sapstartsrv is automatically started when the host is started up or rebooted.

On UNIX/Linux OS-platforms the start script sapinit is installed and in turn starts sapstartsrv. This can be seen on the following figure:

On Windows platforms a service called SAPService<SAPSID>_<instance_number> is created under a special user SAPService<SAPSID> and starts the executable sapstartsrv. Get details from the following figure:

Hint

Remember that the goal of the OS-specific views is not completeness, but rather to make clear there are differences.

In spite of the different OS implementation, the program sapstartsrv provides the same functions when using (for example) the SOAP interface. Details are discussed in a further lesson.

Start Process: Evaluation of Profiles

SAP systems use profiles for configuration purposes. These profiles are provided by the installation tool and, if required, can be adjusted according to the needs of the customer.

According to the architecture of an ABAP-based SAP system, every installation (<SAPSID>) gets exactly one Default profile for system-wide parametrization. In addition, every SAP system consists of instances and uses Instance profiles, which are used for individual configuration of the instance-specific processes and services. In this way the settings provided in the Default profile can be replaced per instance with individual values or even simply enhanced with new parameters and values.

Thereby every Instance profile includes different types of parameters:

  • Parameters to start programs in order to initialize the instance (for example sapcpe, database, ABAP Dispatcher, IGS)
  • Parameters to configure the instance according to requirements and resources (for example type and amount of work processes, security, main memory, and so on.)

Note

The above mentioned parameters are not visible in blocks 1:1 within the Instance profile. This is only to remind the administrators that such a profile consists of different types of parameters. Parameters to start programs use prefixes like "Start_Program_<number>" or "Execute_<number>".

Hint

Here, for the topic of starting SAP systems, only some parameters to start programs are relevant and described without the corresponding syntax.

Hint

Nevertheless, be aware of the following:

An incorrect parameter or parameter value can also be the root cause for an unsuccessful start of an SAP system or an individual SAP instance failure.

For any further instance, an additional Instance profile will be used and stored within the central Profile directory: under /sapmnt/<SAPSID>/SYS/profile.

  • UNIX/Linux: /usr/sap/<SAPSID>/SYS/profile
  • Windows: \\<SAPGLOBALHOST>\saploc\<SAPSID>\SYS\profile

How does an SAP start procedure for a complete SAP system work?

Assuming that all involved sapstartsrvdaemons on UNIX/Linux or services on Windows are up-and-running, the sapstartsrv with the highest priority takes over control (this is typically the sapstartsrv of the priority 1 ASCS instance - see figure above).

Next, the content of the profiles is read by sapstartsrv. First the global parameters from the Default profile are taken into account, followed by the initialization of the instance. In this phase the start section from the respective Instance profile is evaluated, that is, the instance profile defines the steps to be performed during the start process and the processes of the instance to be started by sapstartsrv.

The start section of the ASCSInstance profile is read:

  • Typically the start section begins with the execution of sapcpe, which replicates, copies, or links directories and programs (details are presented below in this lesson).
  • Because the ASCS instance does not need an up-and-running database, it continues the scan of the start section and will start the Message Server and the Enqueue Server (optionally an RFC Gateway Service and/or an integrated SAP Web Dispatcher is/are started).

The sapstartsrv of the instance with the highest priority has done its work and gives over control to the next priorityLEVEL. In the figure above these are the PAS and AAS instances. Both have the same priority 3.

Every individual sapstartsrv scans the common global Default profile and the specific Instance profile in order to initialize the instance according to the respective start section in the Instance profile. This is done simultaneously, because both instances have the same assigned priorityLEVEL 3:

  • sapcpe will be executed (see above)
  • The database state will be checked and if it is not yet up-and-running, a script or command is executed to start the database (this is only valid, if the database is installed on the same host as the PAS or AAS instances - see discussion at the beginning of this lesson).

    Hint

    In our training environment the available SAP S/4HANA Server installations use explicit hosts for the SAP HANA databases. Therefore we should not expect a starting action for the database triggered from the Instance profile.

    Note

    Every Application Server instance (PAS/AAS) requires a database in operational state when it is started. This is caused by the follow-up procedure of the ABAP Dispatcher. When started itself, it initializes in turn the configured types and amounts of work processes, which immediately try to connect to the database.
  • The ABAP Dispatcher will be started and performs follow-up actions like starting the work processes.
  • The Internet Graphics Service (IGS) watchdog will be started. It can be used to generate graphical or non-graphical output for data from an SAP system or another source.

Caution

Normally, you should not change the entries for the start process in the instance profile. However, if these start entries are changed, the sapstartsrv has to be restarted so that the changes made will take effect for the next system restart.

Start Process: sapcpe for Kernel Replication

The program sapcpe (central patch environment) is used to ensure the consistency of kernel binaries and libraries across the entire SAP system by implementing a verification and copy procedure during the start process of the ABAP-based SAP system.

The mechanism is pre-configured by the installation routine and initialized before startup of an SAP system in order to update or exchange content of the instance-specific SAP kernel directories. This is done by replicating the content of the global kernel directory /exe/<codepage>/<platform> to the local exe directory underneath the respective instance-specific directory <instance_name><no> with the help of program sapcpe.

In this way every instance will make use of the same program versions after a successful start of an SAP system.

The program sapcpe can be used in the context of different strategic approaches, depending on the source and target content to be verified. It is also able to work with compressed programs or executables and make use of a configuration file (sapcpeft), which includes direct instructions on how to proceed and what should be done.

Finally there are also parameters for a command line call to determine source and target directories, as well as files and directories to be copied. For more information about the program sapcpe use the following link: https://help.sap.com/docs/ABAP_PLATFORM/85f9aa682547440b80d72492fea86a42/48f5f300af4c3a63e10000000a421138.html?q=sapcpe

Stop Process of the SAP System

The stopping of an SAP system is performed in the reverse order of the starting process according to the instance priority. Because there is a wide range of different technical ABAP-based releases used in the market, two main scenarios have to be differentiated:

SAP ABAP system with an ASCS instance

This setup reflects a typical up-to-date ABAP-based SAP system including an ASCS instance. All Application Server (AS) instances (PAS and AAS) are stopped first. Next the ASCS instance will be shut down (and finally the ERS instance, if installed and configured).

SAP ABAP system without an ASCS instance
ABAP-based SAP system installations of earlier technical releases were installed without an ASCS instance and might still not include it. As a consequence the central services (message service and enqueue process) are not part of an explicit ABAP Central Services instance, but provided by the first installed Application Server (AS) instance, the "central instance", which has priorityLEVEL 2. In case there is a scaling of AS instances, any further "dialog instance" gets priorityLEVEL 3. Accordingly the stop procedure first takes into account the "dialog instance/s" (priorityLEVEL 3) and then the central instance (priorityLEVEL 2).

Note

Conclusion:
  • The stop procedure is dependent on the architecture and the technical release
  • SAP instances with an enqueue server or enqueue process are always stopped last
  • If the database is stopped, it will be typically shut down after the SAP instances

Tasks Before Stopping an ABAP-based SAP System

You may need to stop an SAP system for a variety of reasons, such as to restart after permanently changing profile parameters, before installing kernel patches, or to allow hardware upgrades to be carried out.

Before you stop the system, you should check the system status. This includes checks such as:

  • Active users:

    Call the User Sessions for AS Instance <hostname>_<SAPSID>_<instance_number> overview via transaction SM04 and go to System-Wide List to determine, which users sessions are active in the system.

  • Background processing:

    Check which jobs are active with the job overview (transaction SM37 or SM37DISP). If jobs are terminated by restarting the system, you must re-schedule them. Jobs that are scheduled to run during the time when the system is stopped, run automatically when the system is restarted.

  • Batch Input:

    The Batch Input: Session Overview (transaction SM35) displays running batch input jobs (covered in figure above as background processing).

  • Update:

    Use the Update Requests: initial Screen (transaction SM13), ensure the filters are fitting and choose Execute to check, whether update processes are terminated by the system stop. These update records are rolled back during the system stop process and are set to status init and re-processed again during the restart.

Before you stop your system, you should inform users early enough (if possible) about the upcoming downtime with a system message (transaction SM02).

Note

Normally a system or an instance cannot simply be stopped, there are still organizational framework conditions to consider. For example, the system downtime must be planned with the respective departments and the downtime must be logged. You can use SAP Solution Manager to plan the system downtime. The SAP Solution Manager Launchpad contains an SAP Fiori Group called Technical Administration that includes SAP Fiori App"IT Calendar and Work Modes". There you can plan IT and business events for technical systems, instances, databases, hosts and external services, and schedule work modes, such as maintenance or planned downtime.

Hint

To display a system message on the SAP Fiori Launchpad page, you can implement a plug-in or extend the shell header. For more information, see SAP Knowledge Base Article2475155 - Flash message into the SAP Fiori Launchpad.

Announce a System Shutdown and Perform Some Checks

Prerequisites

Business Example

As an SAP system administrator, you have to restart an SAP system to activate some parameter changes made. As a precaution, users have to be informed about the upcoming event. In addition some checks should be done beforehand.

Note

In this exercise, when an object name or value contains ##, replace ## by the number your trainer assigned to you.

Steps

  1. Before you stop the SAP system, check which users are logged on to your SAP system.

    1. In your SAP system, start the transaction SM04.

    2. Choose System-Wide List or navigate from the menu to Goto → System-Wide List to display the users logged on to your SAP system.

      Hint

      The transaction uses RFC connections to collect user information for all instances. Your user initiates an RFC connection to each instance. This is why your own user is displayed more than once in the context of transaction SM04.

  2. Send a system message announcing that the complete system is going to be stopped.

    1. Start transaction SM02 to send a system message to the users logged on to your SAP system.

    2. Choose Create.

    3. Enter a meaningful system message text.

    4. Specify until when the system message should be displayed and deleted. You can keep the default values.

      Hint

      In case the SAP system would be scaled with PAS and AAS instances, the field Server provides an option for selection and only those users logged-on there are informed about the planned stop.

      This is not valid here in this exercise, because you will stop the complete SAP system!

    5. Choose Save.

      Result

      You successfully created a system message. It will now be displayed for every user who is logged on to the SAP system at the next dialog step, also if new logons are done.

  3. Check whether there are jobs in status active or scheduled.

    1. Start transaction SM37 or SM37DISP.

    2. In the fields Job Name and User Name enter * as a wild-card.

    3. In the section Job Status flag the values Sched., Ready, and Active.

    4. Deselect all other entries in section Job Status (Released, Finished, and Canceled).

    5. In section Job Start Condition ensure the current date is entered in the fields From: and To:.

    6. In the same section choose in field Or after event the value *.

    7. Verify in section Job Step that the field ABAP Program Name is empty.

    8. Choose Execute (F8).

    9. In case the message No job matches the selection criteria View details appears in the status bar (or as a dialog box), no currently running jobs will be aborted when stopping the SAP system.

    Hint

    The selection in transaction SM37 and SM37DISP shows the current situation according to the statuses chosen on the initial screen. There might be a different result seconds or minutes later caused by released jobs. As a consequence execute the check right before stopping the SAP system or PAS/AAS instance(s).

  4. Verify, whether there are terminated updates in the SAP system.

    1. Start transaction SM13.

    2. On the Update Requests: Initial Screen verify the fields Client: and User: are filled with the value *.

    3. In section Status select All or Canceled.

    4. In the Selection area choose in fields From date: and From time: at least a day and time when you last monitored failed updates (normally the current day is chosen and From time:/To time:00:00:00 preselected).

    5. Choose Execute (F8) to check for updates in status Canceled.

    6. On the screen Update Requests check for canceled updates in status Error. If there are no errors, the shutdown can be done without further interaction.

    7. Return to the initial screen of transaction SM13 by using function key F3 or choosing Back.

      Result

      Users were informed about an upcoming shutdown of an SAP system and you have checked some important areas before executing this task.

    Hint

    If there are terminated updates, identify the user or area and initialize a work-flow to get in communication with the respective person/department in order to clarify, whether a re-processing should be done before stopping the SAP system or PAS/AAS instance(s).

    Hint

    Also check for currently executed updates. These would be rolled-back when stopping the SAP system (depending on the shutdown option). Therefore prefer value All in section Status when searching for terminated updates before stopping the SAP system or PAS/AAS instance(s).

    Note

    In most scenarios cross-system business processes are implemented, which involve incoming and/or outgoing data transfer on a regular basis (permanently or temporarily). In such a complex use case, further checks have to done before stopping the SAP system or PAS/AAS instance(s) and often the use of the RFC gateway (via transaction SMGW) and external interfaces have to be taken into account.

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn