Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
24,873

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 :lol: ), 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 :smile:

8 Comments
Labels in this area