Understanding the Concept of Start and Stop Procedures

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).

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.

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.

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.

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.

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.

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.

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.

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.

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:

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.

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.)

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.

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

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).

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).