Introduction
Hello everyone, I have been working on multiple BW landscapes and operations support for quite some time and from my experience I saw batch processing has high visibility among leadership (business) and its always challenging to refine the existing batch processes and bring down the overall runtimes as part of continuous process improvements.
I have been fortunate to successfully optimize batch processing in multiple instances and in my blog I intend to advise handful easy tips to optimize batch processing.
1. DTP - Data Transfer Processes
I have always seen when people create DTP’s they never consider optimization aspects of how this will impact are simple techniques you can use to reduce the runtimes for data loading. Combination of Parallel Processing and Data packet optimization there can be dramatic reduction in runtimes
Increase Parallel Processing: There is a provision in DTP to increase the number of parallel processing, if you have available work processes then feel free to increase this number and change the job priority. By default this is set to 3 and the job class is set as “C”
Another way of parallel processing is to split the data from the source into smaller chunks in case of full load from source to target and run them in parallel with filters applied.
Example: If you have to load Business Partner master data from CRM/SRM system then you can always split them into chunks depending on value range for Source /Territory/Type and run the DTPs in parallel
Data Packet Size: In DTPs you can always vary the data packet size which is directly proportional to the loading run time. Lesser the size of the data packet lesser is the loading time and vice versa. The default value set is 50k records but it can be changed when in edit mode.
Note: At times even after changing the data packet size the number of records in a packet won’t change and in such cases you will have to change the size of source package
2. Info Package
For Full Info Packages too we can have parallel processing to split the data from the source into smaller chunks and run them in parallel with filters applied and there is also provision to change the data packet size
In Scheduler there are other options (“Timeout Time” and “Treat Warnings”) as well which is not for runtime optimization but helpful in case you encountering issues with timeout errors and if warnings are to be ignored
3. DSO
DSO activation can be slow if the batch tables are large in size as these are run through for object activations, you can always ask BASIS team to clean such tables with report RSBTCDEL2, Tcode SM65
BASIS – SQL team should always consider updating the statistics for the DSO and reorg/fragment the tables if required. This can be also a routine activity based on the your requirements and needs
There is a provision to create secondary index for DSO tables and it can be either done by SQL DBA team OR in BW console Tcode SE11 to optimize the runtimes
If you are not reporting on the DSO, the activation of SIDs is not required (this will take up some considerable time in activation); Often the logs show that the activation job takes almost all the time to schedule the RSBATCH_EXECUTE_PROZESS as job BIBCTL_*. RSBATCH_EXECUTE_PROCESS is for scheduling and executing the SID-generation process. If you don't need the relevant DSO for reporting & you don't have queries on it, you can delete the reporting flag in the DSO maintenance. This would be a good way to speed this process up significantly. Check under 'Settings' in the DSO maintenance whether you have flagged the option "SID Generation upon activation".
Helpful SAP Notes & Documents
SAP Note 1392715: DSO req. activation: collective perf. Problem note
SAP Note 1118205: RSODSO_SETTINGS Maintain runtime parameter of DSO
SDN Documenthttp://scn.sap.com/docs/DOC-45290
Thanks
Abhishek Shanbhogue