Basic start-up troubleshooting – the logical sequence!

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!