Problem:

In big trouble now, I write data to E_T_DATA manually as an example before below codes.  I didn't use cursor and didn't set the value sy-subrc, so I thought the update runs again many times and coudn't be ended.  After I run the update infopackge, it shows "request data", when I watched the monitor, it shows warning/not yet, then the system became very slow.  I delete all the relevant objects like cube, datasource and restart the BW service, but the system was still very slow.  Why is it so and how I can deal with it.   Did it have some relationship with this job " BI_WRITE_PROT_TO_APPLLOG ", because I saw this job runs every 5 minute.
------------------------
IF SY-SUBRC <> 0.
    CLOSE CURSOR S_CURSOR.
    RAISE NO_MORE_DATA.
ENDIF.

Answer:

Don't ever delete this BI_WRITE_PROT_TO_APPLLOG job. This is the main application log for your BW system.

Report - RSBATCH_WRITE_PROT_TO_APPLLOG is scheduled in BW every particular minutes to write an application log ,this report is having job name BI_WRITE_PROT_TO_APPLLOG .

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.

This log files can grow large (intensive read on table TBTCO and TBTCB ), especially logs from Job BI_WRITE_PROT_TO_APPLLOG and might impact some of the performances like system slow down.

Check unused Job logs with Report RSBTCDEL2 and clean out 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. 

Get help for your SAP BW problems
SAP BW Forum - Do you have a SAP BW Question?

SAP Business Warehouse Books
SAP BW Books - Certification, Interview Questions and Configuration

SAP BW Tips
SAP BW Tips and Business Information Warehouse Discussion Forum

Best regards,
SAP Basis, ABAP Programming and Other IMG Stuff
http://www.erpgreat.com