Start and Stop Process: Microsoft Windows

Start Processing

...

1. Starting the SAP services

When the Microsoft Windows system is booted, the SAP service ( SAP_, such as SAPC11_00) is always automatically started. The service evaluates entries from the Microsoft Windows start profile, copies the adm user environment to the registry, and reads the required environment variables from the registry.

2. Starting the SAP Processes

You can start the SAP processes using the Microsoft Management Console (MMC). To do this, select an instance and choose Start in the context menu. For more information, see Microsoft Management Console: Windows.

DCOM communication is set up with the SAP service and messages for starting the appropriate SAP instance are sent to the service. The SAP service interprets the Microsoft Windows start profile (see Evaluating the Start Profile below) and starts the processes of which the instance consists. (The processes are started by the program sapstartsrv.exe.)

The message to start the desired instance can also be issued using the command line program sapstart.exe.

The following diagram illustrates the interaction of the individual processes during the start process:

Evaluating the Start Profile

When you start an instance, the SAP service executes all commands in the Microsoft Windows start profile that contain an Execute_ statement. The SAP service then starts the processes of the SAP instance in the order in which the Start_Program_ statements are listed in the profile.

Shutdown Processing

You are stopping the SAP system with the MMC or another utility program. The SAP service waits for a stop message from the MMC or from a command line program (such as sapsrvkill) and then stops the SAP system. The service itself is not stopped.

The database is not stopped with this shutdown process.

What to do After Installing an SAP Instance

Use

Once you have set up a new instance with the SAP installation program R3INST , you can decide whether you want to keep the associated instance profiles or delete them. You can either:

• Keep the profiles to represent one or more instances.

To use the profiles generated or modified by R3INST (start, default and instance profile), they should be imported directly into the SAP profile maintenance database.

• Remove the profiles.

There are already other profiles in the system that support or are shared by more than one instance. To use the existing start and instance profiles instead of the profile files generated by R3INST , identify and delete the files generated by R3INST in the global profile directory.

Once the profiles have been removed, the startup/shutdown scripts of the new instance must be modified to enable instance startup/shutdown from operating system level. The scripts to modify are called startsap or stopsap .

Procedure

To modify startsap or stopsap :

1. Fill the variable
START_PROFILE (in the scripts startsap and stopsap) with the name of the start profile you require. These two scripts are located in the home directory of the SAP administrator (for example, c11adm).
2. Use
for a new Release 3.0 installation of the start and instance profiles. An upgrade from Release 2.2x must be performed without .
3. In the start profile file, you may have to adapt the name of the instance profile used to start the SAP instance programs. To do this, use the CCMS profile maintenance tool.

Starting the SAP Instance

1. Verify that the SAP instance is down.
2. Log on to the appropriate server as adm.
3. Make sure that MS SQL Server is up and running by checking the service in a Services window.
4. Open the SAP MMC Management Console.
5. Browse the navigation tree of the left by expanding SAP Systems à à . Right-click on the instance name and click Start.
6. Click on the Syslog entry to view the system log – refresh until you see a message “SAP-Basis System: Initialization complete”.
7. Close SAP MMC Management Console and log off server.

Non-SAP MMC Console Dependent Method

1. Verify that the SAP instance is down.
2. Log on to the appropriate server as adm.
3. Make sure that MS SQL Server is up and running by checking the service in a Services window.
4. Open a DOS-prompt window.
5. Type in the following, pressing ENTER after you are done:

startsap name= nr=00 SAPDIAHOST= pf=D:\usr\sap\\SYS\profile\_DVEBMGS00_

6. Close DOS-prompt window and log off server.

How do I limit what my users can do when they log on to a SAP instance?

SAP user security is done via roles. A role is basically a group of transactions, authorizations, and authorization objects bundled together for use by a group of users with common functional needs. This group definition is saved and generates a profile which is attached to the SAP user who needs it.

People often get intimidated by SAP security – there are thousands of transactions, authorizations, and objects. It helps to think of all this is simplistic terms.

Let’s say you have a user who needs access to one transaction in the SAP instance. All he needs to do it log on, go to transaction SPAD, and print a list of available printers. That is his whole job, to create this printer list once a day. So he needs the authorizations that allow him to log on to SAP, to go to the SPAD transaction, and to print the list to any available printer. He has * to all printers. He basically needs a role containing the transaction he is allowed to do, SPAD, and the authorization object S_SPO_DEV set to all because he can see and print to any printer.

Then let’s says a new check printer gets added to SAP, and we don’t want the user to be able to print his printer list to the new check printer. So we change authorization object S_SPO_DEV to a list containing authorizations for the printers to which he can print, excluding the check printer. His dropdown list for printers won’t even show the new printer now. And he will be able to print to any printer in his printer authorizations list.

This is a simplistic example but you can see how it works. SAP security can be very tight or very loose. In general, it is loose in DEV, using a modification of the SAP_ALL profile – sort of God-like powers and what the Basis people normally use since it already exists and why make a role that does the very same thing? - to allow every DEV user to do everything with the exception of Basis tasks. QAS may be a little tighter, or a combination, allowing the user SAP_ALL during training but limiting the user to his/her PRD role in another client on the last day so he can test the role he will really use out. In PRD, of course, users should only receive the rights to only what they absolutely need to do.

What is a SAP Instance?

A SAP instance is all the components created by the SAPinst program who all share the same database. There are three mandatory sub-instances; the Database Instance (DB), the Central Instance (CI), and the Dialog Instance (DI) aka Application Server. This is the minimum configuration of any SAP instance. There can be multiple DIs but only one DB and only one Active CI which means that a copy of the CI can exist for High Availability but only one of the CIs can be active at any given time. You will hear about SAP being multi-tiered and that term is referancing these three layers. Sometimes you might see “other SAP tiers” like ITS but that really isn’t a separate tier, it used to be an additional piece of software working with IIS, and now ITS is part of Basis/WAS so it is part of the CI Tier. These layers, plus other SAP written software, are also known as the SAP Business Framework.

You can probably guess at what the DB contains. There are any number of tables in a SAP instance, from 21,000 to 38,000. Many have four or five character names that are usually abbreviations of things like USR for user, MANDT for client, etc. You could guess that USR is short for user. But MANDT? So, we add one more variable to the equation – those four or five character names are abbreviations of German words. Needless to say, trying to look at SAP from a typical DBA prospective is almost impossible. Fortunately, SAP supplies the tools for you to manage all these tables.

The Central Instance is a lump term for all the SAP executables, the installed OS file structure, and anything that is placed on the OS to support and communicate with the SAP instance. It “talks” to the database, handles requests made by the application server(s), and sends back the information. Other software products often call this the middleware layer.

The Dialog Instance connects the users to the CI, passes the issued requests to the CI, and sends the returned results to the user’s session. SAP uses a client piece called SAPGui which handles the user-to-DI communication on the user’s workstation.

These are the three main pieces of a SAP instance installation. There are other parts that can be added for various sub-access and external tasks. For a Development SAP instance or a Quality & Assurance or Test SAP instance, all three layers are normally installed on the same server. For a Production SAP instance, the DB/CI are often installed on one server and the DI on another server for load balancing purposes. It should be noted that the installation of a CI instance automatically installs a DI which can be used by everyone if needed, be used only as needed by Basis staff, or never be used.

Instance can be a difficult term to understand – almost every major database applies this term to the installation of the database software. So if you see reference to an Oracle instance, this means the installation of the Oracle software. An Oracle database is the creation of a new empty database within that Oracle instance.

Understanding the Startup and Shutdown prodedures may help solidify this layer concept.

The normal SAP instance start up consists of three parts: starting the SAP OS Collector, starting the Oracle Listener, and starting the SAP instance. The process mainly goes like this: ora logs on and starts the Oracle Listener then adm logs on and runs the startsap script.

What? You say we missed a step? What happened to the SAP OS Collector?

The startsap script takes care of the SAP OS Collector for us. When the SAP Instance starts up via the startsap script, it checks to see if saposcol is up and running – whether from the root user starting it manually or from another SAP Instance already starting it up, it doesn’t matter. If saposcol is up and running, the script simply moves on to the next step. If it is not, the script starts saposcol as root and then proceeds. So the SAP OS Collector gets handled one way or another.

However, you may need to bring up multiple Oracle Listeners depending on the database configuration. If the MCOD installation option was used then only one Oracle Listener is used since both databases share one Oracle listening port which is normally 1527. If, however, two Oracle instances were installed, and each database uses its own unique Oracle listening port, then multiple listeners must be started. The startup procedure for each SAP Instance would be exactly the same as if only one SAP Instance resided on the server.

The process to stop the SAP instance is close to being the reverse of the start procedure. adm stops the SAP Instance, ora stops the Oracle Listener, and root stops the SAP OS Collector. The only real difference is that saposcol is not automatically stopped by the stopsap script – there may be other SAP instances on the server which means this software needs to stay up and running to gather OS information until that instance comes down.

One thing to note – the Oracle Listener does not start the database, it simply “watches” port 1527 for any database related activity. The startsap and stopsap scripts handling the startup, mount, opening, and shutdown of the database. None of this activity could occur if the listener was not “polling” port 1527, relaying the requested database function, and returning the results through the same port.

The adm and ora users are assigned environment variables using the SAP installation run that identify them as users of a specific Oracle database and SAP instance. So when oraabc starts the lsnrctl program with the “lsnrctl start” command, oraabc’s environment variables tell the server which database for which the listener is to “listen”.