SM66 – a small tip that can make a big difference

Any Basis admin has a set of t-codes that she or he uses frequently in order to check the system’s health.

Some may rely on 3rd party monitoring tools, some wait for alerts to pop-up (and some wait for the end-users to complain 😆 ), but those who know their system well can take a glance at T-codes like SM66 and tell right away if the system is healthy.

In general, t-code SM66 (as most of you already know) shows the “Global Work Process Overview”. Global – because it spans across all the app servers in a group.

It shows (for example) a snapshot of the running processes (Dialog, Spool, BTC etc.), their PID, their Status (Running\Stopped), Reason (PRIV, SLEEP, CPIC….), Time, Action (Update, Read, etc.) , User and the Table.

It also gives you memory allocation of each processes and way more.

If, for example, you see many processes running for quite some time with Reason = CPIC then you know that there is probably a problem with external interfaces that the system tries to call.

If, for example, you see many working processes updating the same table – you probably have a locking issue or any other DB issue.

If, for example you see way many processes than usual – you know that the system is working harder than usual.

I can go on and on about all of SM66′ features, filters and best practices but this is not the purpose of this post.

This post holds a small and simple tip that can make a big difference:

How many times have you encountered a situation in which there was a “problem” with the system – it may have been stuck, maybe slow, even something completely vague that comes from the end users regarding a performance issue or a communication problem with external interfaces\systems  – but when you try to check it – it is gone ?

Well, SM66 can’t help you now because you need a retrospective look at it.

You could check the system logs for problems, STAD and so on – but you’d wish you could have taken a look at SM66 exactly at the time of the problem.

I recommend creating a simple job that will execute SAPMSM66 (this is the program sm66 runs) periodically every minute.

In case of a problem in the system which requires retrospective checks – no problem:

Just look for the job output in at the time of the problem (the spool output) – and there you have it – a snapshot

of the system’s SM66 at the time of the problem.

Simple – and yet very helpful.

Enjoy 🙂