SM50 : (Process Overview)

This transaction code will be useful to view the processes that are running currently in an sap
insance. In this view you can check whether there are free workprocesses to execute the processes.
If all the workprocesses are in running state and no work process is idle it means that wait times will
increase for the processes that are waiting in the dispatcher queue leading to performance
degradation. If you find that there are no free workprocceses for maximum times that you may
consider, increasing the number of workprocesses.

How to increase the number of work processes

SM66 : (Global process overview)

This transaction code will be useful to view the processes that are running across all
instances/application servers of a SAP system. Similar to SM50 checks can be done in this transaction
as well.

SM51 : (Application servers status)

This transaction code will be useful to view all the hostnames and application servers status. If any
application server is down, the same can be identified using status of the server column. We can also
figure out different Message types (Dialog, Batch, Update, Upd2, Spool, ICM etc) configured for the
respective servers.

SM12 : (Lock entry list)

This transaction code will be useful to view all the sap locks that are present in the system. As part of
monitoring, we need to look for any old sap locks that are more than 1 day. If any such locks, we
need to analyse the reason for that lock for such longer duration and take actions accordingly. A lock
can be set for such a long duration due to a long running background job or a lock is not released due
to an application error or a program terminated abruptly but lock not released etc.
How to delete a sap lock?

ST22 : (ABAP Dumps )

This transaction code will be useful to view all the abap dumps that have occured in the system on a
given day. As part of daily monitoring, it is the responsibility of the basis administrator to analyse the
dumps and take necessary actions to avoid issues.

Some of the examples of abap dumps are timeout issue, database space issue, spool overflow
issue etc

SM21 : (System log)

This transaction is useful to view the log of the sap system for various operations. This log will be
very useful to identify various issue in advance and to take necessary measures. System log is the
place to check out for any timeout, network issues, database space issues, message server issues,
spool overflow, locktable overflow etc issues.

Additional details :

SAP System log

SM13 : (Update Requests overview)

This transaction is useful to figure the status of update system. Incase an update is inactive we can
figure out the same from this transaction and necessary action can be taken and update can be
activated again.
Update got deactivated. what is the reason for update deactivation? How to activate the update ?

SM14 transaction can be called internally from SM13. These both transactions are useful for update
administration.

In SM13, you can select status (canceled, to be updated, v1 executed, v2 executed, all ) and time
interval during which you would like to view the status execute to check the overview of updates as
per the status and time interval selected.

In case of canceled updates, analysis to be done whether to repeat update.

ST02 : (Tune summary )

This transaction will be used to monitor

 Buffer statistics like hitratio, swaps, db access details, size of buffer and free size of buffer etc

 Important statistics related to Roll area, Page area, Extended memory and heap memory

 Call statistics like select, insert, update and delete

As a basis administrator, it is our responsibility to ensure there is more hit ratio for the buffers and
less swaps to ensure efficient performance of the sap system. In case you see there are more swaps
and less hit ratios for most of the buffers, then tuning buffers to be carried out to ensure optimal
performance.

DB12 (Backup logs) : This transaction is useful to check the details of

 last successful backup

 overview of database backups ( Success / failure of backup with log details)

 Archiving directory status (Free space of oraarch )

 Overview of redolog files ( Number of redologs that are not yet backed up)
  overview of redolog backups (Success / failure of backup with log details)

DB13 (DBA Planning calender) :

This transaction will be useful to schedule various database backups & clean up jobs like ( whole
database backup offline/online, Full backup online/offline, incremental backup offline/online,
redolog backup, update statistics, check db, cleanup logs, compress database, verify database,
initialize tape and validate structure jobs).

In this transaction, you can also check the status of every job that was scheduled and can reschedule
in case of failures.

DB14 (DBA operations log) :

This transaction will be useful to check the status of following :

 Database backup

 Redolog backup

 BRSPACE log (extend tablespace issues etc)

 BRCONNECT operations (Update optimiser statistics , database check etc)

As an sap basis administrator it is our responsibility to check and ensure backups and other cleanup
jobs are successful everyday. Incase of failures, should figure out root cause and take actions like
rescheduling and ensure these jobs are successful.

SM37 ( Job status overview) :

This transaction will be useful to have an overview of jobs with different statuses.

As part of daily monitoring, SAP basis administrator should use this transaction to findout canceled
jobs and active jobs(for eg: long running - more than 24hrs etc).
Incase of canceled jobs, root cause for the failure to be figured out from the logs of the respective
job and to be actioned by rescheduling etc.

Incase of long running jobs, we need to figure out the reason for long running and action them
accordingly.

In SM37, using extended job selection option, we can even select the jobs based on start condition,
steps (like abap program, external command or external program), period etc

How to identify long running jobs in sap ?

How to troubleshoot a background job running for long duration in sap?

ST04 (Database alert logs and performance) :

This transaction will be useful for (oracle) database administration. In this screen, goto Alerts and
drill down further. Click on "Database Check" to find out any errors or warnings related to database
like MISSING_STATISTICS, STATS_TOO_OLD, LAST_BACKUP_FAILED, LAST_ARCHIVE_FAILED etc. After
going through the error or warning in details take necessary corrective actions based on the error like
running update stats again, re-triggering backup etc

Under Alerts, you can view Alert monitor which will summarize status of the database under
different heads like

 Space Management

 Performance

 Backup/restore

 SAP Consistency

 Health

Drill down on each of these to find out potential problems. These are color coded for ease of
administrator (Red for errors, yellow for Warnings and Green for OK status)
For Eg: If PSAPSR3 tablespace is >90%, you can see Space management in red color. Then it is the
responsibility of Basis administrator to take necessary actions on the same.

SP01 ( Check Spool status ) :

This transaction is useful to find out the status of spool request and output request. In SP01
transcation, you can list the spool requests or output requests between a given interval.

In the list generated, you can check out the status of spool requests and findout any errors by drilling
down further.

For eg: if so many spools are in waiting status, find out whether output device is available or not.

If many spool are in error status, figure out if there is any network issue and take necessary actions.

What are the different Spool statuses and their significance?

If customers complain that they are not able print anything from SAP, check out whether there is any
spool overflow.

What is spool overflow ? How to troubleshoot spool overflow issue ?

SXI_Cache : This Tcode is specific to XI or PI system. This Tcode is used to findout whether cache
refresh is happening or not. Incase if cache refresh is happening successfully, it will indicate the same
in green color. Otherwise it will be in red indicating a problem with cache refresh.

If there is a problem with cache refresh then basis administrator has to troubleshoot the same.
SLDCHECK : This Tcode will be useful to figure out whether connection to the SLD system from the
system on which you are testing is fine or not. In case the connection is fine, all checks will appear in
green. Incase of any issues, it will appear in red or yellow and then basis administator has to
troubleshoot it and make sure SLDCHECK is working fine.

Ensuring SLDCHECK is working fine is important to keep all systems in the landscape in sync.

SXI_MONITOR : This TCode is specific to XI or PI system. This transaction will be useful to figure out
any errors or warnings in the processing of XI or PI messages. In case of any issues, this needs to be
informed to functional team and should be troubleshooted accordingly with the functional team
inputs.

DBO1 : This transaction code is useful to findout the database locks that are present in the SAP
system.

Please find below table which summarizes daily monitoring tasks that are to be performed by the
SAP Basis Administrator :

Sno Task
 ABAP Stack Checks

1 Check process overview(SM50)

2 Check overall system process overview(SM66)

3 Check application servers status(SM51)

4 Check for any pending locks (SM12)

5 Check for Dumps in the system(ST22)

6 Check System log for any errors(SM21)

7 Check for any hanged updates or update status(SM13)

8 Check for excessive swapping (ST02)

9 Check for critical job status like backup,updatestats,checkdb etc(DB13)

10 Check for longrunning/failed jobs status(SM37)

11 Check database alertlogs and performance(ST04)

12 Check spool job status (SP01)

13 Check cache status (sxi_cache) for PI System

14 Check SLD functionality(SLDCHECK)

15 Check SXI_MONITOR for PI system

16 Check for Database locks(DB01)

Java Stack Checks

1 Check java portal accessibility using link

2 Check server0 log for java system for critical errors

3 Check accessibility of management console

4 Check server node status

5 Check default trace for critical java errors

6 Check java reports for memoryconsumption/swapping

Os level checks

1 Check filesystems usage (shouldb be <80%)

2 Check for swap space using topas etc

3 Check for work directory log files at oslevel for errors

Transaction code SM51 is to display a list of active application servers that have registered in the SAP
message server. Further, you can manage & display the status, users, and work processes in all
application servers belonging to the SAP System.

SM66: Global Work Process

SM66 is used to check the Active Work Process of all the instances. No, work process status should
be in PRIVATE mode if it's then wp is consuming more memory.

If any work process is in PRIV mode, go to SM51 and Check the server name, instance number, and
contact the user if he is working in the system or not. If the user is not available Cancel the process
without the core.
SP01: Spool Request Selection

In SP01 t-code we check the Spool Request data.

Execute the report with the required date and if the requested data is more than 500 we will get a
popup to select the entries.
At the end of the page, we can find the following data for the spool request.

SMGW: Gateway Monitor

The Gateway Monitor (transaction SMGW) is used for analyzing and administrating the gateway in
the SAP system. We check the number of Active gateway connections.

SM37: Job Selection

Transaction code SM37 is used to monitor the background, batch jobs running in the system.

From the initial screen, you can search by the job name, user name, or program name accordingly
with the time condition.
 Scheduled - Job already been defined, but the start condition has not yet been defined.

 Released - The job has been fully defined, including a start condition.

 Ready - The start condition of a released job has been met. A job scheduler has put the job
in line to wait for an available background work process.

 Active - The job is currently running. Active jobs can no longer be modified or deleted.

 Finished - All steps that make up this job have completed successfully.

 Canceled - The job has terminated. This can happen in two ways:

1. An administrator intentionally terminates the job

2. A job step contains a program that produces an error, such as:

3. An E or A error message in an ABAP program

4. A failure return code from an external SAPXPG program

In SM12 we check the Lock entries. No lock entries should exist for more than 24hours. The number
of lock entries should not exceed more than 500.

Check the list.

Transaction code SM21 is used to check and analyze system logs for any critical log entries. The SAP
System logs are all system errors, warnings, user locks due to failed login attempts from known users,
and process messages in the system log.

 From the initial screen, go to System Log -> Choose -> All remote system logs. Set the date a
day before and click on the Reread system log.

 In the system log analysis window, you can check/analyze the critical error message by
double-clicking it.

The list can be restricted for Problems Only, Problems, and all messages.
SM13: Update Records

Here we check the update records of the system which are getting canceled. If the records are
reached more than 50 then we need to take action.
ST22: ABAP dumps

Transaction code ST22 is used to lists the ABAP dumps generated in the system, we can check for a
date, user as required.
Every dump indicates the reason for the error, transaction code, variables that caused the error. The
types of error can be of various kinds for which action is to be taken to fix this error from happening
again after analysis.

SMQ1: qRFC Monitor (Outbound queue)

We need to check if any outbound entries got stuck in the queue. If so check with the respective job
owner and re-execute the entries.

SMQ2: qRFC Monitor (Inbound queue)

We need to check if any Inbound entries got stuck in the queue. If so check with the respective job
owner and re-execute the entries.

SM58: Transactional RFC

In SM58 we can check the transactional RFC errors if any occurred.

We can observe different types of errors for different functional modules check the target system
entries and perform the required analysis if the user requires it then we can re-execute those entries
or else we can delete the entries from the system. For example, we are deleting the
WORKFLOW_LOCAL_100 Entries.

Go to the log file -> Reorganize

We are supposed to delete only Connection errors, System error, and Already Executed.

ST02: SAP Memory Configuration monitor

SAP Memory Configuration monitor checks the SAP Buffers and SAP Memory areas for problems
such as swapping.

It is a snapshot of the utilization of SAP shared buffers.

High watermarks of utilization for example extended, roll, paging, and heap memory can be obtained
from the SAP memory configuration monitor.
ST06: Memory Overview / Operating System Monitor

The operating system provides the instance with the following resources:

 Virtual Memory

 Physical Memory

 CPU

 File system Administration

 Physical disk

 Network
You can use the operating system monitor to monitor the system resources that the operating system
provides. The operating system collector SAPOSCOL collects these resources.

DB02: DBA Cockpit

Transaction code DB02 is to analyze and monitor database statistics (DB growth, tablespace size,
missing index &, etc.).

1. Check Tablespace size. Go to Tablespaces -> Overview. If a tablespace size is reaching a 95%
level, it’s advisable to increase the size. The Auto-extend should be Yes.
SMLG: Load Distribution

We need to check this tcode for performance issue, here we check the Response Time in load
distribution of the Instance.

Go to-> SMLG -> Load Distribution icon

ST03N: Workload analysis

The ST03 Workload Monitor is the central access point for analyzing performance problems in the
SAP system. ST03N is a revised version of the transaction ST03. In the current SAP Releases
transaction, ST03N replaces transaction ST03 and is automatically started when you enter
transaction code ST03.
Here you can compare the performance values for all instances, and compare the performance of
particular instances over a period of time. Due to the number of possible analysis views for the data
determined in transaction ST03, you can quickly determine the cause of performance problems.

You can use the workload monitor to display the following, among other things:

 Number of instances configured for your system

 Number of users working on the different instances

 Response time distribution

 Distribution of workload by transaction steps, transactions, packages, sub-applications, and

 Transactions with the largest response times and database time

 Memory usage for each transaction or each user per dialog step

 Workload caused by RFC, broken down by transactions, function modules, and destinations

 Number and volume of spool requests

 Statistics about response time distribution, with or without the GUI time
  Optional: table accesses

 Workload and transactions used by users, broken down by users, accounting numbers, and
clients

 Workload generated by requests from external systems

STMS_IMPORT: Transport Request

This tcode is used to import the transport requests to the system. But for daily monitoring purposes,
we use it to check the import history.

Go to-> STMS_IMPORT -> select the History Icon.

In SCC4 we check whether the client is open or closed.

Go to -> SCC4 -> select the Production Client

If the Changes and Transports for Client-Specific Objects are -> No Changes Allowed then Client is
Closed. Other than that any option is selected then the client is Opened.

Also, make sure Cross-Client Object Changes are set to No Changes to Repository and cross-client
Customizing Objects.