SAP System Monitoring gives you an idea of the status of your technical systems. It gives you a lot of data and knowledge where databases, hosts, and associated instances are concerned. It functions by carrying out checks automated for specific intervals in these categories: Configurations, Exceptions, Performance, and Availability. Depending on the type of object being managed, several metrics and certain thresholds can be set.
So, why is SAP monitoring important exactly? Well, if you own a business, you are bound to experience system downtimes. These, not only reduce productivity but also result in lost revenue due to all the wasted working hours. System monitoring works to prevent this by spotting the problem as soon as it appears. However, as this is a daily task that is mind-numbingly boring, it would result in high turnover and reduced work morale if done manually by employees.
This article will show you the simplicity and efficiency of using automated systems to ensure your business continues running like a well-oiled machine.
What is system monitoring in SAP?
System monitoring is an activity done on a daily basis to assess system functionalities to determine whether the performance is as per the expectations or not. It gives an overall view of the technical concepts and aspects. This makes system monitoring more proactive.
An enhanced system performance makes the business organization more profitable. A few of these System Monitoring Tasks include:
- Monitors Spool Requests
- Monitors the Number of Print Requests
- Monitors Individual Instances Work Processes
- It monitors Update Processes
- It assesses System-wide Work Processes
- Monitors System Logs
- Monitors Lock Entries
- Monitors Batch Jobs
- Monitors Application Users
- Monitors the Database Performance
- Monitors Database Checks
- Monitors available space in the database
- Assessing the CPU Utilization
- Monitoring Application Servers
- Checking Buffer Statistics
- Checking the ABAP Dump Analysis
How do I monitor a web service in SAP?
We monitor web services to determine the status of messages, unearth errors that came up during processing, analyzing the source of these errors, and performing a search to find messages that match the intended search criteria.
Synchronous message errors are logged into the error log while information about asynchronous messages is displayed in the message monitor. The authorization object S_SRT_MONI or S_XMB_MONI assigns you a role.
Use the Monitoring tab in the SOA Manager (SOA Manager is the transaction code) or use the transaction code SRT_MONI in the SAP GUI to start the message monitor. The initial screen of the message monitor will assist you in defining the message selection criteria you want to be displayed. Here, you can:
- Choose the kind of result output you want; It could be in Detail or in Summary
- Choose the kind of view you want. It could be the Basic or the Technical View
- Pick the selection criteria of your choice
- Carry out the message query
- Reselect messages. This is done by using the prompt that goes by the same name (Re-Select) in the detailed result output list.
As web service messages get automatically deleted from the SAP system with a default timeline of a week, you might need to alter this period if you want to keep messages longer. To do this, start the transaction SXMB_ADM. Next, select the option of Schedule Delete Jobs and then change the retention settings as per your requirements
How does SAP Basis Check Performance?
To check performance, SAP basis uses a combination of transaction codes. The main ones include:
SM04: Operating System Performance Analysis
This code basically helps keep track of the general performance of the system. SAP manages this by checking the Operating system components including CPU, memory, network utilization and hard disk.
It also checks for any jobs that are consuming more that 60% of the TOP CPUs resources and the network collision between the end user and server.
ST04: check and analyze the DP performance
This transaction code shows in detail how the database behaves. This includes the usage, in both current time and history. In this case, there are a few things you’ll need to ensure:
First, you should check the data buffer cache quality and size. It should be above 95%, which translates to less physical read from the disk.
Secondly, the user/ recursive call should be greater than 2. This will, in turn, give the recursive call more overtime. The read/user call should also be greater less than 30. Anything greater means more expensive SQL statements.
Thirdly, the sort sections should be lower than 0.1% of the sum total sorts, the time/user call should be less than 15, busy time and CPU time ratio should be 60:40 ratio. Any higher ratio would require some tuning.
Finally, consider the shared pool statistics. The data dictionary (DD) cache quality must be more than 99%.
ST06: the CPU utilization
The percentage of CPU utilized is directly proportional to the systems performance. An idle CPU utilization rate should be 60-65%, if it goes past the value than you have to check a few things.
Start by running OS level commands. In each instance, check which processes are taking the most resources.
Then move to SM88 or SM50. Here, you want to look for any long update queries running or long running jobs.
Move to SM12 and look at the lock entries, then to SM13, and look at the update active status.
Finally check for any errors in SM21.
ST02: check the tune memory
The next check is looking at buffered memory. Here, SAP highlights the compromised entries in red. You can use this to identify exactly which processes are affected, and in what severity.
How Do I Know If My SAP system is Slow
There are a few steps you can use to check if your SAP system is low. We shall highlight some of these steps below.
Ideally, you want to start by login in to the system and checking the following transaction codes.
SM66: Overview on Global/ system wide Work Process
This code will help you monitor the actual work process load that is currently on active instances within the system. With this, we you get to investigate any potential cause of a problem in system performance, or identify any locks within the database.
On the global work process overview’s screen, you’ll see a couple of things. These include the status of every application server, the reason why it isn’t running, whether or not it has been restarted, the running report, the request run time and CPU, as well as, the user who is logged on and client they are logged on to.
SM50: Overview on work processes for every individual processes
This code will help keep track of work process loads acting on specific instances. The transaction displays a variety of information including any waiting, running, PRIV and stopped processes that are related to a specific instance and whether they are free or occupied.
Here you want to check on all the process. Make sure that they are always running or waiting. If the process has any other status, you have to check the process and then report accordingly.
SM37: check background and batch jobs
Here, you basically check for any long running jobs
SM12: Lock Concept
This checks for any long held locks
The main reason why we do basic checks and system monitoring is to ensure that the processing of business is always reliable and efficient. This means constantly checking on application servers, monitoring system-wide processes as well as individual processes and lock entries, with the intent of optimizing your system. With SAP Basis and System Monitoring, your system is always kept secure and stable while avoiding any issues due to pro-active basis.
For more information on sap basis – system monitoring check out Avantra. Its real-time monitoring tools boast of more than 160 built-in checks, working to free your team from depending on tasking SAP tools and Solution Manager. You also get to customize the checks by defining the monitoring capabilities of your checks so you receive regular reports.