Skip to Content
Author's profile photo Former Member

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.

Snap 2013-05-29 at 17.17.44.png


Simple – and yet very helpful.

Enjoy 🙂

Assigned Tags

      8 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Manas Behra
      Manas Behra

      Really a gr8 Tip.

      Manas

      Author's profile photo Manas Behra
      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

      Author's profile photo S Sriram
      S Sriram

      Hi Adi

      Its good one

      Thanks

      Sriram

      Author's profile photo Former Member
      Former Member

      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!! 🙂

      Author's profile photo SUJIT SHARMA
      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

      Author's profile photo Former Member
      Former Member

      Hi Adi,

         Good  practice for healthy monitoring of the systems.Thanks for sharing.

      Regards,

      Bharath Parsi.

      Author's profile photo Former Member
      Former Member

      hi Adi,

      good blog 🙂

      by the way, how is it different from /sdf/mon ?

      we can get the instance wise WP details at any point in time ?

      Author's profile photo Former Member
      Former Member
      Blog 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.