Skip to Content

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.

Snap 2013-05-29 at 17.17.44.png


Simple – and yet very helpful.

Enjoy 🙂

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

    1. Manas Behra

      Hi,

      Also , whenever system is slow genrally SM66 opens very slow as it connects to all Application servers for that . So if runtime of job scheduled  cross threshold ( like 120 -180 sec) we can set alert from controlm or Solman , it can send alert if runtime increases and we can know if System is running slow at that time . Hopefully it will work

      Thanks

      Manas Behra

      (0) 
  1. Avishek Raha

    Good Post. Simple tip but very very useful. We encounter user complaints of system getting slow, etc and your post can be used effectively.

    Thanks buddy for sharing!! 🙂

    (0) 
  2. SUJIT SHARMA

    Hey Adi,

    Thanks for the cool tip, will definitely follow it. Recently face the issue and yeah we missed something like this.

    Regards,

    SUJIT

    (0) 
    1. Adi Jabkowsky Post author

      Hi krishna

      /sdf/mon gives a very detailed wp analysis and is excellent for in depth investigation.

      However, sometimes just from looking at SM66 from a bird’s view you can tell the system state at any given time.

      Every Basis Admin has his or her own set of tools for getting the “feel” of the systems’ health. For me, one of the main tools is SM66.

      I would suggest to use sm66 for the first hand approach and /sdf/mon , st03 for the detailed review.

      (0) 

Leave a Reply