sap basis monitoring

Sap System Monitoring

SAP System Monitoring

SAP system administrators rely on various transaction codes and tools to monitor, troubleshoot, and optimize system performance. Here we will cover all the topics related to system monitoring including application servers, work processes, user sessions, database performance, and overall system health.

1. Monitoring Application Servers in SM51

  • Server Status: From transaction SM51, administrators can check whether all SAP servers are running. If a server is unavailable, its hostname will not appear.
  • Instance Information: You can also view the number of users logged into instances, assess current activity, and monitor the load on each instance.
  • Server and Queue Info: SM51 provides a list of all application servers, their status, queue information, and SNC (Secure Network Communications) status.
  • Instance Status: Use transaction RZ03 to view the status of all active and inactive instances.

2. Monitoring Work Processes in SM50 & SM66

  • Long-Running Work Processes: Check for processes running for an unusually long time.
  • Process State: Evaluate the current state of work processes and cancel any unnecessary or stuck processes via the “Process” menu (option: “Cancel”).
  • Canceling Processes: When a process is canceled, ongoing transactions are terminated, and the dispatcher starts a new process.
  • OS-Level Work Process Monitoring: Use DPMON to view work processes at the OS level.

3. Monitoring Active Users (SM04, AL08)

  • User Activities: SM04 and AL08 show active users, their activities, and users who have lost their connections.
  • Additional Info: View the number of RFC users, interactive users, terminal details, and active instances.

4. Logon Load Balancing in SMLG

  • Load Distribution: In SMLG (press F5 for load distribution), you can view logon groups, response times and average response time for all application server, and the number of users per instance.
  • Failover Handling: If an application server goes down, users are connected to the best available server within the logon group.

5. ABAP Dumps in ST22

  • Monitoring Program Errors: When users encounter errors in their programs, dumps are generated in ST22. These dumps provide details about the error, including what happened, possible resolutions, affected tables, and impacted programs.
  • Common ABAP Errors: Syntax errors, invalid database requests, and database inconsistencies. These dumps are stored in the SNAP table, and old dumps should be deleted to prevent future issues.
  • Handling Excess Dumps: If more than 20 dumps occur, administrators should notify the client.

6. Lock Entries in SM12

  • Managing Locks: Locks older than one day should be analyzed and deleted if necessary after the confirmation from functional team. Normally, locks are released when transactions commit or users finish working.
  • Unreleased Locks: Long-running jobs, SAPGUI terminations, or update processing issues can lead to locks remaining unreleased. To address this, you can delete lock entries or log off the user in SM04.
  • Testing Enqueue Work Process: Go to SM12 → Extras → Diagnosis to test whether the enqueue process is functioning correctly.

7. Terminated Updates in SM13

  • Monitoring Updates: Check for hanged or pending updates in SM13. Failed updates should be repeated based on the type of error.
  • VBLOG Table: All update requests are stored in this table.
  • Cancelled Updates: Monitor cancelled updates in SM14.

8. Client Status in SCC4

  • Production Client Management: Ensure the production client is closed unless explicitly approved. A closed client means no changes can be made to repository objects without automatic recording. Use protection level 2 for maximum security.

9. Database Monitoring in DB02

  • Table Space Usage: Ensure table spaces don’t exceed 90% usage. If they do, increase space by adding data files using SAPDBA.
  • Missing Indexes: Check for missing primary or secondary indexes in DB02. Missing indexes should be reported to ABAP developers.
  • Space-Critical Objects: Address space-critical objects that could cause the system to hang by adding data files to the table space.
  • Monitoring high cost query: Monitoring high cost query in DB02 tcode in database process option.
  • Data space and log space: Monitoring log space and data space in DB02 Tcode in the space option.

10. Background Jobs in SM37

  • Monitoring Jobs: Monitor job statuses and cancel long-running or stuck jobs. If a job is in an active state for too long, it may need to be killed at the SAP level (SM51) or OS level.
  • Recurring Job Failures: If a particular job is canceled more than 20 times, notify the user.

11. Spool Requests in SP01

  • Monitoring Spool Jobs: Look for spool jobs that have been in process for more than an hour. Investigate possible causes, such as printing problems, and review spool logs.
  • Spool Errors: If there are more than 50 spool errors, delete them or schedule an automated job for cleanup.

12. Backup Logs in DB12

  • Backup Status: Check if the last backup was successful and monitor redo logs and archive directories. Investigate potential issues like full sapbackup disks.

13. OS Logs and CPU Utilization in ST06/OS06

  • Monitoring OS Performance: Use ST06 or OS06 for detailed OS performance analysis, including CPU, memory, swaps, disks, file systems, and network performance. The system provides historical OS data for up to 24 hours.

14. Alert Monitoring in ST04 and RZ20

  • Database Alerts: Monitor database alerts and set thresholds using RZ20. You can create custom monitors and alerts.
  • System Errors: Review database error logs in ST04 and monitor log directories at the OS level.

15. System Logs in SM21

  • Log Monitoring: SM21 stores all system messages, including problems, warnings, and general information. Pay special attention to database related errors and update termination errors.
  • Remote Logs: You can also monitor logs from remote systems in SM21.

Performance Tuning in SAP

  • Large Wait Time: Indicates issues with work process sizing or network/RFC connections.
  • Large Roll-Wait Time: Could be due to problems with network connections.
  • Large Load Time: Buffer sizes (PXA or CUA) may be too small.
  • Large DB Request Time: Look for expensive SQL statements, missing indexes, or CPU/memory bottlenecks.
  • Large CPU Time: Typically caused by processing large tables or frequently accessing R/3 buffers.
  • Large Processing Time: Caused by CPU bottlenecks or network issues.

Response Time Analysis (ST03N):

  • Optimal Response Time: Should not exceed 1000 ms for dialog steps.
  • High DB Request Time: If DB request time exceeds 500 ms, investigate missing indexes or expensive SQL statements.
  • High CPU Time: CPU time greater than 400 ms could indicate faulty logic in ABAP programs.
  • High dialog response time: Check average dialog response time.

 

Leave a Comment