SAP Monitoring

• SM50 / SM66: work processes on the local/whole system.
• SM37: background jobs.
• SM13: update records (failed updates).
• SM21: the system log.
• ST22: ABAP runtime errors (dumps).
• ST02 / ST04 / ST06: buffers, database, OS.

Healthy operation means work processes not all busy or stuck, no update failures (SM13), no flood of dumps (ST22), the system log (SM21) free of serious errors, jobs completing on time, and database/OS resources within limits. Deviations are early warnings of trouble.

Every Basis administrator has a morning routine, and it is worth learning as a sequence rather than as a list of transactions, because the order reflects what depends on what.

1. Is the system up and are the work processes healthy. SM50 for this instance, SM66 across all of them. All processes busy, or one running for hours, is the first thing to see.
2. Did anything dump. ST22. A handful of dumps is normal life. A sudden cluster of the same dump is an incident that has not been reported yet.
3. Did the updates complete. SM13. Failed updates mean a user believes they saved something that was not saved, which is worse than an error message.
4. Did the background jobs run. SM37. A cancelled nightly job is a problem the business will find at nine.
5. Are the queues moving. SM58 for transactional RFC and the qRFC monitors. Entries piling up mean an interface partner is down.
6. Is there space. Filesystems, tablespaces and the log volume. DB02 for the database side.
7. Anything in the system log. SM21, which records what the system itself thought was worth noting.

Seven checks, ten minutes once familiar, and they catch most things before a user does.

Half an hour when something is genuinely slow, and this sequence narrows it quickly.

1. SM66. Are processes all busy, and are they doing the same thing. Many processes on one program points at that program.
2. SM50 on the busy instance, and look at the running time and the table being accessed on each.
3. ST03 for the workload profile. Which transactions consumed the time, and was it database or CPU.
4. ST04 or the database monitor for expensive statements. A missing index shows up here.
5. SM12 for lock entries. A lock held by an abandoned session blocks everyone behind it, and it looks like slowness rather than a lock.

The distinction the sequence establishes is whether the system is slow or one thing is slow, and those have entirely different answers. See performance for the tuning side.

Beyond manual checks, SAP Solution Manager / Cloud ALM and alerting automate monitoring, raising alerts on thresholds so administrators act before users are affected. Proactive monitoring is the mark of a well-run system.

The distinction that matters is between a check somebody performs and an alert that finds somebody. Manual rounds catch what happens during working hours; alerting catches the two in the morning failure that would otherwise be discovered at nine. Any check on this page that matters is a candidate for an alert, and the ones that are not alerted are the ones that will surprise you.

• Alert on things somebody would act on now. A cancelled nightly job, a filling filesystem, a stopped queue, a system down. Each has an obvious action.
• Do not alert on normal variation. A dump, a slow dialogue step, a single failed login. Alerting on these trains people to ignore alerts, which is worse than not having them.
• Thresholds by consequence, not by neatness. Eighty per cent on a filesystem that grows a percent a week is fine; on one that fills in an hour it is already too late.
• Every alert needs an owner and a runbook. An alert nobody knows how to answer is noise with extra steps. See profiles for the parameters behind much of this.

For a system that runs the business, catching a filling file system, a stuck update, or a queue of failing jobs early prevents outages. Monitoring is how administrators stay ahead of problems.

A large part of keeping a system healthy is work scheduled to run when nobody is watching, and knowing which jobs matter is what separates a Basis administrator from somebody who restarts things.

Standard housekeeping covers the jobs that stop the system filling up with its own records: reorganising spool requests, deleting old job logs, clearing outdated update records, and tidying the temporary tables. SAP ships a set of these and they are scheduled during installation. Where they were never scheduled, the symptoms appear months later as a database growing for no obvious reason.

Application housekeeping is the module-specific equivalent: clearing processed IDocs, archiving completed documents, deleting expired change pointers. These need business agreement because they touch real data, and archiving in particular is a project rather than a job.

The daily operational jobs are the ones the business notices: payment runs, MRP, billing due lists, interface processing. When one of these fails, somebody's morning is ruined, and they belong on an alert rather than a check.

SM37 is where all of it is monitored. The useful discipline is looking at cancelled and long-running jobs rather than scanning the whole list, and knowing which jobs are expected to take hours so that a long runtime is not automatically alarming.

Job dependencies matter too. Jobs chained by successor relationships stop cleanly when one fails; jobs scheduled by time alone carry on regardless, which is how a downstream job processes data that was never loaded.

Monitoring covers whether the system is healthy. Transports cover whether changes reach it correctly, and Basis owns both.

A transport request collects changes made in development. Configuration goes into customising requests, and repository objects into workbench requests. Releasing a request exports it to the transport directory, and importing it applies it to the next system.

STMS is the transport management system, showing the import queues for each system in the landscape. The queue is a list, and order matters: transports imported out of sequence produce objects that reference things not yet imported.

The failure modes are consistent. Return code 4 is a warning and usually acceptable. Return code 8 is an error and the object did not import correctly. Return code 12 is a serious failure. Importing a queue and not reading the codes is how a quality system diverges from development without anybody noticing.

Overtaking is the other classic problem: a later request imported before an earlier one that it depends on. The transport of copies mechanism and careful queue management exist to prevent it.

The discipline that avoids most incidents is simple and often skipped: import in order, read the logs, and never change configuration directly in production.

• Only reacting after users complain.
• Ignoring update failures (SM13) or dumps (ST22).
• No automated alerting, missing off-hours issues.

• Ignoring SM13. Failed updates are silent to the user who caused them, and they are data that should exist and does not.
• Clearing old locks without checking. Deleting a lock held by a live session corrupts what it was protecting.
• Monitoring only production. See licences for another check that is easy to forget until it matters.

Running the round is the daily work, and setting up alerting so the system tells you before the business does is the part you do in the course.