Interrelation: SAP work process, OPS$ mechanism, o...

Technology Blogs by Members

Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!

21,567

SAP Managed Tags:
Oracle Database

Some time it will be useful to know the which SAP work process is having which corresponding Oracle shadow work process and Check them out at OS level.

Lets briefly discuss The OPS$ Mechanism under UNIX

For the Oracle database, the SAP System is a single user, SAPSR3 or <SAP Schema User> (whatever name given to schema User). Its password is stored in the table SAPUSER. Therefore, to access the database, the SAP System uses a mechanism called the OPS$ mechanism, the ops$<user> in Oracle is a database user identified 'externally'. This means that the database does not have a password for the user but allows them to login directly from a shell prompt with 'sqlplus /'. Security is limited to the UNIX login and password. The string 'OPS$' is configurable in the Oracle init file, OPS$ being the default.

Let’s consider the SAP work process connection to Oracle database:

The work process initiates connection using operating system (OS) authentication via its corresponding OPS$ User. It first logs on to the database as the user OPS$<operating_system_user>, for example, OPS$<SAPSID>adm.
On successful connection, the work process checks the SAPUSER table for the password of <SAP Schema User>. The password of <SAP Schema User> is stored in default oracle password table as well as SAPUSER table. Basically one should not edit the password of this user using Oracle methods or tools. The recommended method is via SAP’s BRCONNCET tool. Because when you change the <SAP Schema User> password via Oracle, the password will not be changed in the SAPUSER table which is the reference repository for the user’s password when the connection process is initiated.
After retrieving the password from the SAPUSER table, the work process disconnects from Oracle.
The work process then connects with the username <SAP Schema User> using the password retrieved from the SAPUSER table. Now this <SAP Schema User> has exhaustive authorization on DB.

OK, lets proceed for Oracle shadow process identification:

Oracle clients are programs using the oracle database, they will not directly access the database files. They will initiate their database connection connecting to the ORACLE-Listener using TCP/IP communication. The listener will assign a so called Shadow process which then will connect to the Oracle Client program. Every database access of the Oracle Client is done through the shadow process.

There are alternative communication methods (shared memory, pipe), SAP default is TCP/IP.

There are alternative server configurations

Shared server - several Oracle Clients will share one Oracle shadow process
Dedicated server - each Oracle Client has it's own shadow process

SAP default is dedicated server.

On Windows we have a little different architecture: The shadow process is implemented in form of a shadow thread in the Oracle Service process.

In terms of SAP standard configuration, each work process, r3trans, tp, br*.exe have their own shadow process / thread.

Shadow processes are client processes managed by the Oracle database. They exist not just for SAP dialog work processes but for all work processes running on all application servers.

To view shadow process information from SAP, use ST04 & SM50.

ST04 -> Performance -> Additional Functions -> Display GV$-Views -> GV$SESSION

There you can find all oracle shadow process.

Watch out for field names like "Schema User name", "OS UID", "OS Process ID", "servername", "Operating system program name" & "Client ID"

Field "OS Process ID" can be mapped against SM50 screen "PID" these can be view at OS level as well by the corresponding processes ID.
Field "Client ID" will tell the SAP User ID, if particular work process is catering SAP work process.

Now if you want to relate SAP work process and corresponding oracle shadow process goto

ST04 -> Performance -> Wait Event Analysis -> Session Monitor

Field "Op. sys. PID" tells the oracle shadow process ID at OS level

Field "SID" from this screen can be mapped with field "Session ID" of GV$SESSION screen previously discussed.

In this way oracle shadow process and corresponding SAP work process can be mapped with help of these two separate screens of ST04 and SM50.

Hope this will be of help to some of us.