Monitoring

Monitoring
Page 1 of 29
Monitoring
1 Introduction
This document provides an overview of what needs to be monitored as a part of daily
monitoring. Currently we are monitoring all systems manually.
2 Purpose
The purpose of this document is to provide technical details of what needs to be monitored for
all the transaction and the action to be taken in case of abnormalities.
3 Best Practices for SAP System Monitoring

SAP Suggests us to monitor the SAP systems as periodically and certain crucial checks should
be performed as described below:
3.1 Basis Monitoring: General System Checks:

Frequency
T code
Meaning
Production
Non Production
Database checks
DB12
Completion of backups and archives and sufficient

archive space
once daily
once daily
DB13
All scheduled jobs running successfully and

actioning any issues such as checks indicating no
backup/archive, space issues, index rebuilds etc.
once daily
once daily
Space critical objects, missing indexes, blown

tabelspaces / free space stats & next extents, table
space history
once daily
once daily
DB buffer quality, exclusive lock waits and the DB

log, Standby server actions are completing
once daily
once daily
DB02
ST04
R/3 Checks
SM21
Investigate new errors as well as resolved issues

disappearing
once daily
once daily
ST22
Investigate short dumps that could have an effect on

the running of the system
once daily
once daily
SM12
Old lock entries
once daily
once daily
Page 2 of 29
Monitoring
SM13
Update being active and any failed updates
once daily
once daily
SM51
Application server status
once daily
once daily
SM50
Work Process Monitor
once daily
once daily
SM66
Work Process Monitor
once daily
once daily
SM37
completed background jobs as well as what is still

active and what has cancelled
once daily
once daily
SP01
Printing is completing and not in error
once daily
once daily
ST03
Workload Monitor
once daily
once daily
ST02
Buffer Statistics
once daily
once daily
SMICM
Check log of ensure ICM is running without errors
once daily
once daily
Table 3.1.a : Basis Monitoring: General System Checks
4 Manual Monitoring
As a daily task we perform manual monitoring of all the production system. We monitor only few
critical transactions in all the production systems and a excel report is shared with the client.
SAP Systems are being monitored once in each of the three shifts and as the person starts the
shift his first task to check by logging onto the SAP systems and make sure that all systems are
up and running. All the production systems should be monitored every 4 hours and the system
status should be sent to the whole team.
4.1 Generic System Monitoring for All Usage Types

As a part of daily monitoring we would be monitoring the following transaction in all SAP
Systems:
(During monitoring if some issues are found, please raise a ticket for the same and follow this
ticket till closure. If the issue is related to BASIS, please ask the shift lead to take appropriate
actions ASAP. Any pending issues should be a part of the shift hand-over document)
1. SM21 Check the SAP System Logs
2. SP01 Check the spool requests in error
3. SM51 Check all the application servers
4. ST22 Check the ABAP Dumps
5. SM13 Check the update records
6. SM12 Check the lock entries
7. SM37 Check the background jobs
8. SOST Check the outbound Faxes and emails
9. DB02 Check the database growth
10. ST04 Check database alerts
Page 3 of 29
Monitoring
11. DB12 Check the Archive log directory

12. DB16 Evaluate the results of DB System check
13. DB13 Database Calendar
14. ST02 Check SAP Buffers
15. SCC4 Check the SAP Client settings
16. SMQ1 Check the outbound queues
17. SMQ2 Check the inbound queues
18. SE06 Check the system settings
19. SICK Check initial consistency check
20. SP12 TemSe Check
21. SM58 Check transactional RFC
22. SMLG SAP Logon groups
23. BDF UNIX Command to check any critical file system
24. Check the Database backup report
25. DB01 Check exclusive DB locks
4.2 Monitoring through the BASIS Work Bench lite Tool

The Basis Workbench lite is a tool enabling automation of SAP Basis monitoring. It handles
tasks which are error exhaustive and labor intensive in nature. An executable has to be
deployed / installed on the client machines and this tool can be used using individual Basis
Id.
We should capture the monitoring data using the BWB tool for all the transactions listed in
Section 4.1. For transactions which are not available through BWB tool, we should capture
the data by logging onto the SAP systems. Once the data is captured it should be analyzed
as per the section 7.
BWB lite Features:
Multiple SAP Systems can be monitored on a single click.
One time activity for entering login Credentials
Output is presented in the form of monitoring worksheet:
Example excel sheet is attached:
5 Monthly Monitoring
a) As a part of monthly monitoring we should look into each server to make sure there are
no unwanted files in the file system and which can be cleaned. This can be installation
files, old kernel backup files, old trace / log files etc.
Page 4 of 29
Monitoring
b) We should also clean up the transport logs older than 6 months to free the space in the
trans directory.
c) Older Logs in the work directory should be cleaned up.
d) Please check and make sure that all the SAP housekeeping jobs are running and
performing the cleanup as desired. In case of any issues the housekeeping jobs must be
fixed. Following tables gives overview of all the housekeeping jobs. For more information
about the housekeeping jobs please read SAP Note 16083
Job name
Program
Variant
Freq
SAP_REORG_JOBS
RSBTCDEL
Yes
daily
SAP_REORG_SPOOL
RSPO0041/1041
Yes
daily
SAP_REORG_BATCHINPUT
RSBDCREO
Yes
daily
SAP_REORG_ABAPDUMPS
RSSNAPDL
Yes
daily
SAP_REORG_JOBSTATISTIC
RSBPSTDE
Yes
monthly
SAP_COLLECTOR_FOR_JOBSTATISTIC
RSBPCOLL
No
daily
SAP_COLLECTOR_FOR_PERFMONITOR
RSCOLL00
No
hourly
SAP_COLLECTOR_FOR_NONE_R3_STAT
RSN3_STAT_
COLLECTOR
No
hourly
SAP_REORG_PRIPARAMS
RSBTCPRIDEL
No
monthly
SAP_REORG_XMILOG
RSXMILOGREORG
Yes
weekly
SAP_CCMS_MONI_BATCH_DP
RSAL_BATCH_
TOOL_DISPATCHING
No
hourly
RSPO1043
RSPO1043
Yes
daily
RSTS0024
RSTS0024
Yes
daily
e) In the transaction SPAM check that the maintenance license is not expired. If the
maintenance license is expired please request a new license from market place and add
it to the SAP system from transaction SLICENSE.
Requesting license from Marketplace
Goto http://service.sap.com/licensekeys Keys and requests and then click on search an
installation and follow the screens. You will receive the license key on your email id.
Page 5 of 29
Monitoring
Apply license in SAP: Go to transaction SLICENSE -- EDIT -- Install License
f)
Check the SCC4 and SE06 settings as described in sections 7.15 and 7.18.
g) Check that the load balancing is working in SMLG as per the sections 7.22.
5.1. System Administration tasks

All system administration checks should be carried out in each SAP system. The following sections
outline the areas to be checked. Further information on individual checks can be found in the System
Administration Assistant (transactions SSAA).
5.1.1. Daily tasks

1. SAP: CCMS System Monitoring - General Monitoring Functions (RZ03 / RZ20).
Review SAP Alert Monitor, check for any alerts in the system. Report any errors.
2. SAP: Checking the System Log (SM21).
Review the system log entries, report any errors.
3. SAP: Output Devices in the SAP Spool System (SPAD).
Page 6 of 29
Monitoring
Check for any errors

4. SAP: Checking Spool Output Requests for Errors (SP01).
Check the for any errors in the spool output requests
5. SAP: Checking Work Process Status (SM51).
Check if any work process has been restarted after an error or has gone In priv
any errors.
mode, report
6. SAP: Checking for ABAP Short Dumps (ST22).

Review ABAP Dump data
7. SAP: Checking for Update Errors (SM13).
Check for Failed Updates All failed updates must be investigated by the appropriate
functional analyst for problem determination and resolution Check update status, report
deactivated update status.
8. SAP: Checking Lock Entries (SM12).
Reviews lock entries being held for lengthy periods

9. SAP: Checking Background Jobs (SM37)
Check for Cancelled or failed background jobs.
10. SAP: Checking Production client is locked (SCC4 / SE06)
Check whether the production client is locked or not.
11. ORACLE: Backing Up and Checking the Database (DB24).
Check Backup and the database
12. ORACLE: Backing Up and Checking Offline Redo Log Files (DB13).
Check for any inconsistencies.
13. ORACLE: Monitoring Database Growth (DB02).
Check Database Table space Levels
14. ORACLE: Checking Database Performance-Snapshot(ST04).
Check for buffer quality and high water marks. Review Dynamic Statement Cache for inefficient
and costly SQL
15. ORACLE: Monitoring the Archive Log Directory (DB12 / DB24).
Report any inconsistencies found
16. ORACLE: Evaluating Results of the DB System Check (DB16 / DB24).
17. ORACLE: Checking and Creating CBO Statistics (DB24/DB13)
18. AIX: Evaluating the Error Report (ST06).
Review the report and inform any serious error.
19. AIX: Operating System Monitor (ST06)
Page 7 of 29
Monitoring
Check for CPU utilizations, paging of the system, check the processes running, Report any
processes = 0 or any high CPU or memory Figures, check the OS collector make sure the current
state is active.
20. AIX: Monitoring File Systems (ST06).
Check the SAP and Oracle directories in particular
5.1.2. Weekly tasks

On a weekly basis, the following tasks have to be performed in all 1SAP Systems
1. SAP: TEMSE Check (SP12).
2. SAP: Spool consistency checks (SPAD).
3. ORACLE: Searching for Missing Indexes (DB02 / DB24).
4. ORACLE: Database Verification - Checking Physical Structure(OS Level)
5. Check the EWA Reports(In Solution manager system tcode-DSWP)
5.1.3. Monthly tasks

On a monthly basis, the following tasks have to be performed in all 1SAP Systems
1. SAP: Changing Administrator Passwords
2. ORACLE: Analysing the Entire Database
3. ORACLE: Changing the Database Administrator Password
In addition we can check the queued and transactional rfc connections using transactions SM58,
SMQ1 and SMQ2, report any inconsistencies.
Also we need to check the trace files and log files (dev_w*, brarchive* etc.) for any in consistencies in
work processes or database.
5.1.4. Adhoc Tasks

The following tasks can be performed on an Adhoc/occasional basis
1.
SAP: Checking the Transport Management System (STMS)
2.
SAP: Deleting Old User Master Records (SU01)
3.
SAP: Checking User Activities (SM04)
4.
SAP: Job Scheduling (SM36)
In SAP Support Portal, subscribe to the following SAP Notes to be advised when they
change;
SAP Note 146289 - Parameter Recommendations for 64-Bit SAP Kernel
SAP Note 830576 - Parameter recommendations for Oracle 10g
Page 8 of 29
Monitoring
SAP Note 723909 - Java VM settings for J2EE 6.40/7.0
5.1.5. Template for Daily Monitoring and Health check

6 Half Yearly / Yearly Monitoring
As a part of half yearly and yearly monitoring we should ensure the following:
Overall System space is OK. Make sure that none of the file systems are more than 90%
utilized.
Memory / performance Bottle-necks should be checked. Make sure that the CPU
utilization is always below 90% on all the application servers. If the CPU utilization is
constantly seen to be over 90% (as seen from ST06) we need to analyze and find out
which process is using the most of CPU and take appropriate actions to resolve this. You
may be required to contact SAP / hardware vendor as applicable. In some cases you
may also be required to contact OS support team.
Similarly please check that the free physical memory is not below 10% as seen from
ST06. If such is the case please inform the BASIS team.
Ensure that the DB has good tuning and is performing well. All the alerts as reported
from ST04 and DB16 are resolved.
Prepare for audit of all systems to make sure that all systems in the landscape are at
same SPS / Kernel level.
Identify list of critical fragmented tables, from YEND perspective, and plan reorg and/or
index re-build 2 weeks prior to the YEND.
7 Technical Monitoring Steps

This section describes all in a detailed manner, what needs to be monitored in each transaction
and the action to be taken in case of any abnormalities.
7.1 SM21 - Checking System Log

SM21 displays all the logs in the SAP system for all the application servers.
Page 9 of 29
Monitoring
Diagram 7,1.a : SM21 System Logs

Frequency: This should monitored once in each shift
Check: Please check the system log for all the servers and look for any critical issues. Critical
issues could be related to work process reconnect errors, DB errors, Errors in the enqueue /
locking mechanism etc.
Action Taken: For any potential errors monitoring team should inform the BASIS Shift lead
about it and create a ticket.
BASIS Shift lead should work to resolve the error. In case the error resolution requires some coordination with other teams like DB team or functional team, please create a ticket for them.
RAG Status: We should report the following status based on the errors we see. This should be
reported into the email sent to the team.
Page 10 of 29
Monitoring
Green No Errors or warnings reported

Yellow There are warnings reported
Red Critical errors are reported
7.2 SP01 - Checking Spool Output Request

SP01 shows the spool requests which are created in the SAP system. It is also used to analyze
any errors in the SAP spool system.
Diagram 7,2.a : SP01 Spool

Check: Please check the total number of spools in the SAP system. Also please check if there
are many spools in error status.
Action Taken: If there are many spool requests in the SAP system and if this is abnormal,
monitoring team should intimate the BASIS shift lead about it and create a ticket.
Basis shift lead should find out if the SAP housekeeping job which deletes all the old spool
requests after a certain period, is finishing successfully. This job should be scheduled to run
daily.
If there are many spool requests in error status, monitoring team should intimate the BASIS shift
lead about it.
Basis shift lead should look into the error logs and fix them.
RAG Status: We should report the following status based on the errors we see.
Green No Errors reported
Yellow Not more than 10 spool requests are in error status since it may not be affecting all
printers in the system.
Page 11 of 29
Monitoring
Red More than 10 spool requests are in error status or spool request number is very high
which means that there is some serious issue with the spool system.
7.3 SM51 Check the SAP application Servers

SM51 transaction lists all the application servers which are installed and which are active and
running.
Check: Check if all the application servers are up and running fine. Also check that the work
processes configured for the servers are not in error status. Also check that there are free work
processes in the application servers so that the servers are not heavily loaded.
Diagram 7,3.a : SM51 SAP Application Servers
Diagram 7,3.b : SM50 SAP Work processes

Action Taken: If any of the application servers are found down or if the applications servers are
heavily loaded, monitoring team should inform the BASIS shift lead about the situation and
create a Remedy ticket for the situation.
Basis shift lead should bring up the application server if it is down or if the application servers
are found heavily loaded, the Basis member should find out if there are problems reported into
the WP trace, SM21, ST22 and resolve the error.
Green No Errors reported and all application servers are running fine.
Page 12 of 29
Monitoring
Yellow one or two work processes in error status. This might be a onetime problem due to
erroneous program.
Red More than one or two work processes are in error status or any of the application servers
are down. This might point to some major issue pointing towards memory bottlenecks in the
system.
7.4 ST22 - Checking ABAP Dumps

ST22 transaction lists all the dumps that might have occurred in the SAP systems. This
transaction should be checked in each shift and we need to take action for any dump which
might have occurred after the last monitoring being done.
Check: We need to check for any critical dumps that might hamper the running system. Such
dumps could be related to Database (DBIF*) or can be related to Kernel (SYSTEM_CORE*).
Diagram 7.4.a : ST22 Dump Illustration

Look for mass dumps which are occurring in the system since the time system was last
monitored.
Action Taken: Monitoring should create a ticket and inform the BASIS shift lead about the
situation.
Basis shift lead should Carefully look into the dump and if this is related to BASIS, we need to
correct it otherwise get in touch with the concerned person / Team who had encountered the
error. In any case please raise a P5 ticket and assign to the concerned team.
Green No Dumps reported
Yellow There are yellow dumps reported.
Red There are Red dumps reported into the system.
Few critical Dumps:
SYNTAX_ERROR: Look into the dump and find out the affected object. Send an email to the
developer affected, Please create a Remedy ticket for the analysis.
SYSTEM_CORE_DUMPED: Look into the dump to find out the reason of the error, this might be
related to Kernel issues. Accordingly send your analysis to BASIS team. Please create a
Remedy ticket for the analysis.
Page 13 of 29
Monitoring
DBIF_RSQL_SQL_ERROR: Analyze the dump and find out the reason of this dump. Such a
dump occurs when there are some deadlocks or there are some SQL errors. If there are
deadlocks please investigate and send email to BASIS team.
If the dump points out to some SQL error please contact the affected user on whose name the
dump exists.
In either case please create a Remedy ticket
7.5 SM13 Update Records

SM13 gives us the list of all update records which are pending or which are in error.
Check: Monitoring Team should check the following
There are not many pending update records
Check for erroneous update records
Update should be active
Page 14 of 29
Monitoring
Diagram 7.5.a : SM13 Updates

Action Taken: For any abnormality found the monitoring team should create a Remedy ticket
and inform the Basis shift lead about it.
Basis shift lead should take actions as per the abnormality seen.
There are not many pending update records Check if there are ample free work
processes in the systems and check the system performance.
Check for erroneous update records Inform the responsible person / team about the
error.
Update should be active Basis lead should activate the updates
Yellow Only 5 updates have failed and this could be due to some error from the development
side and wrong data being provided. This is not generic and may not impact the general system
performance.
Red More than 5 update failures or too many updates are pending. This might point towards
some serious issue in the system and may impact the overall system performance.
7.6 SM12 - Checking Lock Entries

SM12 displays all the lock entries in the SAP system.
Page 15 of 29
Monitoring
Diagram 7,6.a : SM12 Lock Entry

Check: We should check every day that there are no lock entries in SM12 which are older than
a day. Also check if there are many lock entries and system is loaded.
Action Taken: Monitoring team should inform the Basis shift lead about the abnormal situation
and create a ticket for the same.
Basis shift lead should check if there are old lock entries, please find out if there are some jobs
running for the user in SM37. Also find out the there are any user session in AL08. If no such
activities are found, please drop an email to the user to confirm the deletion of the lock entry.
Before deleting the lock entry please ask the user to log off from the system and re-check if the
locks are released. If the lock still remains check AL08/SM04 to find any RFC login for the user.
Remove these logons if any and re-check if the locks are released. If the locks are still not
released, delete the lock entry from SM12.
If the system is loaded due to too many lock entries, please check SM13, SM21, ST22, SM50 if
there are some issue.
In either case create a Remedy ticket and inform the Basis Team about the issue.
Green No old lock entries and number of lock entries are normal
Yellow Around 10-15 old lock entries. This might happen if the user is disconnected from
network abruptly and SAP is unable to detect this so the lock entry remains. Not serious issue.
Red More than 15 old lock entries or many locks into the system. This may happen if the
enqueue work process has some abnormalities and the SAP locking mechanism is not working
as desired. Such errors will also be reported in SM21.
7.7 SM37 Check Background jobs

SM37 displays the status of all the background jobs running in the SAP System.
Check: Monitoring team should check for the following situations:
Long running jobs
Page 16 of 29
Monitoring
Cancelled Jobs
Jobs in delayed status
Action Taken: For any issues identified the monitoring team should create a ticket and inform
the Basis shift lead about it.
Basis shift lead should take actions as per the situation:
Long running jobs Find out if the job is really doing something. Check the Job status
and if found that job is in a stale condition, please inform the responsible person / team
about it.
Cancelled Jobs : Please check the job logs and if the issue is related to BASIS please fix
this otherwise inform the responsible job owner.
Jobs in delayed status Check if there are sufficient WP available in the system and
take appropriate actions.
Green No long running jobs, cancelled jobs or delayed jobs
Yellow Less than 5 long running jobs or cancelled jobs.
Red More than 5 long running jobs or cancelled jobs or delayed jobs.
7.8 SOST Check outbound email and Faxes

Transaction SOST is used for manage the information which has to be sent outside of SAP
systems. Such tasks could be sending emails, FAX etc.
Diagram 7.8.a : SOST SAP Outbound emails and Faxes

Check: On the main screen in SOST we can see if there are some emails / Faxes in error staus
Sometimes the error would be related to the FAX connectivity in which case please check if the
associated RFC in SM59 is working properly.
Action Taken: If the documents in the SOST queue are in error, monitoring team should create
ticket and inform the Basis shift lead about the situation.
Basis shift lean should check if there is some RFC issue or if the SAP Send job is not running
properly in SM37. Fix the issue and ask the document owner if he wants to documents to be resent. Please raise a Remedy ticket for the same.
Page 17 of 29
Monitoring
Green No documents in error status
Yellow Around 5-10 documents in error status
Red More than 10 documents in error status which would happen if the settings in the SCOT
transaction are not correct. This could also happen if Firewall is blocking the documents from
being transmitted.
7.9 DB02 Database Administration

DB02 is a database administration transaction and displays many Db related details.
Check: Monitoring team should check the free space in the DB. They should also check the
percentage of tablespaces used.
Diagram 7.9.a : DB02 Database Administration

Actions Taken: If monitoring team find that the DB free space is below 10% of the any of the
tablespace is more than 90% utilized, they should create a ticket and inform the Basis shift lead
about it.
Basis shift lead should take appropriate actions and get more space allocated.
Green Ample free space in DB and no tablespaces above 90%
Red Either there is less DB space available or some of the tablespaces are above 90%
utilized
7.10 ST04 Check DB alerts

ST04 is also one of the DB administration transactions. Any DB related alerts can be seen from
this transaction.
Check: Monitoring Team should check if there is any error reported into the DB alerts.
Page 18 of 29
Monitoring
Diagram 7.10.a : ST04 Database Alerts

Action Taken: If the monitoring team finds some errors, please inform the Basis shift lead about
it and raise a ticket for the same.
Basis shift lead should take appropriate actions to resolve the errors.
Red There are critical alerts being reported.
7.11 DB12 Database backups

DB12 shows the DB backup, log backups and archive directory status
Frequency: This should monitored once Daily in the shift A.
Check: Monitoring team should check if there are success DB backup happening for each day.
Also check the archive log backup and the archive log directory status.
Page 19 of 29
Monitoring
Diagram 7.11.a : DB12 Database backup

Action Taken: If the monitoring team finds some failed backup or no backup happening for a
day, or if they find that the Archive log directory is more than 90% used they should create a
ticket and inform the Basis shift lead about it.
Basis shift lead should take appropriate actions to get this fixed, either by requesting for a log
backup to free up the archive log directory.
In case of failed / no backup, they should inform the responsible team.
Green No problem with the DB backup or the space available in archivelog directroy
Red There was no DB backup on the previous day or the archivelog space is very less.
7.12 DB16 Evaluate DB system check

DB 16 shows the result of the DB check performed.
Frequency: This should monitored once daily in shift A.
Check: Monitoring Team should check if there are any errors reported in the DB check report.
Page 20 of 29
Monitoring
Diagram 7,12.a : DB16 Evaluate DB check

Action Taken: If some errors are encountered in the DB check, monitoring team should create
a ticket and inform the Basis shift lead about it.
Basis shift lead should take appropriate action and get the errors resolved.
Green No errors reported in the DB system check.
Yellow If there are no errors reported. Only Warnings reported.
Red Critical errors are being reported.
7.13 DB13 - DB Calendar

DB13 is the DB planning calendar which schedules the database house keeping jobs.
Diagram 7.13a : DB13 DB Calender

Frequency: This should monitored Weekly in Shift A.
Check: Please check if any of the scheduled jobs has failed with some error over a week.
Action Taken: In case of any errors, monitoring team should create a ticket and inform the
Basis shift lead.
Basis shift lead should find the resolution of the error and fix it.
Green No cancelled jobs
Red Some of the DB jobs have been cancelled.
7.14 ST02 SAP Buffers

ST02 is a critical transaction which displays the situation of all the SAP Buffers. It has a direct
impact on the SAP system performance and should be monitored in each shift.
Page 21 of 29
Monitoring
Check: Monitoring Team should check if there is high number of swaps occurring into the SAP
system. This check should be performed on all the application servers
Diagram 7.14.a : ST02 SAP Buffers

Action Taken: If many Swaps are found into the system, monitoring team should create a
ticket and inform the Basis shift lead about it.
Basis should check the affected server and the SAP Buffer. He should check the free directory
entries and if they are more than 20% no action is required.
In addition he should also check if the hit ratio of the affected buffer is below 90%.
In case of many swaps he should look into increase the buffer allocation.
Green No Swaps occurred
Yellow Less than 5000 swaps occurred but can be ignored
Red More than 5000 Swaps are in the system and needs attention
7.15 SCC4 - Checking Client Status

SCC4 sets whether the changes allowed in System Change Option are applicable for a
particular client, and also if changes for client-dependent objects are allowed. The two SCC4
and SE06 actually work in tandem. If you allow changes in System Change Option, you still
have to set a client in SCC4 where these changes can be actually made. But even if you "open"
a client for client-independent changes, if the System Change Option doesn't allow it, you
actually cannot change client-independent objects.
Page 22 of 29
Monitoring
Diagram 7.15.a : SCC4 Client Oerview

Frequency: This should monitored monthly in shift A.
Check: All the clients should be closed and no modification must be allowed.
Action Taken: If the client is open, ask the BASIS team to check.
Green No Client is open
Red Client is open
7.16 SMQ1 - Checking Outbound Queue

SMQ1 displays all the outbound queues to send to other system.
Check: Make sure that not many queues are waiting and that there are no queues in error
status such as WAIT ENQ etc.
Action Taken: If there are many queues which are waiting to be send monitoring team should
inform the Basis shift lead with a ticket.
Basis shift lead should check in SMQS that the scheduler is working and there are no errors like
Destination not reached etc.
Page 23 of 29
Monitoring
Diagram 7,16.a : SMQ1 Outbound Queue Illustration

Error Analysis:
BASIS: In case the queues in SMQ1 are in error status make sure UPDATES in the system are
working and there are not many update errors or stuck updates.
Functional: If the error is related to functional team ask them via a ticket to look into.
Please create a Remedy ticket for analysis of the situation.
Green Queues are processing normally
Yellow There are 5-10 queues in error
Red More than 10 queues in error or there are many pending queues in the system.
7.17 SMQ2 - Checking Inbound Queue

SMQ2 displays all the inbound queues to receive from other system.
Check: Make sure that not many queues are waiting and that there are no queues in error
status such as WAIT ENQ etc.
Action Taken: If there are many queues which are waiting to be send monitoring team would
create a ticket and inform the Basis shift lead about it.
Page 24 of 29
Monitoring
Basis Shift lead should check in SMQR that the scheduler is working and there are no errors
like Destination not reached etc.
Diagram 7,17.a : SMQ2 Intbound Queue Illustration

Error Analysis:
BASIS: In case the queues in SMQ1 are in error status make sure UPDATES in the system are
working and there are not many update errors or stuck updates.
Functional: If the error is related to functional team ask them via a ticket to analyze and fix the
issue.
Please create a Remedy ticket for analysis of the situation.
Red More than 5-10 queues in error or there are many pending queues in the system.
7.18 SE06 - System Change Option

System Change Option provides granularity on what Repository and cross-client customizing
objects can be modified. This is more of a global setting (regardless of the client) and is only for
client-independent objects. In here, Repository objects are further subdivided into groups so you
can set only which group can be changed.
Diagram 7.18.a : SE06 Post installation Options
Page 25 of 29
Monitoring
Diagram 7.18b. : SE06 System Change Option

Frequency: This should monitored on a monthly basis.
Check: Global settings should be set to Not Modifiable
Action Taken: If the Global setting is set to Modifiable, send an email to the BASIS team to
take appropriate actions.
Green Global setting is set to Not modifiable
Red Global setting is Modifiable.
7.19 SICK - SAP Initial Consistency Check

Transaction code SICK analyses the SAP Kernel to find out whether any inconsistencies that
can result if problems exist.
Diagram 7.19.a : SICK Consistency Check

Check: There should not be any errors reported when this transaction is fired. This should be
checked on a weekly basis.
Action Taken: If there are any errors, please inform the BASIS shift lead them. Please raise a
Remedy ticket for the work.
Basis shift lead should take appropriate action to fix the errors
Green No errors reported
Page 26 of 29
Monitoring
Red Some errors are reported
7.20 SP12 TemSe Check

SP12 shows all the temporary sequential objects in the SAP System. We should check the
consistency of these objects on a weekly basis.
Diagram 7,21.a : SP12 TemSe Check

Frequency: This should monitored once in a week on Monday in Shift A.
Check: Run the consistency Check every week on Monday.
Action Taken: Monitoring team should delete all the inconsistent objects displayed.
Green No inconsistent objects reported
Yellow There are few inconsistent objects
7.21 SM58 Transactional RFC

SM58 displays all the Transactional RFC session in the systems:
Diagram 7,22.a : SM58 Transaction RFC

Page 27 of 29
Monitoring
Check: We should check every day and make sure there are no many entries in Error. Check if
the queues are processed slowly and there are many queues waiting to be processed.
Action Taken: If many entries in error are displayed monitoring team should inform the BASIS
shift Lead.
Basis Shift Lead should analyze the error. If there are some SQL errors, we need to fix them.
If the issue is due to slow processing, we should look into the updates and lock entries in the
system. Such errors will also be reported into SM21 logs and sometimes we can find related
ST22 dumps as well.
Also check if the user / password of the RFC user is not working or if the user is locked. If such
is the case please reach out to the SEC team to get this fixed and inform the functional team to
reprocess.
If the issue is pointing to the functional team, please create a Remedy incident and assign it
directly to the functional team.
Red More than 10 queues in error or there are many pending queues in the system.
7.22 SMLG - Checking Logon Groups

SMLG allows us to configure logon groups and can be used to verify that the load distribution is
working correctly in the system.
Frequency: This should monitor once in a month.
Check: Verify that the logon groups are configured and the load distribution is happening such
that all the servers have good quality. (Lower the value better the quality)
Check that all the application servers are up and running.
Action Taken: In case any application server is found down or any quality issues reported
monitoring team would inform the Basis shift lead and create a ticket.
Basis shift lead should consult the team members if some activity is going on otherwise bring
the server up
Secondly, if the server Quality is low, try to diagnose the reason for the same by looking into
SM21 logs and other traces.
Green All application servers are up and load balancing is happening fine.
Red Some of the application servers are down or the load balancing is not happening
properly.
7.23 BDF UNIX check for critical file systems

BDF command is fired at the UNIX level to check if there are any file systems which are space
critical.
Page 28 of 29
Monitoring

Check: We should check every day and make sure there are no FS which are space critical
Action Taken: If any space critical FS are detected, monitoring team should inform the BASIS
team about it.
BASIS team should check this and create a Remedy ticket for getting the extra space allocated
to the affected FS.
Green No critical FS found.
Red Few critical FS found.
7.24 Check the database backup report

A backup report is generated daily which has the status of database backup of all the systems.
Check: Check the report to find out any failed backups. Also make sure that the backup of all
the monitored systems is happening.
Action Taken: If there are any failed backup or missing backup please notify the BASIS on call
person immediately.
BASIS team should check this and create a Remedy ticket for the backup team to get the
backup done for affected systems.
Green No failed or missing backups.
Red There are failed or missing backups.
7.25 DB01 Check exclusive DB locks

In the transaction DB01 we can find out the Deadlocks or DB locks.
Frequency: This should be monitored daily in each shift.
Check: Check for any exclusive locks or database deadlocks in the system.
Action Taken: If there are database deadlocks or exclusive locks in the system please notify
this to the BASIS team.
BASIS team should check the reason of the deadlock. This may have happened due to multiple
jobs running at the same time and trying to update the same object. Basis team should create a
ticket and assign it to the affected team so that they can take appropriate actions.
RAG Status: We should report the following status based on the status
Green No exclusive DB locks.
Red There are deadlocks in the systems or there are many exclusive database locks in the
system.
Page 29 of 29

Monitoring

Uploaded by

Copyright:

Available Formats

Monitoring

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Monitoring

Uploaded by

Copyright:

Available Formats

Monitoring

3 Best Practices for SAP System Monitoring

3.1 Basis Monitoring: General System Checks:

Completion of backups and archives and sufficient

All scheduled jobs running successfully and

Space critical objects, missing indexes, blown

DB buffer quality, exclusive lock waits and the DB

Investigate new errors as well as resolved issues

Investigate short dumps that could have an effect on

Old lock entries

Update being active and any failed updates

Application server status

Work Process Monitor

Work Process Monitor

completed background jobs as well as what is still

Printing is completing and not in error

Check log of ensure ICM is running without errors

Table 3.1.a : Basis Monitoring: General System Checks

4.1 Generic System Monitoring for All Usage Types

11. DB12 Check the Archive log directory

4.2 Monitoring through the BASIS Work Bench lite Tool

Multiple SAP Systems can be monitored on a single click.

One time activity for entering login Credentials

Output is presented in the form of monitoring worksheet:

Example excel sheet is attached:

Apply license in SAP: Go to transaction SLICENSE -- EDIT -- Install License

5.1. System Administration tasks

5.1.1. Daily tasks

Check for any errors

6. SAP: Checking for ABAP Short Dumps (ST22).

Reviews lock entries being held for lengthy periods

5.1.2. Weekly tasks

5.1.3. Monthly tasks

5.1.4. Adhoc Tasks

SAP: Checking the Transport Management System (STMS)

SAP: Deleting Old User Master Records (SU01)

SAP: Checking User Activities (SM04)

SAP: Job Scheduling (SM36)

SAP Note 723909 - Java VM settings for J2EE 6.40/7.0

5.1.5. Template for Daily Monitoring and Health check

7 Technical Monitoring Steps

7.1 SM21 - Checking System Log

Diagram 7,1.a : SM21 System Logs

Green No Errors or warnings reported

7.2 SP01 - Checking Spool Output Request

Diagram 7,2.a : SP01 Spool

7.3 SM51 Check the SAP application Servers

Diagram 7,3.a : SM51 SAP Application Servers

Diagram 7,3.b : SM50 SAP Work processes

7.4 ST22 - Checking ABAP Dumps

Diagram 7.4.a : ST22 Dump Illustration

7.5 SM13 Update Records

There are not many pending update records

Check for erroneous update records

Update should be active

Diagram 7.5.a : SM13 Updates

Update should be active Basis lead should activate the updates

7.6 SM12 - Checking Lock Entries

Diagram 7,6.a : SM12 Lock Entry