Data load failures

[Former Member]

Hello all,

These days my daily loads are failing regularly. We used the same process chain before also but there was no problem in the daily loads .I have taken charge of monitoring the loads 2 months ago. From that time the problem started. There are no real issues for the process to fail.Process is failing when data is being loaded from ODS to CUBE or activating ODS .It is hell lot of time to Refresh the Statistics.If i have some error message i can correct it,but it says " process still running" I have stream lined the data packet size as well but no difference in the loads. Before a particular load used to take 1 hr to complete ,now the same process is taking 2-3 hrs to load,though there is not much change in the data which is being loaded. After the role has been handed over to me i have activated all the process chains contents into BW ADMIN from the guy who has handed over to me. But still in SM37 daily there are messages which show a job "BI_WRITE_PROT_TO_APPLLOG" running in his name. IS there any way of rectifying this error.Please tell me how to overcome the daily load failures.

[Former Member]

Hi Praveen ,

Could u please tell me whether the Job running in the name of u r earlier colleague is on R/3 side or BW side ?

The Job should be have name " ALEREMOTE " is u r running it with process chain.

If it is showing the name of u r earlier colleague then it may happen that the Job is locked since u r have taken charge from last two months.

So better kill the Job which is still running and then start fresh uploads.

You can kill the unwanted jobs in SM51 for that u need PID to be taken from the Job Details tab of SM37.

If u do not have authorization to kill the OLD jobs in the name of earlier colleague then contact Basis people.

Best Regards ,

Amol.

[Former Member]

Thanks Amol for the reply . I think the job is running on BW side. My collegues ID is locked after he left.

If i kill the process using the method wat u said,does the new job create on its own or shud i create it. Please clarify.

Warm Regards,

Praveen

[edwin_harpino]

hi Praveen,

about that job, take a look oss note 769414

hope this helps.

Solution

This is only a consulting note that explains why the RSBATCH_WRITE_PROT_TO_APPLLOG/job BI_WRITE_PROT_TO_APPLLOG report runs in your system every 5 minutes since Support Package 23 (3.0B) and the equivalent Support Package 16 of 3.1 and Support Package 04 (Stack 04) of 3.5.

This report must neither be descheduled nor deleted, as long as BW is working live, because otherwise any error messages that appear are not written to the application log.

If you prefer another user under whom the report should run, you can of course first deallocate the report in sm37 and reschedule it again under the desired user.

You MUST use the sm37 job name BI_WRITE_PROT_TO_APPLLOG for this.

The 5-minute execution interval is only a default value, and can be extended up to one hour. However, obviously the error messages may then only appear in the application log after one hour.

If you shut down the system (import to the Support Package and so on), you can then of course deallocate this sm37 job.

There should also only be one active periodically running sm37 job that executes this report, therefore you can delete any multiple scheduling in sm37.

The job usually schedules itself as soon as either the monitor assistant is executed - then with the user who executes the monitor assistant

or if the AdminWorkbench is called - then with the user who calls the AdminWorkbench.

If a scheduled job is already found in sm37, no further one is scheduled.

The job must of course run in the BW client.

The job user needs authorizations to write application log entries.

Note:

In the sm37 log of the current BI_WRITE_PROT_TO_APPLLOG job, you will still find all the messages that the job has written into the application log.

If there were no new messages for writing into the application log, only message RSBATCH 020 (which indicates that no logs were found for writing into the application log in RSBATCHDATA) appears in the sm37 job log.

"No logs found for writing to appl. log in RSBATCHDATA."

This is not an error it is simply a note to indicate that the job was executed correctly and that a new message was not to be written at this time because no new messages have accumulated.