Vous êtes sur la page 1sur 29

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).
Report any inconsistencies found
17. ORACLE: Checking and Creating CBO Statistics (DB24/DB13)
Report any inconsistencies found
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


Frequency: This should monitored once in each shift
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.
Frequency: This should monitored once in each shift
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.
RAG Status: We should report the following status based on the errors we see.
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.
Frequency: This should monitored once in each shift
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.
RAG Status: We should report the following status based on the errors we see.
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.
Frequency: This should monitored once in each shift
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

RAG Status: We should report the following status based on the errors we see.
Green No Errors reported
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


Frequency: This should monitored once in each shift
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.
RAG Status: We should report the following status based on the errors we see.
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.
Frequency: This should monitored once in each shift
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.

RAG Status: We should report the following status based on the errors we see.
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


Frequency: This should monitored once in each shift
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

RAG Status: We should report the following status based on the errors we see.
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.
Frequency: This should monitored once in each shift
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.
RAG Status: We should report the following status based on the errors we see.
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.
Frequency: This should monitored once in each shift
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.
RAG Status: We should report the following status based on the errors we see.
Green No Errors reported
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.
RAG Status: We should report the following status based on the errors we see.
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.
RAG Status: We should report the following status based on the errors we see.
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.
RAG Status: We should report the following status based on the errors we see.
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.
Frequency: This should monitored once 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.
RAG Status: We should report the following status based on the errors we see.
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.
RAG Status: We should report the following status based on the errors we see.
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.
Frequency: This should monitored once in each shift
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.
RAG Status: We should report the following status based on the errors we see.
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.
Frequency: This should monitored once in each shift
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.
RAG Status: We should report the following status based on the errors we see.
Green Queues are processing normally
Yellow There are 5-10 queues in error
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.
RAG Status: We should report the following status based on the errors we see.
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


Frequency: This should monitored once in each shift
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
RAG Status: We should report the following status based on the errors we see.
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.
RAG Status: We should report the following status based on the errors we see.
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


Frequency: This should monitored once in each shift

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.
RAG Status: We should report the following status based on the errors we see.
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.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.
RAG Status: We should report the following status based on the errors we see.
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

Frequency: This should monitored once daily in shift A.


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.
RAG Status: We should report the following status based on the errors we see.
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.
Frequency: This should monitored once daily in shift A.
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.
RAG Status: We should report the following status based on the errors we see.
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

Vous aimerez peut-être aussi