The SAP OS Collector – SAPOSCOL in a nutshell

The SAP Operating System Collector (SAPOSCOL) is a platform independent program that runs in the background of the operating system and collects system information using a shared memory segment for multiple applications and all SAP instances on a host. . These information details can be viewed through transaction code ST06 / OS06 in the SAPGUI interface. It is a very useful tool for NetWeaver / Basis administrators and consultants to monitor server performance. SAPOSCOL pulls real-time data from the system, although it is not automatically updated, you must click the ‘Refresh’ button to get the updated data. SAPOSCOL collects data from the system every 10 seconds and records it, and also records the hourly averages for the last 24 hours. It runs autonomously from SAP instances exactly one process per host and collects data from various operating system resources. User can monitor all servers under SAP panorama with this tool. But for the remote server (livecache server) the transaction code is OS07. You can check CPU utilization, virtual and physical memory usage, swap size / pool data, disk response time, utilization of physical disks and file systems, resource load for running processes and even LAN data from the watch list.

You can navigate to this tool from SAP Menu-> Tools-> CCMS-> Control / Monitoring-> Performance-> Operating system-> Local-> Activity.

If you cannot see any data, it means that the OS Collector (SAPOSCOL) is not running (error code: shared memory not available). In this situation, your main task is to fix the saposcol to work properly. This usually happens after a new SAP installation or kernel updates. If you are new to SAP systems, the following guide will be helpful in overcoming the saposcol problem.

Unix / Linux / AIX / Sun / Solaris system:

First, check the permission of the saposcol.exe file, it should be 777 (the owner is root in the sapsys group) and the sticky bit should be set to 4750. If you want to know which user is running saposcol, use “ps -ef | grep saposcol “. Now to change the saposcol file to owner root, group sapsys, mode 4750, please login as root on your Unix system and run the commands as shown below,

cd / usr / sap // SYS / exe / run

chown root saposcol

chgrp sapsys saposcol

chmod 4750 saposcol

You can also run “saproot.sh” in the exe directory to set the permissions. Then run saposcol -l as the same owner (root). Check the status of the collector using saposcol -s. After setting the file permissions, you can also use, ST06 -> OS Collector -> Click ‘Start’ to run SAPOSCOL.

To stop the OS collector, use saposcol -k. If this command failed to kill the process, you can run “cleanipc 99 remove” (see SAP note 548699). If this attempt also fails, you need to remove the shared memory key from saposcol. Run the command “ipcs -ma” and note the shared memory ID on the line containing the saposcol key. Then run the command “ipcrm -m ID”. The shared memory key will be created again the next time you run saposcol.

Sometimes using “saposcol -l” gives a message that it is already running, but when I grep the process using “ps -ef | grep -i saposcol” it may not show the process. In this situation, you can use an undocumented parameter “saposcol -f”, where “f” means to start the process forcefully. When you start, stop the process in the methon regulation using “saposcol -k” and then start it normally using “saposcol -l”.

If saposcol is not running yet, you must start it in dialog mode. Login with use adm and follow the steps below,

saposcol -d

Collector> clean

Collector> exit

saposcol -k to stop the collector.

Before rebooting

saposcol -d

Collector> leave (You should get a message – Shared memory removed)

Collector> exit

cd / usr / sap / tmp

mv coll.put coll.put.sav

CD

saposcol

“coll.put”, if this file contains the old shared memory and needs to be removed for a clean boot (see SAP note 548699, point 7). If you cannot clear shared memory, try the following commands to clear shared memory:

$ saposcol -kc

$ saposcol -f

If this also fails then you have to reboot from OS level and it seems you need a new version of saposcol as well (see SAP note 19227).

IBM iSeries i5 / OS (OS / 400, OS / 390):

– Check the permissions of the directory ‘/ usr / sap / tmp’ and the file ‘saposcol.exe’, it must be 4755 and the owner must be root in the sapsys group. See SAP note 790639. After assigning permissions, you can run from operating system command line using ‘SAPOSCOL -l’. To show the status use ‘SAPOSCOL -s’ and to stop the process use ‘SAPOSCOL -k’. You can also run the process by submitting a job at the operating system level using

CALL PGM (SAPOSCOL) PARM (-l)

Submits the job to the QBATCH job queue in the QGPL library.

– On iSeries, you might experience strange data when analyzing CPU utilization using tcode ST06 / OS06. Even if you are using multiple CPUs, SAPOSCOL may only report the CPU usage for the first CPU. Also, you will sometimes find reported CPU uses above 100% at some intervals, if you are running a SAP instance on an unlimited partition where multiple logical partitions are using a shared processor group. In this situation, make sure that the reported CPU usage for CPU number 0 is the average usage of all CPUs used in the system. If you want to view the shared information of the CPU partition, please apply the support packages as per SAP note 994025, including the following patch levels

6.40 disp + work package (DW): 182 SAPOSCOL: 69

7.00 disp + work package (DW): 109 SAPOSCOL: 34

By applying these patches and support packages to the system, the new transactions, OS06N, ST06N and OS07N are available to view additional information in two sections titled “Host System” and “Virtual System”. These include information about the partition type and the CPU available and consumed on the current partition, as well as on the shared processor group. So if you are an iSeries user and your SAPOSCOL is not running, chances are you need to install the latest kernel and saposcol patch. (SAP Note 708136 and 753917)

– Another scenario in iSeries, when your saposcol is not running and you cannot start it from ST06 / OS06. The problem may be because the R3ADMAUTL authorization list was not accurate. You can solve it this way,

1) Remove QSECOFR * ALL X

2) Change * PUBLIC from * USE to * EXCLUDE

3) Add R3OWNER * ALL X

Now you can start saposcol with the tcode ST06 / OS06. And you can also start the process from the command line,

CALL PGM (/ SAPOSCOL PARM (‘- l’)

If this does not solve the problem, check if both QPMLPFRD and QPMWKCOL programs in QSYS library have * USE- authority assigned for user R3OWNER (SAP Note: 175852). If not, you must run the following commands:

GRTOBJAUT OBJ (QSYS / QPMLPFRD) OBJTYPE (* PGM) USER (R3OWNER) AUT (* USE)

GRTOBJAUT OBJ (QSYS / QPMWKCOL) OBJTYPE (* PGM) USER (R3OWNER) AUT (* USE)

Then you need to check if the R3OWNER user is part of the R3ADMAUTL authority list (SAP Note: 637174). After this, if you get the error “SAPOSCOL is not running? (Shared memory not available), follow the steps below,

1) Remove shared memory (coll.put) per SAP Note: 189072. Location of ‘coll.put’ is: ‘/ usr / sap / tmp’.

2) End the QPMASERV, QPMACLCT, QYPSPFRCOL, and CRTPFRDTA jobs in QSYSWRK if they are running.

3) Delete the temporary user space, WRKOBJ OBJ (R3400 / PERFMISC *) OBJTYPE (* USRSPC)

4) ENDTCPSVR * MGTC

5) CALL QYPSENDC PARM (‘* PFR’ ”) [There are 6 blanks after *PFR and there are 6 blanks making up the second parameter]

6) FINAL JOB (xxxxxx / QSYS / QYPSPFRCOL) OPTION (* IMMEDIATE) SPLFILE (* YES) [This command must be run for all QYPSPFRCOL jobs found on the system even if they show with *OUTQ as their status]

7) FINAL JOB (xxxxxx / QSYS / CRTPFRDTA) OPTION (* IMMEDIATE) SPL FILE (* YES) [This command must be run for all CRTPFRDTA jobs even if they show with *OUTQ as their status]

8) RNMOBJ OBJ (QUSRSYS / QPFRCOLDTA) OBJTYPE (* USRSPC) NEWOBJ (QPFRCOLDTX)

9) RNMOBJ OBJ (QUSRSYS / QPFRCOLDTA) OBJTYPE (* DTAQ) NEWOBJ (QPFRCOLDTX) [This object may or may not exist at this time]

10) CALL QYPSCOLDTA * note This program will create a new * USRSPC. After the collection services starts, there should be a new * DTAQ.

11) Start the collection services using GO PERFORM, choose 2 and choose 1; OR CALL QYPSSTRC PARM (‘* PFR’ ‘* STANDARDP’ ”) [There are 6 blanks after *PFR and there are 6 blanks making up the second parameter]. Now start the collection services from Operations Navigator.

12) STRTCPSVR * MGTC

13) End and restart Operations Navigator if it is running. See IBM Authorized Program Analysis Report (APAR) SE12188 for more information.

14) Now start SAPOSCOL from ST06 / OS06.

Windows system:

– Go to the Kernel folder on the command line where you will find saposcol.exe. Set full owner permission

for file and folder. Then run saposcol -l (saposcol -d in dialog mode)

– You can also try Start / Stop the SAPOSCOL service from Control Panel -> Administrative Tools -> Services (services.msc).

If all other attempts fail, make sure you have the correct version of SAPOSCOL. Get the latest version of SAPOSCOL from SAP Service Marketplace for your operating system. Download the SAPOSCOL.SAR file for your Kernel and save it in a directory. Then STOP SAP & SAPOSCOL. Check for kernel library locks and don’t forget to back up the library. Then run APYR3FIX and then APYSAP. See OSS Note 19466.

SAPOSCOL can also be terminated due to a small amount of internal memory allocation. When this memory gradually fills up during SAPOSCOL runtime, the system writes data out of the buffer. As a result, the next buffer is cleared and SAPOSCOL ends with a dump. Apply the following patches with at least the patch levels specified below:

SAP Release 640: SAPOSCOL patch level 100 and DW patch level 293

SAP version 700: SAPOSCOL patch level 75 and DW patch level 151

SAP Release 701: SAPOSCOL patch level 18 and ILE patch level 53

SAP version 710: SAPOSCOL patch level 36 and ILE patch level 161

SAP version 711: SAPOSCOL patch level 12 and ILE patch level 48

Therefore, it is obvious that if we use different SAP systems on a server with an incompatible mix of Kernel versions, SAPOSCOL will face a crisis and will not provide data for all systems, although the functions of the SAP system will run without any problem. This happens because we are using new IBM technology with EXT Kernels, so it will not allow SAPOSCOL to reside in a single level store (SLS), instead of putting it in Teraspace. In this situation, it is obvious that if you run an EXT system with other than EXT systems, saposcol will run only on one system. To overcome this problem, you must upgrade to EXT Kernel for all SAP systems with the latest patches. Then set the proper authorization for the SAPOSCOL file and directory as indicated, which will resolve any issues related to SAP OS Collector.

Leave a Reply

Your email address will not be published. Required fields are marked *