The collector SAP OS system (saposcol) is an independent stand-alone program from the platform that runs in the background and OS collects information system using a shared memory segment for various applications and all SAP instances on one host. These details information can be displayed via the transaction code ST06 / OS06 in SAPGUI frontend. It is a very useful NetWeaver / Base tool administrators and consultants to monitor server performance. Saposcol extracts the real-time data from the system, even if it does not automatically update, you must click on the 'Refresh' button to get the updated data. Saposcol collects system data every 10 seconds and records, and even records the hourly averages for the last 24 hours. It works independently from SAP instances exactly a process for host and collects data from various operating system resources. The user can monitor all servers in SAP landscape with this tool. But for remote server (liveCache server) the transaction code is OS07. You can monitor CPU usage, physical and virtual memory usage, pool data size / Swap, disk response time, the use of physical disks and file systems, load resource for running processes, and even the LAN data from the monitoring list.
You can access this tool from SAP Menu-> Tools-> CCMS-> Control / Monitoring-> Performance-> Operating System-> Local-> Activities.
If you can not see all data, this means that the operational collection (saposcol) is not running (error code: Shared memory not available). In this situation, your main task is to secure the saposcol to function properly. This usually happens after a new installation or SAP kernel updates. If you are new to the SAP system the following guidance will be useful to overcome the problem saposcol.
Unix / Linux / AIX / Sun / Solaris system:
First, check the permission of the saposcol.exe files, should be 777 (owner is root in sapsys) and sticky bit group must be set to 4750. If you want to know what user is running saposcol, use "ps -ef | grep saposcol". Now edit the file saposcol the owner root, group sapsys, the 4750 mode, log on as root to the UNIX system and execute commands as below,
cd / usr / sap // SYS / exe / run
chown root saposcol
chgrp sapsys saposcol
chmod 4750 saposcol
You can also run the "saproot.sh" in exe directory to set permissions. Then run saposcol -l as the same owner (root). Check the status collector using -s saposcol. After setting the file permissions, you can also use, ST06 -> OS Collector -> Click 'Start' to saposcol running.
To shut down the operating system for collecting user saposcol -k. If this command is not able to kill the process, you can run "99 cleanipc remove" (Check SAP Note 548699). If this attempt fails, then you must remove the key from shared memory saposcol. Run the command "ipcs -but" and annotate shared memory ID in the row that contains the key saposcol. Then run the command "ipcrm ID -m". shared memory key will also be created next time when you run saposcol.
Sometimes using "saposcol -l" gives a message that is already running, but when you grep the process using "ps -ef | grep - I saposcol "may not show the process. In this situation, you can use an undocumented parameter "saposcol -f", where "F" is about to start the process with force. When it begins, then stop the Methon adjustment process using "saposcol -k" and therefore normally start using the "saposcol -l".
If saposcol still does not work, then you need to start in windowed mode. Login with ADM use and follow the instructions below,
saposcol -d
Collector> clean
Collector> quit
saposcol -k to stop the manifold.
Before restarting
saposcol -d
Collector> leave (You should get a shared memory message- deleted)
Collector> quit
cd / usr / sap / tmp
coll mv . put coll.put.sav
CD
saposcol
"Coll.put" if this file contains the old shared memory and should be deleted in order to get a clean start (check SAP Note 548699 , item 7). If you are unable to delete the shared memory, try the following commands to delete the shared memory:
$ saposcol -kc
$ saposcol -f
If that fails too, then you need reboot the system from the operating system level, and also seems to need a new version of saposcol (Check SAP note 19227).
IBM iSeries i5 / OS (OS / 400, OS / 30):
- Check the permissions of the directory '/ usr / SAP / tmp' and the file 'saposcol.exe', it should be 4755 and owner must be root in sapsys group. Check SAP Note 70639. After assigning permissions you can run from the command line of the operating system using 'saposcol -l'. To show the use of state 'saposcol -s' to stop the process and use 'saposcol k'. You can also run the process by submitting a job at the operating system level using
CALL PGM (saposcol) PARM (-l)
It supports the work into work QBATCH queue in the QGPL library.
- In iSeries, you may experience strange data when analyzing the CPU usage using Tcode ST06 / OS06. Even using the most CPU, saposcol could signal only CPU utilization for the first CPU. Also sometimes there are uses of CPU above 100% in some intervals, if you are running as SAP in an uncapped partition where multiple logical partitions are using a pool of shared processors. In this situation, make sure that the CPU usage reported by number CPU 0 is the average use for all of your CPU in the system. If you want to see CPU partition information shared, apply support packages as SAP Note 994025 including the following patch levels
6:40 disp + work package (DW): 182 saposcol: 69
7.00 package disp + work (DW): 109 saposcol: 34
applying these patches and support packages in the system, new transactions, OS06N, ST06N, and OS07N are available to display additional information in two sections entitled "system host "and" Virtual system ". These include the type of partition information and the CPU available and consumed in the current partition in the shared processor pool. So if you are an iSeries user and your saposcol is not running, the highest probability is that you need to put the latest patch the kernel and saposcol. (SAP Note 708136 and 753917)
- Another scenario iSeries, when the saposcol is not running, and you can not start it from ST06 / OS06. Problem may be with the list of authorizations R3ADMAUTL was not accurate. You can solve this way,
1) Remove QSECOFR * ALL X
2) Change from * PUBLIC * USE authority to * EXCLUDE
3) Add R3OWNER * ALL X
now you can start using the saposcol Tcode ST06 / OS06. And also you can start the process from the command line,
CALL PGM (PARM / saposcol ( '- l')
If this does not help check if both QPMLPFRD and QPMWKCOL programs in library QSYS have the authorization assigned to the user manual * R3OWNER (SAP Note 175852). and if you do not execute 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 should check if the user R3OWNER part of the list of authority R3ADMAUTL (SAP Note 637174).? After that if you receive the error saposcol "is not running (shared memory not available), then follow the instructions below,
1) Remove the shared memory (coll.put) as for SAP Note: 18072. 'coll.put' location :. '/ usr / sap / tmp'
2) End the QPMASERV jobs, QPMACLCT, QYPSPFRCOL and CRTPFRDTA in QSYSWRK if running.
3) delete the temporary user space, WRKOBJ OBJ (/ * PERFMISC) OBJTYPE R3400 (* 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) ENDJOB JOB (xxxxxx / QSYS / QYPSPFRCOL) OPTION (* IMMED) 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) ENDJOB JOB (xxxxxx / QSYS / CRTPFRDTA) OPTION (* IMMED) SPLFILE (* 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, opt 2, and opt 1; OR CALL QYPSSTRC PARM ( '* PFR' '* STANDARDP' '') [There are 6 blanks after * PFR and there are 6 blanks making up the second parameter]. Alternatively, start the Collector from Operations Navigator.
12) STRTCPSVR * MGTC
13) Finish and restart Operations Navigator if it is running. See the IBM Authorized Program Analysis Report (APAR) SE12188 for more information.
14) Now we start from saposcol ST06 / OS06.
Windows:
- Go to the folder in the kernel command line where saposcol .exe. Set the full permission owner
for the files and folders. Then run saposcol -l (saposcol -d in windowed mode)
- You can also try the start / stop service saposcol from the Control Panel -> Administrative Tools -> Services (services.msc).
If all other attempts fail, so make sure you have the correct version of saposcol. Get last saposcol from SAP Service Marketplace for the operating system. SAPOSCOL.SAR download the files for the kernel and save it in a directory. Then stop SAP & saposcol. Check for all the locks of the Kernel Library, and do not forget to take the backup library. Then run APYR3FIX and then APYSAP. Check OSS Note 19466.
also saposcol can be stopped due to small amounts of allocation of internal memory. When this gradually filled memory during runtime saposcol, the system writes the data out of the buffer. As a result the following buffer is cleared and saposcol ends in a landfill. Apply the following patches with at least the following patch levels specified:
SAP output 640: saposcol patch level 100 and the patch level DW 293
SAP output 700: saposcol patch level 75 and patch level DW 151
SAP output 701: saposcol patch level 18 and level of patch ILE 53
SAP output 710: patch level 36 and the patch level ILE saposcol 161
SAP output 711: level 12 patch and the patch level ILE saposcol 48
So, it is obvious that if we use different SAP systems on a server with the mixture of incompatible versions of the kernel, saposcol will face crises and will not provide the data for all systems, although the functions of the SAP system will run without any difficulty. This is because we are using the new IBM technology EXT Kernel, so as not to allow saposcol to reside in single-level storage (SLS), rather than put it in teraspace. In this situation it is obvious that if you are running a system with other non-EXT EXT systems, saposcol will only run on a single system. To overcome this problem, you must update EXT Kernel for all SAP systems with the latest patches. Then set the correct permission for the saposcol files and directories as lead that will solve every problem with the SAP OS Collector.
0 Komentar