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.
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.
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.
No comments:
Post a Comment