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