Skip to Content
Problems during the data load occur more or less frequently. The cause is differently. Sometimes it is an issue with disk space, sometimes there is no memory available, sometimes there are timeouts;.
Here some examples for the error messages:

Data load

Data loading error- URGENT

As we are all dealing with BW, we only see the monitor entries, and mostly it is giving us the impression, the load is still running, but in fact the load already terminated for whatever reason. Here I will describe some things to check and the resulting action to fix the issue.
Of course, the dataflow has to be set up correctly. The datasource has to be active and replicated. The mapping from datasource to infosource has to be maintained and activated and/or the update rules to the datatargets as well.

Loading from R/3:
Here it depends on how you load your data. If you load it using the PSA, you have to check in the SourceSystem if the data doesn’t arrive in the PSA. If it is already posted to the PSA, you have to check your BW itself.
If you don’t use PSA for your loads, well then you have to check both sides. R/3 for the extractor related issues and BW for the transfer or update rules related issues.
1. Actions in the SourceSystem:
a) goto transaction sm37 and check for a job named BI_REQU….(REQU…. will be the request number in BW) for your communication user (usually it will be ALEREMOTE). If the job doesn’t exist, check with your basis. There might be a delay time until the job will be created. If it exists, check whether it is running or not. If it is running goto b), if not, your load just finished or terminated. Check the job log. If it finished successfully ok, if not, goto c)
b) goto transaction sm50 (may be better sm51 if you have more than one application server) to check for running processes for your communication user. Here it is also possible to check what a process is doing at the moment and you can start debugging the process. If there is no process, the load just finished or you need to goto c)
c) goto transaction sm21 and choose ‘System-Log->Choose->All remote system logs’ to display the log entries for all servers and not only for the one you are currently logged on to. Check for entries related to your communication user in the relevant time. If there are errors, check with your basis. Additionally goto d)
d) goto transaction st22 to check for dumps for your communication user in the relevant time. Analyze the dumps. There might be a program error -> check with a developer to fix the program error, there might be disc space, memory or other parameter errors -> check with your basis and/or a developer to get the issue fixed.
2. Actions in BW:
The actions here are almost the same as described for R/3, but just for completion, here the steps once again.
The difference here is the user you have to check. If you scheduled the load in background it is again the communication user (mostly ALEREMOTE). If you scheduled the load directly, the communication user is your user name.
a) goto transaction sm50 (may be better sm51 if you have more than one application server) to check for running processes for your communication user. Here it is also possible to check what a process is doing at the moment and you can start debugging the process. If there is no process, the load just finished or you need to goto b)
b) goto transaction sm21 and choose ‘System-Log->Choose->All remote system logs’ to display the log entries for all servers and not only for the one you are currently logged on to. Check for entries related to your communication user in the relevant time. If there are errors, check with your basis. Additionally goto c)
c) goto transaction st22 to check for dumps for your communication user in the relevant time. Analyze the dumps. There might be a program error -> check with a developer to fix the program error, there might be disc space, memory or other parameter errors -> check with your basis and/or a developer to get the issue fixed.

Loading from BW itself:
If you are loading data within BW, eg. from ods to cube, things are mostly a bit easier except you have lots of coding in all the routines in the transfer or update rules. Without the coding you normally get a message in the monitor for the error.
The checks to do are again the same as described before in ‘Actions in BW’ and I will not repeat them here.

Loading from Flatfiles/Legacy systems:
As there is no control over the legacy system while loading data, we also need to concentrate on checking BW for errors. The actions in the legacy system or the file (system) will be more or less concentrated on checking the authorities on files, tables or views. For other errors, there is a error message available in the monitor and if not, goto ‘Actions in BW’.

Possible actions to solve the issues:
If you are dealing with program errors, ok, it is pretty easy, talk to a developer and correct the error. Additionally it might be necessary to increase the performance of the program by using another logic.
If you are dealing with system error, talk to your basis. In this case you might need to add some disk space, enhance table spaces, increase the size of some system parameters (for program runtime, for memory management …). The basis needs to do some fixes.
If nothing solves your issue, then open a new thread or search for a thread in SDN or open or search for a note in the

OSS

To report this post you need to login first.

9 Comments

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

  1. John Skrabak
    Good stuff.

    Think this kind of “How BW works in the real world” stuff like what are the typical problems, solutions, and things to keep an eye on are in your system is one iof the biggest missing pieces.

    Your blog inspired me to post to the SDN Suggestion forum.  I thin kwe nned to find a way to collect or index this kind of content, be it blogs, or forum threads that are instructional, in some way.  Maybe a shared blog, or a wiki.  So much go info is on SDN, just need to be able to pull it together.   

    (0) 
  2. Prakash Holalkere
    Hi Siggi

    Thanks for this excelent post. Had one question: Does SM58 transaction in R/3 hold any relevance to such data load issues? I have noticed that the tRFC queue here gets blocked in case of loads with yellow status in BW? please enlighten.

    thanks

    Prakash

    (0) 

Leave a Reply