Skip to Content
Actions

Basic start-up troubleshooting – the logical sequence!

June 20, 2013 | 2,709 Views |
 #sapadminbasisbeginnersSAP troubleshooting
Follow RSS

If I had to select one single issue that people report more than anything else in the  Basis discussion forums it has to be problems they have starting an ABAP system.

 

Over the years I have read hundreds of discussions and for some reason the majority of posts start with a brief explanation of the problem and a “copy” of the dispatcher developer trace. Why?, There’s really not enough information there for anyone without a crystal ball!

 

If you find yourself in this situation, What do you do?

 

Basically when you start the system…

 

Database starts

SAP checks if the database is available and if it is not it starts the database. No dedicated developer trace is created in the work directory as the database has its own logs.  If the database does not start correctly it should be visible within seconds.

 

Message server kicks in

The message server is the first part of the system to start, it handles the communications between the instances.  Only one message server is available per system, regardless of the amount of dialog instances available. The message server logs are kept on the dev_ms developer trace and if there is an issue with the message server it will be pretty obvious because you will not see a dev_disp trace.

 

Dispatcher next

Ahhh the Dispatcher!… well, the dispatcher dispatches (ha!), Nah, seriously… The dispatcher job is to receive the requests and direct them to an available suitable work process. During start-up you can see how the work processes are invited to start in the dev_disp developer trace. If something was to go wrong the only thing you will find in dev_disp is that the work processes died. Usually no reason is ever given for the failure to launch in this trace, but one dev_w* developer trace for each dialog process is created and populated in the process.

 

The dialog processes

This is where you’ll find the root of the problem 99.9% of the time. Why?…  Each dialog process has a dedicated memory area and a dedicated connection to the database layer. If something is going to go wrong it will most likely happen here. Each work process has its own developer trace dev_w* where you will find detailed information on the error.

 

So the logical troubleshooting sequence, in a nutshell is…

  • Check connection to the database with a quick R3trans –d command, it’s the quickest and simplest way to discard DB availability as the issue.
  • Go to the work directory and check the developer traces. If the dev_w* logs exist it means that the message server and dispatcher started and the issue is in the work process logs..
  • If the dispatcher and work process developer traces are not created then your issue is in the message server developer trace.

 

The next time you find a start-up issue I’m hoping that these simple steps might mean we can dispense with the crystal ball 😉

 

Love to hear your comments.

 

Follow-up blog Basic start-up troubleshooting JAVA – the logical sequel!

To report this post you need to login first.

35 Comments

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

  1. Former Member

    Knowledgeable document for Freshers in SAP BASIS, escpecially helpful in Operation & maintenance projects…..

      Cheers……….. Juan!!!!!!!!!!!!!!!

    Thanks

    Sumit

    (0) 
  2. Akshay Gupta

    Juan,

    What a wonderful troubleshooting tip.

    Usually when something goes wrong in the startup of the system and the development/biz. team is firing you with calls/emails about the system’s availability, most of the time is spent in work directory catting the logs and trying to figure out the issue and 1st thing that went wrong.

    Next time on wards, I will follow the trail so that the user’s don’t have to loose their cool.

    • Go to the work directory and check the developer traces. If the dev_w* logs exist it means that the message server and dispatcher started and the issue is in the work process logs..
    • If the dispatcher and work process developer traces are not created then your issue is in the message server developer trace.

    Regards,

    Akshay.

    (0) 
  3. Former Member

    Hi Juan,

    Very nice document.

    Small addition .. In the home directory of SIDADM it writes some files in Unix apart from work directory which gives some more information. Like startDB.log etc.

    I would request you to publish similar document for Java as well as part 2 😉

    Thanks,

    Jagadish.

    (0) 
  18. Former Member

    Very good Juan, it is very easy and simple.

    SCN users not following these simple steps if they have issues starting SAP and asking the same questions again and again.

    (0) 
      1. Former Member

        Hi Juan ,

        Have you prepared for the java system ???

        i am waiting for the doc for  java System.

        If you have prepared please update the link .

        Regards,

        Abhishek

        (0) 
  24. Former Member

    Juan,

    Great article and deeply insight information.

    If you have time, can also extend the troubleshooting scope to cover sapstartsrv process. I have encountered a wired situation that the Windows MMC doesn’t display any SAP System to start with. We were all in panic then. Finally we found the culprit is a bad sapstartsrv.exe (the win service failed to start), which was overwritten by wrong kernel binary. Back to the old day I didn’t know the link between windows service and MMC.

    this is my 2c

    (0) 

Leave a Reply